Understand how it works

I read through technical documentation to get a better grasp of what inspecting a steel roll means and how the software works.

In-context research

Steve (Researcher) went to several factories to observe and interview users of the product, users of its competitor, and their supervisors. This helped us to understand:

• Challenges in the work environment
• How users make decisions
• How Sarclad compares to competitors
• How long it takes to master the software

One limitation of the research was that it was conducted in the UK only. We later discovered that some findings did not apply to other markets (for instance, operators in the UK wore safety gloves that made it difficult to press buttons. But that was not an issue in the US). But more importantly, it meant stakeholders in the US did not feel as heard as their colleagues in the UK, which caused delays with the project later on.

We prepared a 1-day workshop with our client to try to think things through together and get everyone on board with the re-design project. The workshop was attended by Software Engineers, Product Owners and representatives from the Sales and Marketing teams.

Review the data and our goals

Steve presented insights from the research to get everyone on the same page.

Map out needs and pain points in the journey

We split into two groups with a mix of competences, with my colleagues Steve and Rebecca each in charge of one group. Our goal? Outline what the main journeys are for operators, depending on the task they are trying to accomplish. I jumped from group to group, encouraging them to think of what operators need at each point of the journey, and what their pain points are.

Prioritise information

The next exercise was to mark with red and green pens what was essential to operators in the interface, and what was not. This is when we had the most difficult discussions. Steve had observed how operators consistently skimmed through entire steps of the process that were unnecessary to them, and we knew some things had to go. But this isn’t easy to see for someone who is used to the product as is. So, I used the 5 whys method. This opened up discussions, and led to some surprising discoveries: for instance, one of the steps in the process existed only to facilitate QA testing. By the end of that stage, our stakeholders agreed to remove some things completely. And my colleagues and I understood how some others things could not be changed much, but might be improved to be less disruptive.

Sketch ideas

To end our day, we sketched out different ideas and voted on the ones we believed had the most potential.

I created a series of wireframes to visualise the new flow and layout of the pages, then iterated a couple of times to address any concerns that our clients had (for instance, the resolution of devices in most factories would have been too low for some of the graphs I had planned).

In the meantime, Rebecca (UI Designer) started to create the new look of the app.

We had planned a round of testing to validate the design. Unfortunately I was not involved: there were some delays, and by the time we would have been ready to test I had left System Concepts.