“We don’t need user research”
or the reality on the ground.
Project overview
Implement a shift change features between colleagues for a catering and hospitality app. When an employee is unable to work due to illness, they can request coverage by asking colleagues to take over their shift.
Challenges
Why this project ? Currently, employees handle shift changes through WhatsApp groups, where unrelated topics can quickly clutter the chat, making the shift change process lengthy, frustrating, and stressful—especially when the shift change has a very short deadline.
What is the vision ? (defined with the stakeholders) “We want to provide an easy, intuitive and quick way for employees to change shift between them so that they don’t need to do it on WhatsApp”.
My process
The design brief allowed me to identify the following challenges :
Limited user research and restricted access to users.
Balancing “enhancing the current design” with maintaining consistency using components that have known issues.
Constantly advocating for more user research and testing.
Limited autonomy in design decisions.
“We will test the solution once its implemented”.
Stakeholder management
Design brief
Adapt and gather data in every possible way
Split the overall task into “2-week-sprints achievable user stories” and prioritize them
Create the flow, test it if possible and iterate on feedbacks
Start design
Technical feasability meeting with engineering team & handoff
User research
How to gather data when you have a limited access to users with stakeholders acting like “The single of source of truth” ? You adapt.
User researchI perform high-Level research using ChatGPT (but always ask where the information comes from).
I found colleagues who are the closest to the clients. The stakeholder was actually the closest person to the clients.
I conduct research on my free time (not the best idea) by contacting people of my network working in the catering and hospitality field.
I advocate for user research, I advocate for user research and I advocate for user research.
What I did
User researchManagers prefer minimal involvement in the shift change process but still want final approval to account for differences in employee experience levels.
Employees typically arrange shift changes on WhatsApp, but they’re dissatisfied with this approach since group chats are often cluttered with unrelated topics.
When using group chats, important information about shifts can easily get lost, leading to miscommunication.
Due to the fast-paced nature of hospitality, employees frequently need to arrange shift swaps on short notice.
Quick access to available colleagues is essential so that employees can easily identify potential replacements for their shifts.
Employees often struggle to find available colleagues quickly, leading to stress when a shift needs coverage.
Key takeaways
User researchTo ensure we address the right problem, I suggested collaborating with the stakeholder to define a clear problem statement that summarizes the main issue we aim to solve with the flow.
How can we create a process that allows employees to swap shifts on short notice with minimal manager involvement?
Problem statement
Splitting & priorisation
After collecting all available data, I took time to break down
the shift change feature into smaller, manageable segments.
Splitting & priorisationSince we worked in two-week sprints, I collaborated closely with the stakeholder to break down the overall task into smaller, achievable segments fitting within each sprint.
Secondly, we prioritized tasks effectively—and then I got to work.
And I advocate for user research, I advocate for user research and I advocate for user research.
What I did
Splitting & priorisationBreaking down tasks allowed me to manage stakeholder expectations more effectively during feedback sessions, ensuring we stayed within scope and avoided tasks outside the story’s objectives.
As a result, I was able to reduce meeting times by up to 50%.
Key takeaways & challenges
Splitting & priorisationReminder: the task is about implementing a shift change features between colleagues for a catering and hospitality app. When an employee is unable to work due to illness, they can request coverage by asking colleagues to take over their shift.
The overall flow is now broken down into smaller, more manageable segments.
Step 1: An employee creates and edits a shift change request.
Step 2: Colleagues respond to the request.
Step 3: The employee selects a replacement and submits the request to the manager.
Step 4: The manager approves or rejects the replacement proposal.
Results
Build the flow
As I now know where to start, let's build a flow to solve the problem statement.
And guess what ? I was also able to negotiate 1. Single. User Test.
The flowCreate basic Figma components for the flow to streamline my work.
I used insights from research, stakeholders, and assumptions to conceptualize the flows.
What I did
The flowI worked in close collaboration with the stakeholder to build and refine the flows.
Since a flow can be difficult to visualize and understand, I paired it with “quick and dirty” wireframes to gain stakeholder buy-in.
However, the stakeholder already had a flow in mind, which often limited my autonomy in decision-making.
I advocate for more user research, I advocate for more user research, I advocate for more user research.
Finally, I was able to negotiate a single user testing session to validate the concept flow before moving into design.
Key takeaways & challenges
(I know, you see nothing on the picture. My point here is to show the combination of a user flow and basic wireframes).Testing
Let’s test our concept flow using the basic wireframes from the previous step.
And remember: we only have one user test.
TestingDoes the flow make sense?
What are the best entry points to access the feature within the app?
What information do employees and managers need on the different pages?
What do I want to discover ?
TestingGiven that I could only conduct a single user test, I decided that metrics like "task completion rate" or "error rate" wouldn’t be especially relevant.
Instead, I proposed creating an Excel sheet to structure our observations using a “severity scale” (Source).
Working collaboratively with the product owner, we developed an Excel sheet that includes key tasks (“create request,” “edit,” “validate,” etc.), personas (employee, manager), and the severity scale to organize feedbacks effectively.
What I did
TestingThe user “validated” the flow, noting its speed and clarity.
We gained valuable insights, especially for managers, about essential information to display when approving a shift change request (such as hourly cost, experience, and location).
The user raised concerns about the feature’s effectiveness for short-notice requests, stating, "We can’t rely on employees to check the app spontaneously for shift change requests.”
As a result, they emphasized the importance of push notifications to promptly alert employees to urgent shift changes.
However, I was unable to identify a clear access point, particularly given the limitations of testing with only one user.
Key takeaways & challenges
TestingYes, we had very relevant insights and the flow was “validated” by the user.
However, Can we say that our flow is “validated” when it was only tested by one user ?
Critical thinking
Design
Balancing “enhancing the current design” with maintaining consistency using components that have known issues.
DesignIn collaboration with the other designers, I started implementing the design using every current components we could use. I also make a list of variants and new components we need.
Find the balance between “use what we already have to bring consistency”, “improve when it is necessary” and “stay in the user story scope”.
Regular meetings with engineering team to talk about the technical feasability of the design.
What I did
DesignI had limited autonomy in design decisions because of the decision of the stakeholder.
I had to work with a chaotic and complex design system.
Finding the balance between "using existing components for consistency, even if they're poorly designed" and "improving them when necessary, considering time constraints."
Key takeaways & challenges
Design iteration for the shift change request form.
Check the CTA width by creating variants for all translations (English, French, German, and Italian).
Propose a new progress indicator component to address spacing issues on mobile, along with a quick accessibility color check (review this).
And after ?
As I write these lines, I'm in the process of finishing the design.
And after ?Because the stakeholder wants to implement the design before to test it, I will continue to advocate for more user testing before implementation.
In the same time, I will define metrics in case I manage user tests.
Once design is validated, I will work in close collaboration with other designers to implement components into the design system.
I will organize the handoff with the engineering team through collaborative “pair programming.”
What are my next steps ?
Food for thoughts
A critical reflection on what I could have done better.
Food for thoughtsWhat are the “rooms for improvements” ?
At times, I found myself over-engineering simple components.
Note to self: Remember the KISS principle (Keep It Simple, Stupid).
1
While creating flows, I developed wireframes to gain clarity. However, I may have spent excessive time on them and sometimes blurred the line between wireframing and prototyping.
Note to self: Remember that wireframes are low-fidelity, prototypes are high-fidelity, and always stay clear on the purpose of each task.
2
Although I divided the project into manageable segments, my time estimates were occasionally inaccurate, sometimes extending beyond the two-week sprint.
Note to self: Take time to not only break down overall tasks into user stories but also further divide each user story into specific tasks to better gauge the workload required to complete it.
3