Building for collegues

UX research

Designing for colleagues

As designers, we often assume we understand our colleagues, what they do, how they work, and what they need. The truth? We usually don’t.

This case study is about what I discovered when I actually took the time to design for the people sitting across from me.

The problem

The problem you ask? Our colleagues weren’t really being designed for. We worked side by side every day, yet we barely understood how their tools, processes, and frustrations actually looked from their side. Everyone had their own way of doing things, but we were still designing based on assumptions.

I wanted to change that, to see what would happen if we stopped guessing and started designing with them, not just around them.

The goal

The goal was simple: understand how my colleagues actually work, not how I think they work. I wanted to uncover their real challenges, habits, and needs and then use those insights to design a solution that genuinely make their day easier. This meant listening more, observing closely, and designing a tools and processes that feel natural to the way they already get things done.

Let’s start with a little background:

About the company

4-sure technology solutions is a company aimed as providing service providers as a service (SPaaS), which means that we connect:

Service providers (think builders, plumbers, electricians, solar installers and many more)
Supply chain (think insurance companies, goods and services providers and retailers like Builders Warehouse and the like)
Every day, normal people (think of a home insurance holder).

We specialise in connecting and assessing relationships by creating digital solutions that make the relationship possible and easier to manage. This requires responsible and highly skilled individuals in relationship management to perform tasks and liaise effectively between the different parties, ensuring every step is memorable.

Things we are responsible for as the design team:

A mobile application for on-the-road service providers to get jobs and job information in real-time.
A web application for companies to get jobs from the supply chain.
A web application for retailers and suppliers to supply job-related services to on-the-road service providers for whatever they need, when they need it.
An internal web application to process claims and requests from individuals who need service providers.

The last point is our focus as we are designing for the colleagues.

How we designed for our colleagues:

Looking at the current internal process, we asked ourselves:

Who are our colleagues exactly?
What do they do exactly?
Why do they do what they do?
What challenges do they face daily?
What are some niche challenges they have that the current process doesn’t cover?
How can we use design to solve their problems?
What opportunities are there to explore and improve the processes?
What are some problems they’ve solved using manual processes that we can use to streamline all the processes?
Are we wasting time creating solutions they don’t use, or worse, they don’t need?
What other things do they need help with?
These questions, among others, can arise during team deliberations.

My role

As the UX researcher on the project, my job was to dig for truth.

This is what I decided to do:

Sit with colleagues in person.
Watch how they worked in real time.
Ask questions that cut past surface assumptions.
Bring back insights that the design team could actually use.

The process

Research - Ideate - Prototype - Test - Deliver

Research

Living in a remote world, you sometimes need to look people in the eye to get the answers to your questions.

46km later, here are some notes from the colleagues;

Notes in summary:

What we learnt:

We didn’t know what our colleagues actually do on a day-to-day basis, shocker!
There were too many manual processes for things that are partially covered by existing flows in the system.
Colleagues are trying to solve problems by introducing new processes, which slow down the initially planned and “known” flows.
The current system did not, in fact, account for what they do daily.

We used the information to create user personas to keep in mind the people we are designing and solving problems for: