Business Problem

Before I joined, the development team worked with a business analyst to define requirements iteratively sharing them with the business customer.

However, unclear processes and inaccurate requirements led to ongoing churn, spurring confusion and revisions as the requirements did not accurately address the business problem.

High Level Findings

• All user groups were not being considered.
  The design of the application was only from the perspective of the business customer, who were not the main users of the application, leading to incongruity and misalignment with the business goals.
• Bias towards simplified development.
  Development's wish to replace-in-place was reliant on replicating a tool that the business did not fully understand and contained functionality resident across multiple applications that was not in sync. This accounted for the initial churn.
• Problem was more complex than assumed.
  User interviews showcased many steps and hoops the users needed to jump through across different applications to achieve the business goals.

Lesson Learned

Redevelopment of internally facing applications has become less common in an age of SaaS vendors, but there are instances where the best solution is a home-grown solution.

It was a challenge working with stakeholders who were very adamant and resistant to reimagining the process and their application, even though they were not happy with the direct translation result.

Systematically walking the customer through each decision and interaction point was met with great success.

Developing a new, consistent UI reduced the visual complexity streamlining the use of the processes.

Initial Actions

With frustration the project lead solicited my help in untangling the project. My assistance began with a review of the current application that was being replaced and speaking with the business customers and users of the application. This was done to determine the main business drivers and what they were trying to accomplish.

The application being replaced was 10+ years old and was difficult to maintain by development. Many business customers had had a hand in the iterative design and revision over the years, so the current state did not reflect the ultimate state of what was needed.

Through interactive design sessions we mapped out the processes the business was trying to achieve, these were followed by developing Figma prototypes of screen designs, and repeatable atomic designs for tables, content areas and interactions to be utilized throughout the interface.

Resulting Actions

Working with the development team we refined these atomic designs to ensure that they could be developed and integrated into the SaaS solution the team was using to scaffold the design.

While the predominate design sessions were with the primary business customer, there were periodic checks with additional stakeholders, and different user groups to ensure what was being visioned mapped to the business needs.

Developing the atomic designs early in the process allowed the development team to structure the development process into Agile sprints, to design and develop functionality aligned to the different areas of the application.

By reducing the scope of the application to only include display data the application complexity was reduced, and editing of data was normalized into the applications where users were working, avoiding multiple entry points which confused and frustrated users.

UX Tools & Techniques

Throughout the year long project, many tools and techniques were used, many of which are specifically identified.

• Thought leadership and the ability to paint a vision of the future was key in winning over the business customers.
• Prototype (Figma) development laying out design patterns, atomic designs, user flows and processes aligned to good usability practice.
• Communication and presentation skills to a relay a clear vision. Iterative layout and design skills to present simple options to communicate complex information.