Modernise a Legacy Tech Stack.

Supply Period Redesign Case Study

Client : ESG + External Clients
My Role : Research, Designer, User Testing
Project Time: 1 Yr 6 Months + Ongoing
Team: 2 UX Designers, 2 Sprint Teams x 6 Developers, Business Analyst, Project Manager

Define

Background

In 2019, the business decided redesign of a legacy product called Elec X as part of ESG's product suite to adapt the product to a modern tech stack and allow for overhaul of the legacy product inline with a wider commercial aim to modernise our core product suites. This case study concentrates on the supply period redesign area of the product.

The Problem

The problem was a conceptual application had already been produced by the development team as a technical proof of concept and we were fairly restricted by the like for like requirements of the new design with legacy which constrained what we could change as part of any improvements.

Discovery

Methods Used

Contextual Inquiry
Semi-Structured Interviews
Card Sorting
Personas

Initial Research - Contextual Inquiry

As part of initial research we needed to decide where to concentrate our efforts and where the opportunities were for improvement so we could make an impact and provide value.

Due to having lack of access to any metrics for tracking analytics due to the nature of the software we looked to our internal users to gather the answers we needed to understand how they currently use the legacy application and where they mainly spent their time in the application.

To do this we (me and the Junior UX Designer) spent 2 days with the internal team responsible for electricity and who used the legacy application. This involved observing how they used the product combined with semi structured interview questions to dig a little deeper when needed.

Overall Findings

  • Most Electricity team users spent most of their working day site level or MPAN level(e.g Supply Period) within the legacy application as they tended to deal with individual queries on a site by site basis.
  • Most data needed for analyst to deal with day to day work was at site level
  • Electricity Team staff mostly users dealt with issues on a site level which meant they spent most of their time on the supply period screen.

Further Research - User Interviews

Now we had carried out our initial research and understood how the teams were using the product in their natural context and what key areas of the product were (in this case the "supply period") we set about better understanding the "Supply Period" further.

To do this we carried out some semi-structured interviews with the team to provide further insights into the supply period specifically including looking deeper into how they use it and why. We also tried to understand the happy moments and what the current pain points were.

Key Outcomes

  • Show only relevant data and fields
  • Lots of information provided but it was poorly grouped
  • Lack of clear labelling for groups, input options, and filter operators
  • Doesn’t show the most important data to see from a high-level overview
  • Active data gets moved, even though it is still active.
  • Have to do export records via DB because we can’t set the max records to 1000 in the UI.
  • Too much clicking

Information Architecture - Card Sorting

To guide our the redesign of the supply period we had identified from our research so far that the data structure and its content needed to be understood further. To do this we carried out a card sorting exercise with our internal electricity team. This allowed us to understand how the team interprets the data hierarchy, the labelling of the data and also allowed us to potentially identify the key data they needed see most.

We carried the card sorting session using an unmoderated online platform to allow our users to carry out the card sort when they had the time. This was to enable us to get their input without putting too much time pressure on the team due to resource and time scales pressures.

Personas - Revalidation

Now we had carried out our initial research we were ready to move on to the design phase and start brain storming some ideas but before we did we revisited the proto-personas that were produced at the start of the project (Previous to any Discovery). This was so we could validate the personas and update them based on the research we had carried out and produced a more concrete set of the personas to allow us to better understand the motivators and needs of the user segements.

Overall we found the key issue with the legacy design of the supply period was the amount of content and the hierarchal structure of the data. We decided we needed to look further into this to gain an understanding of how the users would expect the content to be grouped and prioritised. Following this we used our research to expand on our proto-personas done at a earlier stage in the project to help drive empathy and understanding going forward.

Design

Methods Used

Low Fidelty Protoyping
High Fidelty Prototyping
User Testing
Thematic Analysis


Paper Prototyping

