Building one stop shop for Picnic workers
Redesigning navigation to manage growing content, without frictionOverview:
Picnic workers relied on a patchwork of apps to do their jobs such as Slack for onboarding and comms, Google Forms/email for feedback and surveys, Workday for holiday requests, plus separate tools per operation (fulfilment, distribution, customer service).
It might seem normal for desk-based workers like designers or developers to juggle multiple platforms for different tasks. But Picnic's operations span a much wider range of users from tech-savvy students to workers who are barely familiar with smartphones.
This fragmentation was a major driver of new-joiner frustration, with turnover as fast as 8 weeks after onboarding. This project set out to identify the core pain points and build one effortless home for work and life admin at Picnic.
Contribution:Lead designer end-to-end problem discovery, concept design, through to detailed design implementation
Partnered with business stakeholders to shape requirements
Step-by-step how we tackle this mega app :
Scheduling / Availability / Holiday
- Workers didn't know how to complete basic tasks.
- Existing tools gave no clear instructions.
Procedure / Safety / Weather / Event updates
- Before a shift starts, workers want to know what task they'll be assigned so they can prepare (e.g. bringing a jacket if working in a chilled zone).
- No clear structure for where to check important announcements, or which ones were company wide.
- Work regulations and procedures were hard to find, so workers defaulted to asking their team lead, leading to long wait times, and team leads repeatedly answering the same basic questions.
Team communications
- Group channels made workers feel included.
- Announcements made via group chat were hard to find or reference later.
Payment / Hour balance / Payslips
- Workers had no transparency into pay and hours, resulting in extra admin work answering the same basic questions every payday.
Support
- Workers didn't know an FAQ hub existed, so they asked around informally instead.
- No clear structure for who to contact for which issue and getting in touch with the wrong person meant longer resolution times.
Step 2: Set design principles early
Picnic Ops spans multiple operations (fulfilment, distribution, CS), which meant multiple stakeholders with different needs. Design principles gave us a shared reference point, not just for design decisions, but for how the business and ops teams evaluated trade-offs too.
Self explanatory
Provide enough information to help users complete tasks in the easiest, most intuitive way possible.
Everyone, regardless of experience level, should know how to use the product and where to find help.
Everyone, regardless of experience level, should know how to use the product and where to find help.
Show their values
Create a rewarding experience that helps employees understand their achievements and stay engaged.
Be active and attentive
Clarify what just happened and what the next step is whenever we communicate with the user.
Always be comprehensive
Choose communication elements carefully. Avoid excess that doesn't add value, so users stay focused on their goal.
Step 3: Define high-level requirements with stakeholders
Mapped core functionality against nice-to-haves and prioritized, based on:
Whether the existing tool already worked fine
How frequently the function was used
Whether the existing tool already worked fine
🚨
Critical
Potential to become a blocker to operations; changes frequently based on business needs, and issues here require significant effort to resolve.
- 👉 Scheduling
- 👉Availability submission
- 👉 Hour balance
- 👉 Alert
👌
Nice to have
Current tools work reasonably well, with occasional issues that can be resolved with minimal support (team lead, dev, or admin).
- 👉 Help centre
- 👉Onboarding
- 👉Holiday submission
- 👉Announcement
- 👉 Chat / Communications
- 👉Payslip
Step 4: Build vs Buy. How can we make sure the chosen method the right direction ?
The central design question:
To answer this, we started mapping out how all the functionality would come together in one app.
Information architecture
We explored multiple IA structures to stress-test scalability, making sure the app could absorb future functions without needing a rebuild and validated them with workers, team leads, and ops staff.
Take the home screen as one example: defining the IA meant deciding what belonged in the main tabs versus the homepage, or whether certain functions (like availability) deserved their own tab. These decisions didn't need to be perfect. Each one would get a deeper dive once it moved into real development. They just needed to be solid enough to make a confident call and move forward.
Visual Direction
Our existing design system was built for operational complexity, not for a consumer-facing, engaging tone. So this needed its own visual language. We explored multiple UI directions to find one that felt approachable without losing clarity.
In parallel, the dev team investigated third-party feasibility and confirmed it: no existing solution could meet Picnic's requirements without compromising the experience. This gave the business a clear, evidence-backed case for building in-house.
Step 5: Deep dive, design, and implement
With the high-level plan in place, we moved into deep-diving each function individually and implementing them. As expected, scheduling turned out to be the core function which we've continued adding capability to, even today.
Scheduling
Check upcoming shifts, take or drop shifts, and adjust schedules within Picnic's planning regulations.
Availability submission
Let workers tell planners when they're available to work.
Approved hours
Track hours worked and see how much they'll be paid.
Holiday request
Submit and manage holiday requests directly in the app.
Submit and manage holiday requests directly in the app.
Impact:
Adopted by 10,000+ employees. Measurably improved shift transparency, reduced no-shows, and drew consistently positive feedback across fulfilment and distribution centers.
This is still an evolving product, not a finished one. Because everything is built in-house, existing functions, just new ones, stay open to revisiting. Every conversation with workers about a new feature tends to surface something about an existing one too, like a friction point we hadn't caught, or something working better than expected. That continuous discovery loop is part of what building in-house made possible.
We're also starting to explore AI to personalize the app for each worker, so they only see what's relevant to them and can stay focused on both work and personal life without unnecessary noise.
This is still an evolving product, not a finished one. Because everything is built in-house, existing functions, just new ones, stay open to revisiting. Every conversation with workers about a new feature tends to surface something about an existing one too, like a friction point we hadn't caught, or something working better than expected. That continuous discovery loop is part of what building in-house made possible.
We're also starting to explore AI to personalize the app for each worker, so they only see what's relevant to them and can stay focused on both work and personal life without unnecessary noise.