Technically complex can still be human-centred
When Trans Lex Work, a company working in the maintenance of turbines and other large rotary equipments asked us to help with designing a predictive maintenance system, we got excited. The thing we love about this job is it takes you to new places, and you have to immerse yourself in entirely new categories with every project. But it can also be scary for the client — we are not engineers, and had zero knowledge to build on regarding machine maintenance.
How could we give relevant advice in an industry they had over 30 years of experience in? Fortunately, we had some real cheerleaders on the client team, who understood the importance of good service design. Because they see there are other digital services on the market — with complex, professionally built software — that are simply not being used. The reason is, they are too complicated, and designed with only the machines in mind — and not the users.
That said, there were certainly some sceptics on the team as well. Which I personally find super useful — they are going to help us pick apart what needs to be picked apart, and raise issues that we might find out about a bit later otherwise. Also, if you can ‘turn’ them — you know you’re on the right track.
Since the topic was a bit farther from our core expertise, we took an unusual approach. Before we did any research we went head-first into a Design Sprint together with the client team.
0. The Sprint-First approach
Starting with the Design Sprint had a number of strategic advantages:
- It acted as a supercharged deep-dive into the topic for us. We got as many information about the industry as we possibly could in 5 days, with experts present — so we could always go even deeper
- Also, it wasn’t a ‘theoretical’ deep-dive — it was very practical, as we instantly had to use the knowledge to create a working prototype
- Creating the prototype (even if it’s just a few screens) also helps set the direction much better — you have to make clear decisions about what’s in, what’s out, and who are your main users.
- It also super quickly showed the client how we work — what’s the design process, and how we want to understand the users alongside the technology
- It helped create trust between the parties quicker — we were in the trenches together, and everybody delivered on their part!
- It also helped us plan our design research better — we had a clearer understanding of the stakeholders, the process and the end users.
So the interesting thing that we did here is that we flipped the design process — we didn’t use the design sprint to kick-start the design part or solve a specific problem. We used it to get a clearer understanding of the design area, the scope and to feed into our research.
It was important to state it right at the beginning that the prototype we make here might be very different from the final design — but it gives us something tangible to start off of. It’s sometimes easier for experts to comment on specific screens or functionality (what they like, what they miss, etc.) than to speak in the abstract. (We actually used both methods in our design research, because it brings out different insights.)
All in all, after the Design Sprint, we were ready to plan our design research. It included 1. shadowing different experts on the job, 2. process mapping (as-is and to-be) with a cross-functional team, and 3. a number of interviews with each different user-group (mechanics, diagnostics experts, project managers and B2B clients)
1. Shadowing experts on the job
Following along a ‘typical’ work process, observing the nuances and really understanding the context of future use is crucial in the design process — especially when the context is special. To really feel that wind, hear that noise, and understand other factors our experts might not be able to tell us in interview or workshop situations — simply because it’s so natural for them they don’t even think to mention it.
When shadowing, we tag along, observe, take pictures, make notes — and ask questions in-situ and after. (The narrower definition of shadowing doesn’t allow in-context questions — but since there was no interaction with clients that we would disrupt, there was space for questions).
Shadowing gave us a more nuanced understanding of the process and context — so we could even do prep-work for the journey mapping workshop that allowed us to be more efficient on the day.
2. Process Mapping (as-is and to-be)
The point of the mapping exercise was to see every step of the maintenance process (from routine maintenance to problem handling) laid out — so that 1. we could see otherwise ‘hidden’ steps as well, and 2. we could define together with the client which steps should the new software support — and what is out of scope.
You usually do journey mapping for one user type at once. But we had 3 key users whose jobs intertwined — so we wanted to see them on the same map. We also wanted it to be an ‘experience map’ — showing positive or negative feelings connected to each step, AND we also wanted to show what kind of tools are used at the specific steps. A bit complicated? Maybe, but also super useful. So we played around with different visualisations and ended up with a canvas that showed the main phases of the journey on top, the experience was signalled by the ‘traffic light lanes’ (green-good, yellow-indifferent, red-bad). And every user had their own post-it colour. We also used small icons for every step to show which tools are used.
To help our participants, we did a mock-up map of another — more everyday — process with multiple stakeholders: education.
Then, together with our team, we did the map of their own processes — and in the end, decided which steps should the new software support. It was useful to see through which tools these steps were currently done — from pen and paper through phone calls to computers. This helped us prepare for our interviews, and also create a new low-fidelity prototype — this time a list of the main features in an organised way.
3. Interviews with different user groups
The final, main step in our design research was user interviews. We did a number of individual interviews of all important stakeholder groups: mechanics, diagnostics experts, project managers and B2B clients. By this point we had a better understanding of each profile and the work they have to do, and how they might be able to use the product. We also had a clearer idea of our blind spots — what information we were missing. This allowed us to tailor the interview guides specifically to the different roles. The guides had two main parts:
- Filling in the blanks and expanding on the users’ everyday work and processes that are relevant for the new product — uncovering implicit needs
- Getting feedback on the iterated concept of the product: its features and contents based on the mapping workshop — and clarifying and complementing them with new, emerging needs — uncovering explicit needs
After the interviews we did classic synthesis (as in: organising and reorganising the information in different clusters until you go crazy and beautiful-mind the situation to get the most insights out of it).
In the end, what we handed over to the client and the UX design team were
1. Direct suggestions of the structure and features of the digital product
2. Suggestions about the implementation once the product is ready: how to communicate it internally and externally, and what kind of supporting processes and tools could be put in place to help successful adoption
1. Structure and features
- Key elements and information architecture of the digital product
- Key operating principles with examples
- Main data types the system has to handle — grouped together from usability perspective
- User stories for the input and output of those main data types. How they work now, and how they could change/be simplified with the new product.
- User needs per user types, connected to features, prioritised (also considering the different types of data that might or might not be available, depending on B2B client cooperation)
- Benefits of the proposed system compared to current system — connected to specific features and workflows
2. Suggestions about implementation and comms
- Based on our research we summarised what data sets are already available, and made suggestions on the process of entering and tagging new data
- We summarised the as-is state of the technological environment of users and made suggestions on how it should be upgraded / changed for optimal use of the software
- We listed the most important benefits for each user group — as they could be used in internal communications when introducing the new processes
- We made some suggestions about the process of the internal launch
- And also created a categorisation of their B2B clients, that can help define which messages and value propositions are most relevant for them during sales.
When we finished our final presentation to the team, we got some of my favourite feedbacks ever, emphasising how some people were a little worried in the beginning that we had no industry knowledge, but the results are genuinely useful, not just for the new software, but also for their everyday operations!
Because technically complex design can still be human centred!
