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.
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.
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.
How might we turn a Word doc-driven process into a user-friendly variable-length drafting process that also supports a structured data approach?
+ 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
+ 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
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.
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.
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.
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.
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.
Fully integrated throughout the application and user experience.
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.
