What we've got here: A natural-language and machine-learning proof of concept built out under tight wraps; it'll be a first in this market niche, and nobody wanted the competition to catch wind. The drawback? UX was only now getting involved, and the corner office wanted a beta launch, like, yesterday.
The now: What we have to work with
Turns out there are projects, which contain documents referred to as control standards, referred to by an alphanumeric code formatted NNNN-1. The tool's value is to read documents uploaded to a project and suggesting interrelationships between them, referred to as matches. Identifying these interrelationships is work that otherwise takes analysts days and weeks of reading and cross-referencing.
What stood out is, I was unclear where to even start. There's too much going on in this UI and very little to organize it into some sort of hierarchy. Once you'd created your first project from the splash screen, it wasn't obvious at all (a) that you would need to create a new project to analyze a new set of standards or (b) how to go about doing this. There were also too much information encoded in colors — red, green, blue, orange, and white — to be useful at a glance.
Triage and prioritize for quick, incremental improvement
Time is the constraint here, but, fortunately, all problems are not created equal. First priority needs to be issues that will most negatively effect the experience of beta users. Poor execution can easily kill an otherwise excellent product idea, so we don't want usability to get in the way of evaluating the value of the product. On the other hand, we will get invaluable real-life observation, metrics, and feedback from the initial beta users, so getting to market quickly is as valuable for me as a designer as it is for the organization.
Taking stock, what we do have is good research and a product manager who has domain expertise as well as in-depth knowledge of our target users; we know who they are, what they do, how they work today, and how this product can add value for them.
A few quick roughs get everyone on the same page.
You need ...
- ... access to your projects on the landing page.
- ... a guided experience to create new projects.
- ... a workspace that lets you focus on the task at hand: Reviewing matches suggested by the system between text-heavy legal documents and internal rules, called control standards.
- ... to focus your attention on reading and comprehension of the documents themselves instead of trying to sort out what's what in the UI.
- ... filters to narrow down your projects without having to scroll and scan to find the one you need.
Design fast
While working on a separate track to design a more optimal future experience and align the product with the rest of our suite, I work directly with the front-end developer to add as many improvements as we can. We add a new guided experience for creating a new project.
The rest of the product suite uses Google's Material design components. We can't implement that short term, but we can start moving our form controls in that direction visually.
The pills were asked to carry too much. What do the colors mean? What happens if you're red-green color blind?
More importantly, on the project page, which is the workspace of the application, we have “pills” pressed into service as both form controls and to present information, encoded in several combinations of color. The “pills” are also spatially separated from the contents they affect. I clean this up and add some visual hierarchy.
I move the “pills” along a baseline, so that I can spatially associate them with content. Instead of using multiple colors to indicate value, we use a simple square with five states: Empty, 1/3 full, 2/3 full, full, and completed, indicated with a checkmark. Any more granular value can be given as an exact numeric value in the details; you don't need that level of precision when scanning the sections. I remove the complexity of having them serve as form control as well by moving that functionality to the details section and exposing the choices as radio buttons.
Work six and 12 months ahead
Meanwhile, I'm also working on a roadmap for a post-beta release.
I'm taking the product to a clean, white design using Google's Material component library and conforming to the company's brand guidelines. This is the design standard of the other products in our suite, but it's also the right choice for this purpose and this audience: Reversed text and a "dark mode" is not optimal for an audience of lawyers in a tool the primary purpose of which is to make sections of legal text available for reading, comparison, and comprehension.
I'm also breaking out of the “pill” format. The original format represented each control standard with an ID, which has no meaning unless you memorize these IDs by the hundreds. Instead, I lay out the structure of the project in sections, each with its associated suggested mappings. Each control is presented as a row in a table, which allows me to expose more information -- name, summary, date created, and so on. That serves several purposes: It makes the project easier to scan, it gives you enough information to pick the control you want to work on, and it allows you to get an overview without digging into individual controls one at a time.
There are also major experience speed bumps that are functional in nature and have to do with helping our users assemble the right files for import into the tool in the first place as well as integrating that import process, and exporting the output, into a parent product. Those are the kinds of user experience problems I work through at a product management and requirements level and serve as a reminder that the scope of UX is wider than strictly UI.
