Introduction
Sometimes, what feels like the biggest success looks the least exciting. The UI for this project is hardly the most visually interesting thing, but it's one of the projects I'm proudest of, due to the obstacles that were overcome between concept and completion.
Goal
The task was to create a self-service application that allows Case Managers and other admin-types to set up their own business divisions (known as "clients"), users, project templates, and projects which feed into our eDiscovery application. Prior to this application, this work was being done manually. Contacting an employee to perform the setup was a bottleneck for our customers. This application would change all that and make setup as easy as typing in a few fields.
Challenges
Over the course of the year, several challenges held the project back. First, there were confusing priorities from upper management. This project was very important to secure a big deal. But so was an infrastructure project that this project depended on that promised to speed development going forward. And so was a vision project that was more consumer-oriented and would broaden the funnel.
Second, we had no product manager or product owner. We had very strong subject matter experts and advisors, but no one really tasked with moving the project forward. Yet I was on the hook to produce a workable UI. So I had to act as product manager to get the requirements I needed, and then translate that into screens. This involved learning functional areas that I hadn't worked in previously, being relentless about getting people's time, documenting UX needs from other teams, and pressing for answers. If no one could ask on my behalf, I would have to be the one to push.
As is common, scope was a shifting target. It kept getting reduced as our team's work was slowed and dependent upon the infrastructure project. This meant frequent adjustments to MVP and rethinking of interactions.
Next, we were not permitted to design a product from scratch. Because of technology and infrastructure limitations, we had to satisfy requirements using preexisting UI elements. Crafting the ideal interaction from all possibilities is hard enough; making an app do everything it should with a limited toolset is much harder.
To complicate matters, we hired a new UX team member who took over for me half a year into the project when it had stabilized. Significant time was put into getting the new hire up to speed, attending meetings together, and reviewing the new hire's work. Then, after layoffs a few months later, I had to invest time into resuming and reworking.
Sample UX requirements I requested of framework team.
Sample of detailed issues log I created to get requirements definitions
Process flowchart to get stakeholders on the same page.
A picture is worth a thousand words...conceptual diagram to explain mental model to Engineering and stakeholders and settle on MVP.
Problem-Solving
Below is a small selection of the types of functional and interactive problems I helped solve during this project.
Every screen was wireframed multiple times as scope changed and more requirements information became available from stakeholders. I took responsibility for every label, field type, and understanding what each field did.
In addition to general information, each project contained specific settings defining how it should be treated during processing. I reworded as much arcane, technical jargon to a human-readable labels as possible. I requested the Examples section to give users a concrete idea of how to set these fields to get their desired outcome. While visually plain, many interaction details had to be worked out, such as, "What if I select French as my fallback language or as the language to boost, and then a user disables that language in the top section?"
Despite the simplifications our team made compared with the old way of doing things, the above screens are pretty complex as this field has a lot of technical details. Confronting the user with all those screens felt overwhelming, so I suggested that we pull out only the very minimum required fields for project creation. Once the user successfully created this project "shell," we could show all the other settings.
Initial design for adding users to a project. Since our application has both a list of users and a list of projects, it makes sense to allow adding of users to projects from either list. To maximize development effort and consistency for the user, it was agreed that the same dialog would be used in both pages.
We thought through the edge cases, such as, "What if you already added one of the selected users to one of the selected projects?" and "What displays if you remove all users or all projects?" and "What if you try to mix users or projects that belong to different clients?"
In the end, we made compromises and reduced scope in favor of simplicity and reduced development time. If you already added the user, you can add them again and the user gets the union of all permissions. You can only add one or more users to a specific project which can't be deleted, and vice versa. If you delete all of the users or projects, the Save button is disabled. And since you can only pick one user or project (depending on page context), you know the related client, so the corresponding projects or users will be pre-filtered to that client.
Original design to pick a project specifications template. All available templates would be in the dropdown. If a user picked a template and further customized the settings, the template name would indicate that it was user-customized and the "Save As" link would become available. Clicking would open a modal dialog for a new name, and upon saving, that would be the newly selected template in the dropdown.
The development team came back with a few reasons why this design would not be feasible. In response, we compromised on this interaction model. The existing template would be shown as a hyperlink. Clicking would open a modal to change templates. The link could reflect if the user had customized the template further. "Save As" was dropped from scope. While not ideal, and while introducing one extra click, this compromise accomplished the same goal and allowed developers to move on with their tasks.
Released Application
In the end, we released, and the product is in production. Reception has been generally favorable, and we are happy to be in the process of redesigning the UI to be even more user-friendly.
The screen of general properties is responsive. With wide viewports, it appears as above, and at narrow viewports, it appears in one column as wireframed above.
