UX Case Study: Case Organization App Moving to the Cloud

CaseMap is a Windows-only 20-year old installed software product. It has been developed using the Delphi code language and MS Access, which is a database application. The main purpose of CaseMap is to help legal professionals organize all the elements of a legal case in one place, so they can easily see connections as well as gaps in a case. The software unifies facts, legal issues, documents, evidence, actors, and legal research under a single platform and connects them all together. Many existing users already love the product because it helps them create a story of the case and out-organize the opposition. CaseMap is part of a suite of products that includes TimeMap, a timeline tool; TextMap, a transcript tool; NoteMap, an outlining tool, and Sanction, a tool for court presentations.

Our biggest NPS detractors were that CM was complicated, hard to teach, and slow to learn. Many of its features were hidden behind menus inside of menus. 

At its heart, CaseMap serves a greater need than some of our current products with bigger sales. I and the team believe in its potential to improve more people's lives by making the act of forming cases easier. I was confident that if we kept to a strict 'diet' of simplification, as a team, we could make a great product with a great impact, together. First, we had to define what users thought CaseMap's role. 

• Convoluted MS Office XP style UI that hid many features behind layers of menus, sub-menus, and modals inside of modals. 
• Feature bloat. Features were added as users asked for them, but no total record of why features were added and if they met the user's needs was kept. So no feedback loop on the feature's success. 
• No analytics to know what features users were or were not using.
• Some marketing neglect meant the product was sold as a Swiss army knife.  As a result, it didn't always meet the expectations of the user. 
• Combine the best features of the suite into one unified product.
• Migrating existing users. This by itself doesn't sound like an issue if you have never done it, but moving existing users comes with many more expectations and toes to step on, especially when you don't have analytics. 
• An aggressive release timeline meant the UX team only had limited time to stay ahead of development. 

We had two engineering teams to help with the accelerated timeline.

• UX Research; 1 lead & 2 associate researchers split across multiple product teams
• UX Design: 1 lead (me) & up to 3 associates. 1-2 working solely on the project at all times
• 1 Visual Designer
• 2 Tech Leads
• 1 Tech Writer - split across multiple products
• 1 Architect - split between products
• Product Managers: 1 External and 2 Internal ( who directed the development teams )

• Stakeholder interviews
• Mine the internet product opinion
• Perform a Top Task Survey
• Existing User Surveys and Interviews ( Qualitative and Quantitive)
• Prototype and test
• Refine, improve, repeat

My first step, with no researcher at that time, was to perform a round of internal stakeholder interviews.  Performing stakeholder interviews creates a general understanding of the most important features and tasks of the users from the internal people who are most in touch with the user. It also helped collect shared expectations of going to the cloud. 

Contrasting this "insider" view I like to get a free outsider view. One of my favorite resources for assessing existing products is to 'mine' application review and recommendation sites. These sources give a quick sense of opinions, major issues, and competitors of your existing product. ( I later used these reviews to be put into textual analysis so the team could quickly see what the common themes were in the market opinion. We also used some of the text as the first draft of our list of top tasks.)

Once we had a UX Researcher on board, we performed a top-task survey. A top-task survey is a great method for establishing users' primary goals with existing applications and websites. I had the pleasure of working with this method creator, Gerry McGovern, at Cisco. I recommend it over the Jobs-To-Be-Done method as it is easy to apply through a simple survey. It is especially for products or websites with many features or links.

Conducting interviews and surveys with existing users gets a baseline of how users feel about CaseMap. We sent out quantitive surveys and performed qualitative interviews to gut-check the most important user features and user perception of CaseMap's wheelhouse. 

After collecting baseline market information we embarked on gathering team members for a design sprint to work out what the new product would be. Much like the Product Liability Navigator process (see PLN page for more information on the process and links to Design Sprint resources) we had a shortened timeline and focused on creating requirements and goals to solve the user needs. 

During the design sprint, we built our Lean Business Canvas and established our metrics for success, called our team objectives or OKRs. 

( For more on team objectives I recommend SVPG training, method and books. Start here)

One of the best decisions we made early on for this product transition was to set guidelines for how we approach re-designing the product. After establishing these rules, agreed on by the team, talking out the workflow for features became much easier by reducing disagreements on approach. 

• Knowing that complexity was the biggest detractor. We set a rule of simplicity. We created a simplified application framework. We applied navigation and sub-navigation to this rule.  We aimed to make as few a type of components as possible for the user even if on the back-end they worked differently. 
• We focused on giving the user ONE way to do things instead of four. 
• For higher risk and higher cost features, we chose one way to make them and then tested them against the current product. 
• If a feature was low risk and low cost, release it and then collect feedback. 
• Follow the 80/20 rule. Focus on the main features that your core users use every day. Plan for the average user. Build to scale for everyone when possible.  

• Follow the rules created by the team, whenever possible. Bring up exceptions with the team as they happen. Make a new rule when this exception meets team approval.
• Simplify whenever you can. Fewer components. Fewer styles. 
• Apply Atomic Design methodology. Design from the smallest component up and reuse pieces as much as possible when designing new larger 'molecules'. 
• Focus on the core users workflows and tasks that you have the greatest confidence as being primary tasks. Don't redesign the main workflows for the outlying tasks. 
• Ask hard questions about the existing or legacy workflows. Were they built that way because they made sense to the users or because they made sense to the engineer at the time? Don't assume 'this must be like this for a good reason'. In this case, applications have changed a lot and improved a lot in 20 years. Do you want to base today's customers success on old choices? 
• Keep working on the 80%, the core workflows, and make those 10% or even 1% better at a time. 

• CaseMap Cloud met the company's small law sales for the year in the first quarter it was released. 
• All test participants seemed to agree we had removed the largest NPS detractors to the product, making it easy to learn, intuitive, and simple to understand. 
• CaseMap cloud migration was the largest product migration to the cloud for our company at its time and we achieved that migration faster than any other product. I don't think this would have been possible without the simplification approach we took and of course, the great teams we worked with. 

• For new and existing products, I believe very highly in Top Task Surveys, that establish user baselines and Design Sprints to create innovative solutions that meet core user needs.
• Lean Business Canvases are a wonderful tool for business and UX creating new products. Our original marketing suggestions generated from our very first Lean Business Canvas turned out to be true. 
• Small businesses were quicker to adopt and laud the new Cloud product. Large businesses were harder to please and slower to migrate; often creating obstacles by insisting on outlier features before signing contracts. 
• Always insist on analytics in your new and old products. You can't learn from history if no one is writing it down. 
• Terminology turned out to be more of an issue than anticipated. Each of the products in the CM suite used different phrases for relatively the same actions or elements. Quite some effort was needed to pull apart what was a legal industry term and what was a learned application term. Pulling these 'vocabularies' apart allowed us to more easily join the multiple products' taxonomies.