How I researched complex processes at Stuart from scratch.
Or a short guide about how to break down complexity and translate it to UX deliverables.
9 months ago I joined Stuart as a Product Designer, and started my journey into the world of logistics. I have never worked in such a dynamic and fast-changing environment before, and one of my biggest challenges was to quickly incorporate and research the Supply and Demand side of logistics from scratch.
Now, looking back to the beginnings of my journey at Stuart I can say it’s been an amazing time when I rapidly learned a lot; I believe I selected the appropriate set of exercises and I am excited to share it with the community. Maybe it will help another designer to start their journey smoothly into the complex domain!
Principal advice: Set your research goals.
When I joined Stuart we did not have a dedicated User Research Department, nor any urgent upcoming project. I adapted to the current situation (the cross-functional team I joined was in search of engineers, and the roadmap for the team was not defined yet) and set the goal of my research by myself, which was to holistically research the topic of Supply and Demand to get myself prepared for future projects.
Do: Talk to your manager, PM/PO, or whoever made a decision of you joining the project to understand what was the reason you are in the project/company, and/or collect their vision/expectations. Try to find out the current state of the project, what is the biggest need/problem the company needs to address. Is there any research done already about that topic? Depending on the answer, you should think of your research goals and methods.
Below I am sharing some advice based on my experience researching complex processes from scratch — meaning there was no research done before I joined, and no relationship established with my users and stakeholders.
Advice #1: Know who your user is.
Do: It’s extremely important to connect to the right people and ask them the right questions. How to identify the right people? Check the organisational chart, internal documentation (Confluence, Notion, etc.), simply ask whoever is onboarding you which people you should meet. Along with learning about company culture, building the right network are the most important steps of a newbie.
UX deliverable
Users- or stakeholders map. It’s needed to know the scale of your research (so you can estimate timeframes), and map out existing relationships (consider both official and unofficial), so once you start talking to your users you can link workflows/insights and grab a bigger picture.
Advice #2 & 3: Know what you’d like to learn from users, and what you’d like to achieve from the first touchpoint.
It sounds very cliche, but indeed it’s crucially important to identify what you would like to take from your touchpoint(s) with the user. Talking to experts in their domain could be challenging, because they have so much specific knowledge to share they simply might not know how to pass it on.
Do: Ask the right questions and frame the interview. Consider studying internal documentation of the department your user is working in if possible, and/or sector-related materials so you can have a better understanding of users’ pain points. Ask them what kind of projects they participate in, who they closely work with, what kind of tools they use, etc. Also, if you plan to collaborate closely with your users in the future, remember that the first touchpoint is not only about you learning about your user, but also an opportunity to get a buy-in from them! Explain what Product/UX design is about and how you expect the relationship with that person to look in the near future — maybe you are already planning some shadowing sessions, usability testing, or a second round of interviews?
UX deliverable — 1
Interview guide. First think of what you’d like to learn (goals), then translate it into questions (interview guide). Don’t forget about timeframing, introduction, ice-breaker (more in the next advice), closing and Q&A part.
UX deliverable — 2
Interview documentation. Once interviews/touchpoints are over, it’s important to document what users have shared with you. This can be a simple transcript where you group insights, empathy map, user journey, jobs to be done, etc.: whatever suits your research goals best, and would help you in the next phase of your research/project.
Advice #4: Treat your users as people, not robots.
Even though your users might do repetitive tasks and have very little “human” part in their daily routine, we are human after all!
Do: I always like kicking off the first interview by asking my users how they found their way to their workplace, what they like and dislike about their job, and what their daily motivation is. It always helps to break the ice and establish a human connection. Understanding what motivates your user is great knowledge you can benefit from in your future research and design processes!
UX deliverable
Ice-breaker part in your interview guide.
Advice #5: Sharing is caring.
Sharing your learnings, especially when you start investigating a topic no one has ever touched before, could be the most helpful thing you can do for your team and company. Even if you don’t know who can benefit from your research outside of your team, it’s still important to keep it accessible.
Do: Document your research in such a way that it can be shared to the biggest range of people. Share it actively (on Slack, email, calls) and passively (make it searchable).
Advice #6: Find your way to dive deeper into the problematic topic.
Once you feel comfortable with the domain knowledge, do not hesitate to run a second round of investigation.
Do: Find a method that suits your project goal best. Talk to the PM/PO if needed to align on what you’d like to clarify and what level of detail is needed. For the project we run I scheduled a set of shadowing sessions with a few users, where we asked them to perform their tasks and explain the decision-making process in detail.
UX deliverable
Depends on the problem/project. It could be an interview, shadowing/screen-recording session, survey, etc. As I was dealing with complex processes, I always liked to validate process diagrams I created after every shadowing session with users to be sure I interpreted all that I saw correctly.
After running all those exercises I closed the initial part of my research and really felt confident to embrace upcoming challenges (I am on it right now!). During my research process I heavily relied on Nielsen Norman group materials, here happily sharing some of them:
To watch:
To read:
What about you? Have you ever had an experience dealing with complex processes research? What would your advice be?
