Requirements and Discovery.

Project Constraints.

This project presented us with a myriad of interesting and unique challenges that I was eager to take on. Many unique constraints cropped up during this process which required me to adapt quickly and pivot when needed. I listed some constraints that stood out to me below.

• A veteran designer left at the start of this project so we became a two person team; my Design Manager eventually tasked me with leading the effort

• The existing tool was in jQuery but all new features were to be designed for React

• The Case Browser was scheduled for release in Q2 2022 and Match Review in Q4 2022

• We had to align closely with our backend dev team as they worked to improve overall system performance

• Data security and risk reduction was a constant factor that we had to consider

Research and Analysis.

User Interview Findings.

To make sense of all of our research, we decided it was best to synthesize our data into a few key findings so that we could stay laser focused on the problem.

Card Sort Study.

A research method that I found very useful for organizing information that I wanted to mention here was the card sort study. I knew what a card sort was in theory, but I had the opportunity here to put it into practice in a real world setting.

A core piece of our new design would hinge on providing users with a way to view clients and use that to decide how to prioritize their work. I used a tool called Optimal Workshop to conduct a card sort study with internal SMEs to uncover the client data that would best help users make decisions to mitigate risk.

We used the results of our card sort study to create a table of clients that we called the case list and would later become a core piece of the Case Browser.

Identifying MVP.

While analyzing research findings it became clear that there were a lot of user pain points to address. Being a small team we knew we needed to strategically prioritize our efforts in overhauling such a dense software system.

High Priority Pain Points

• The UI was over-extended because features were stacked on top of each other

• Users did not have a way to quickly browse, prioritize and organize their clients

• Users had no concept of how many clients had been reviewed and how many remained

• Users struggled to compare a client profile to matches because of the existing top-bottom layout

We decided to conduct a workshop with our two Product Managers and identify HMW questions that focused on the high-priority user pain points. This allowed us to define two MVPs that would ultimately make up the core of this effort: Case Browser and Match Review.

Visual Design.

User Flow.

Rarely is design thinking a linear process and you must engage with the process thoroughly in order to get those lovely screens that represent a finished product. Many times, it’s really difficult to orient yourself so I always like to start thinking about how users will be engaging with the product. How do they get from A to Z? What options need to be available to them? How can I get an idea of how many screens we might need?

This is where user flows come in. I find them to be a really useful way to begin empathizing with the journey that a user might take. It helps me to visualize both the best and worst case scenarios and along the way I always uncover additional pain points and opportunities.

My team and I created a lot of user flows. Some large, some small. Some don’t even represent the final product, but each time we did it was a step closer to identifying solutions that would best meet user needs.

Below are some of the user flows that were created to begin visualizing possible solutions and how we might link them together.

Sketches.

It’s really hard to stare at a blank canvas and just come up with an idea. This is why I love the user flows so much. A flow allows me to focus on a distinct segment of the users journey and begin ideating what the screen might look like. When it came time to sketch, my team and I followed a “work together, alone” approach. We decided to take 10 minutes to come up with as many sketches as possible and then put them on a Miro board to discuss our solutions.

This exercise really helped us to build confidence and allowed us to quickly iterate and build off of each others ideas before we invested too much time into wireframes. Many of these sketches were then presented to Product, Dev and internal SMEs as an extra check to see if we were on the right track.

Below are some of my initial sketches that I contributed to the group.

Solutions in Low Fidelity.

I think it’s important to fail fast and learn often so I always strive to get design ideas in front of users quickly to validate my assumptions. I leveraged the wireframe feature in Miro to build out low fidelity versions of the design and regularly presented them to internal SMEs and, on occasion, users during feedback sessions.

One example of this that comes to mind was my proposed way of enabling users to create and group their queries. I learned that the method I initially wireframed would not scale well and did a poor job of communicating hierarchy to users as it didn’t fit their mental model of “queries” and “query groups” very well. I was stuck on this issue for a week or so, just trying different possible solutions.

Then, one morning I was making my coffee thinking of the navigation issue and an idea popped into my head to try a collapsable navigation component, similar to an interaction I had seen used before in Jira. I ran upstairs and mocked it up in Miro and showed it to my design manager. He loved the idea and a few days later we tested it with our users and received amazing feedback on it. This gave us the confidence to continue polishing the idea and we later called it the “Stack Nav”. This is now a component that we utilize in several different places in our app.

This was just one of the many examples of how constant iteration helped me work my way to the best solutions possible. Including users in this process also allows them to see that we are actively working on solving their problems and listening to their issues. This keeps our relationship with them strong and also continues to build their trust and faith in the business as a whole.

Prototyping.

I have to admit, this might be my favorite part of the whole process. I love working out the interactions that a user will experience when using a product so when it came to the prototypes, I took sole responsibility in this effort.

I quickly learned that prototypes can get blown out of proportion very quickly and there are so many times when you get thrown into another designers prototype and have no idea where to click. To remedy this, I decided to utilize Figma’s “flow” feature and built out lean prototypes that focused on a specific task. This resulted in 11 flows for Case Browser and 7 flows for Match Review.

By using these flows, I was able to quickly present my work to internal stakeholders, SMEs and test with external users in a way that more realistically demonstrated what the final product would look and behave like.

Iteration.

As with every stage in the design thinking process, even with the prototypes, I was constantly iterating. By using components and variants from our Figma design system that I built from the ground up (more on that in another case study) I was able to make one small tweak to one variant of a component in one location (i.e. the design system) and have it flow to every screen where that variant was used. This kept my prototyping process very rapid as I was able to implement changes and iterations in a matter of minutes.

I cannot say enough how powerful design systems, components and auto-layout was when creating the high-fidelity designs. Since I was going at this alone, it saved me so much time and it kept all of my designs clean and consistent. Since I placed such importance on keeping my designs, layers, and files clean and tidy any designer in the future should have a pleasant user experience when they go back through these files.

Handoff.

We had weekly check-ins with our frontend team and monthly check-ins with our backend team to keep constraints on our minds. When it came time to handoff, we were already pretty well aligned.

We didn’t have access to a tool like Zeplin so I decided to create a page in Confluence where I would document all of the business rules for these two MVPs. The business rules covered all of the interactions, which I enhanced with notated screenshots from the prototypes. The business rules for each MVP were also broken out into the same flows as the prototype so that they both aligned perfectly with each other.

The combination of prototypes broken out into flows, the tidiness and consistency of the hi-fi designs, and the detailed business rules with links to each prototype flow made it really easy for us to hand the baton off to the dev team.

Takeaways.

This was first and foremost a team effort, across the board. However, I was given the opportunity later in the project to take the lead on a lot and own this project as the sole designer. I learned so much during this process and grew leaps and bounds as a designer. I was able to take the lead, use my gut, implement knowledge and things I have learned but always had access to a very knowledgable mentor in my design manager to fall back on when I hit a wall.

I think I could improve my process going forward by spending more time thinking about micro-interactions. The old jQuery screens had a lot of inconsistencies on them with regards to these micro-interactions that it was easy to overlook them. I think spending more time really combing through a screen will keep us from having to double back during release time to address these items.