Now we had carried out the research we started to use this data to drive out solution and design concept based on the business goals, knowledge of users needs and constraints of the project. We started out initial concept by producing a high level paper prototype/workflow of the supply period using a whiteboard and a brainstorm session with Users, key stakeholders, Business Analysts and Developers.

High Fidelity Prototype

Once we had the initial design of the flows, category's solidified and an agreed high level design from the brainstorm session we then looked to build something a little bit more concrete in Figma to produce a high fidelity design with more detail to then test the idea.

We built our design up in Figma utilising our ESG design system to apply common UI design patterns and components. Part of the protoype involved a plugin called Google Sheet Sync to help us to manage the wealth of data across each screen/tab. This allowed us to update the data as and when was needed to make it as realistic as possible compared to real environment for User Testing.

User Testing

Now we had a high fidelity design ready we now could consider testing the design. Firstly we needed to understand the common tasks the users did in their natural environment (day to day jobs) some of which we had understood from the discovery phase. We went to validate and check over these before writing a test script we could allow users to run through.


For each round of user testing we would analyse the research output including metrics based on error/confusion rates and success rate from the sessions using thematic analysis collaborating with BA and Development to find trends in the data and then formulate an initial prioritisation of the data. Once this was done all the insights were moved into a detailed spreadsheet where would further analyse them and create actionable changes out of them to feed back into the design.
‍

After 2 iterations of testing and design refinements to the supply period prototype we agreed at this point the design would be suitable go to the development team to be produced. This was to aid our next set of user testing due to the data driven nature of the product, a real world scenario with a better accuracy of data would provide the most out of our next set of user testing. There was also pressure to start development from a project resource perspective so this benefited both our teams objectives and delivery times of the project.

Delivery

Methods Used

Design System
Pair Designing
User Testing
Thematic Analysis

Development and UI Design

Now we had reached development stage we worked with developers to implement the design using the pair design approach to support the design and development into the user interface. This is involved using the living design system to be imported as a module into the project to help utilise reusable components.

User Testing

Once a version of the design had been developed we carried out a 3rd iteration of user testing in a test environment with any improvements and outcomes/recommendations communicated to the project teams as per previous testing but this time actionable insights were created on the backlog within Jira to be actioned with the development phase.
‍Each actionable insight has a problem statement, description, severity rating (as defined in user testing analysis), resource rating impact and source to the origin of the problem so it could be traced back to the relevant research.

Retrospective - If there was more time/resource?

  1. Further Research
    ‍More research, as it‘s a complex and extensive system with many factors (for example, technical and business challenges) and various stakeholders.
  2. Additional User Testing
    ‍Further iterations / test phases,actually test the product in more natural environment 
  3. Focus more time on UI Design
    ‍Actively allocate/jump on the project as a UI designer to further solidify and support developers in implementation of visual designs.

Learnings

1 - Designing/Prototyping in smaller chunks
Due to the nature and size of this feature I think it would have benefited froma smaller chunk or area of the feature being split down and allocated toindividual UX designers to be designed and tested rather than producing thewhole concept as one.
‍
2 - Support and spend more time with the development team
Looking back we should have aimedto be more embedded into the development team to allow us to support the developers more in implementing our design to the standards needed and thus reducing the need for the raising of tickets to correct visual design errors.
‍
3 - Field Study is our friend
‍On a complex project where there is little or no knowledge Field Study is very helpful to allow us as a team to quickly understand the product, its usage and team who interact with it.

Conclusion

"Overall the Elec X project was a challenging project and the supply period was a big part of those challenges. The complexity and scale of the project put many potential roadblocks in our way combined with other issues such as resourcing and delivery times. However we managed to overcome these challenges by the UX team adapting where we could to come up with creative ideas to deal with these constraints and improve one of the key features of the product for the user in terms of their day to day tasks as part of the electricity team while still allowing the business to keep to its timescales for delivery. Overall the product has not only been moved to a improved tech stack to help the efficiency for maintaining it for the business going forward but we have achieved in improving the experience and the support service that comes with the product."