U.S. Dept. of Commerce
Designing a first-gen platform for managing the Entity List lifecycle for the Bureau of Industry & Security (BIS)
My roles in the overall application development project
User Research
Stakeholder Interviews
Design Sprint Facilitation
Feature Design
Experience Strategy
Information Architecture
Wireframes
Usability Testing
My tools
Figma
For consistency with other BIS applications and to quickly help stakeholders understand the vision, even my initial wireframes were designed high-fidelity using the USWDS.
Background
"What's the Entity List?"
It’s the extensive list of foreign people, companies, research institutions, and government organizations that you are legally not allowed to send certain goods and sensitive technologies to because it would harm U.S. national security or foreign policy interests.
The Entity List lifecycle
1. Nominate (Focus of this case study)
Countless agents and analysts draft and submit nomination ``packages`` containing the comprehensive rationale and evidence for anywhere from 1-50 entities to be added to the Entity List
2. Review
Multiple departments and specialists within BIS review and validate the details of a package of entity nominations
3. Vote
Representatives from the Department of Commerce (Chair), Defense, State, Energy, and Treasury vote to approve or reject a package of nominations
4. Publish
Approved nominations are published in the Federal Register making an entity's status legally binding, public, searchable, and subject to exacting export license requirements
Conduct initial user research
Create user stories, personas and user flows
Draft and link low- and mid-fidelity wireframes
Conduct user preference and usability testing
Develop and apply visual brand language
Finalize UI design and prototype
Key requirements for the Nominate phase
Since the Entity List was first created in 1997, the primary tools used have been Word and Excel documents and email.
- Variable content volume: A submitted package can feature countless entities and evidence, resulting in a few pages or 100+. This meant the input functionality had to be flexible.
- Structured data need: An overall strategic imperative was to make more of the data searchable and matchable. This meant creating structured data sections that would parallel existing Entity List information and what’s in other draft packages.
- Reduce formatting time: The Export Administration Regulations (EAR) require very specific formatting parameters for entities to be published in the Federal Register. Enormous amounts of BIS time are typically spent re-formatting what is initially submitted by agents and specialists. So the content input structure needed to support automated formatting to reduce this workload.
- Reduce window switching: Stakeholder and user research revealed a significant digital weariness from constant use of other BIS platforms that require an excessive amount of opening and closing windows.
The problem statement
How might we turn a Word doc-driven process into a user-friendly variable-length drafting process that also supports a structured data approach?
The simplest option, a single text input field, wouldn't suffice
+ It’s definitely an MVP development option
– Not practical for anything over 2-3 paragraphs
– Difficult (impossible?) to parse into a usable and searchable database format because of formatting inconsistencies among users
– Heavy server load because all memo content would be called each time
– Less supportive of the subsequent Reviewer process in which users would edit the content directly, pose questions for the submitter, or add comments and feedback
– Drafts would still be initially created as Word docs and then cut-and-pasted solely for submission, meaning other employees wouldn’t know an entity is part of a draft package until after it is submitted and parsed — contrary to an overall strategic goal
The block builder approach
+ Completely eliminates the need for Word doc drafts and keeps all content within the application from the first moment
+ Maximizes use of screen width during drafting process but creates opportunity for a column to be added for Reviewers to add notes and comments
+ Maintains the “full-page preview” feel users wanted since they often jump around to different sections while working on a draft
+ While this approach did not make it to usability testing (more on that below), stakeholders immediately grasped the block builder functionality when seeing it for the first time
A closer look at the block builder approach
Two foundational pages
Two types of content pages serve as the foundation of the application and interface, with dashed line blocks indicating the various sections for inputting entity nomination content. One is for managing the Package itself while the other is for inputting details on specific entities being nominated.
One active block at a time
Only one content block at a time can be in a focus state for editing in order to support user concentration. This was also intended to help prevent loss of inputted data as error messages would display if the user clicked away from the active block.
Key content required to unlock secondary input fields
For the Entity Editing screen, a Company Name must be entered before subsequent grayed out or inactive blocks become selectable. A similar prioritization exists for the Package Management screen.
Users can fill secondary content fields in any order
Once the secondary blocks become selectable, users can tackle them in any order. This was based on a key insight from the user research that most users jumped around from section to section as they drafted packages and inputted entity information. No one ever started at the top of the Word doc template and went line by line in order from start to finish.
An inline experience to add links and attachments
Documentation is required for each part of an entity. So the Entity Input/Editing experience is designed to allow users to add attachments, classified reference ID numbers, and URLs through an inline experience.
Error messages
Fully integrated throughout the application and user experience.
Most case studies have a Hollywood ending. Real projects don't.
A stepper pattern was deployed instead, primarily because it already existed
Multiple legacy BIS applications already used stepper functionality, so the codebase already existed and was easily deployable with minimal development time.
This was despite the fact that the stepper functionality was part of what was creating click fatigue within other BIS applications that users were far more active on. The time-and-money saving benefits vastly outweighed the user experience benefits.
While disheartened with the decision momentarily, it happens (but fortunately not too often!). From my personal perspective, I was most disappointed that the block approach didn’t get the opportunity to be part of usability testing so its benefits could be demonstrated and leveraged for future projects.
The disappointment faded quickly, and it was back to work on designing and refining countless other aspects of this first-gen application to continue to prepare it for initial launch.
