How to Rapidly Overhaul Outdated Software

We set out to re-design decades old legal tech software in just a year. This project's success hinged on prioritization and simplification of features. I worked closely with my internal product team, the client, and a cohort of users to validate our designs. The user friendly interface was designed to reduce employee training and acquire new customers.

Project Overview

The Product

Law firms use this software to manage the litigation and debt collection process for debtors. It tracks their firm's financials, produces documents, generates reports, and takes the guess work out of employees day-to-day operations.
‍

The Team

I led the project alongside a Product Manager and a Tech Lead. In our roles, we oversaw our respective teams' activities. I directed a team of two UX/UI designers. We worked closely with a product owner on the client side, as well as several subject matter experts.

My Role

In the discovery phase, I led efforts to understand the product, its functions, and its users. I identified all necessary design tasks, estimated them, and sequenced the work. During delivery, I both worked on designs and supervised other designers to see the project through to completion.

Planning the Work

My agency had just over a year to rebuild a complex legal tech solution. After initial discovery, we knew we had to keep the requirements fresh for the long haul. Following a Google venture sprint model, I structured our work into two-week modules.

It was important for us to build in time to understand requirements and test designs with users so we could remove any unnecessary features. This product was over 20 years old and had a lot of duplicative features. While we spent extra design time doing this testing, we knew we'd save development time by removing features.

We completed the project under budget and met the client's objectives: modernizing the product and allowing them to expand into new markets.

We based our sprints on Sprint by Jake Knapp, but extended the process to two weeks instead of one to give us time to create development ready designs.

Day 1: Requirements Gathering

At the start of each sprint, we delved deep into the specific task users needed to accomplish within the software. Day one was dedicated to understanding how users performed this task and its significance. We collaborated with the client to explore how their current software facilitated this task and identify any existing pain points. For complex tasks, we also conducted usability studies with platform users.

The day concluded with a team discussion, revisiting the project scope and assessing whether new insights influenced our planned timeline or approach for the two-week sprint.

Day 2: Brainstorm Ideas

On the second day of the sprint, our objective was to brainstorm and evaluate as many ideas as possible. We'd gather in a room to map out all the requirements and address any remaining questions collaboratively, ensuring everyone shared a clear understanding of our objectives.

With this shared understanding in place, we'd begin sketching ideas, evaluating them based on our understanding of why users required this process. Once we had a sense of direction, we'd divide the design work among our team of designers. Despite working on different parts of the flow, our collaborative approach ensured a cohesive design by the end of the week.

After we got the requirements, we’d visualize the designs together to ensure shared understanding and to divide up the work between designers.

Day 3 & 4: Wireframing and Feedback

Building upon our sketches from the previous day, day three was dedicated to translating those ideas into tangible screens. We identified existing design patterns for reuse and developed new components as needed. We collaborated closely with the engineering and product teams to ensure the feasibility of our designs.

On day four, we presented our wireframes to the client and subject matter experts to gather feedback and assess if our new designs were effective. Our aim was to receive approval to proceed with testing the new designs with users.

We wireframed key screens for feedback from devs, product, and the client. As our component library grew, we integrated it into wireframing. Eventually, we moved straight to high fidelity as patterns solidified.

Day 5 & 6: Create Prototype and Test with Users

After we got the nod of approval from the client, we'd begin preparing a prototype to use for testing. Our goal was to create a simple prototype to test the key screens in the workflow. I’d write a test script made up of 3-5 tasks.

We wanted to learn if our design was usable, but we also wanted to understand what features might not be necessary in the MVP. Since we only had a year to re-create a platform that was built over 20 years, we wanted to make sure we were spending our time designing the right things.

On test day, I'd moderate 3-5 sessions with our cohort of users. Throughout the test, myself and the observers would keep track of key usability issues or any missing functionality needed to do their job.

We'd meet to debrief between sessions and start to formulate a list of the top issues we saw with the design. Overall, we conducted and synthesized the tests following the ideology laid out in Steve Krug's Rocket Surgery Made Easy. He emphasizes using tests to identify the biggest issues and fix them in the simplest ways.

With the help of a cohort of current users, we’d test our designs on simple prototypes.

Day 7: Improve Design

We'd begin day 7 meeting with the client to review the test findings. Our goal was decide on what we wanted to change or remove from the design before it went to development. Common changes included things like: re-labeling navigation to be clearer, combining or splitting up content we grouped together, and adding or removing columns in data tables or steps in a process.

This day was particular crucial because it was our last chance to review the scope of work and decide what we could build in the hours we had.

We also used this time to identify future roadmap items. If users were able to complete a task, but thought it might be easier doing it a different way, we'd make a note to come back to revisit in a possible future release.

This project was all about lean UX methods. We focused on insights versus presentation aesthetics so we tracked our testing takeaways in Google docs.

Day 8 & 9: Create UI Mockups

By this point in the sprint, we had a clear direction for the design. We'd spend day 8 and 9 working heads down to produce designs. Our goal was to create all the screens and annotations necessary for the development team. This was a lot of work in a short period of time. We relied on our component library to speed up the process.

The last few days of the sprint, we’d crank out all the states required to handoff to the dev team. I found the Hamilton soundtrack particularly motivating to listen to on these days.

Day 10: Sign Off

On the last day of our sprint, our goal was to get approval from the client and complete all the designs needed for the process we were working on. At this point, both our team and the client would be happy with the direction of the product. The client may request a few small tweaks, but this review was mostly to “dot our I's and cross our T's”.

Results

The client was thrilled with the end result. They appreciated the involvement of their current users in the process because it alleviated a lot of their anxiety with overhauling a software that already worked well. We finished under budget although we did launch later than the original date planned. This was due to adjustments in resourcing and trying to maintain pace with the development team to not work too far ahead.

This sprint structure contributed to the project's success in three key ways:

It helped us develop shared understanding. The other designer and I would spend hours sketching together. We'd try out many different ideas and discuss the validity of each. This exercise created a shared understanding that ultimately increased how fast we produced designs during the sprint.
Testing allowed us to eliminate features. Taking the time to test helped make decisions on what features to cut from the original product easier. The testing sessions were equal parts usability assessment and feature prioritization exercises.
Frequent check-ins with the client. Throughout the two weeks, we had at least 4 calls with the client. We found this was the sweet spot for spending just enough time on the designs to complete them accurately.

Before and Afters

We joined the client at a conference to unveil the new product to their clients. Our booth was easily the busiest. People who weren’t clients lined up to get demos of the new software.