The brief
Users had years of muscle memory. A redesign could not break it.
Schedulers open StaffPoint at the start of the day and keep it open until the end. Many had used the same screens for years and knew exactly where everything was. They did not ask for a new look. They needed less friction in the work they already did.
A shift calendar, staff suggestions, automatic calls and texts, attendance tracking and billing, in one system.
Schedulers who fill shifts, client facilities that request them, and the staff who work them.
Every change had to feel familiar on day one. If people had to relearn the tool, the redesign failed.
My role
One designer, working with the owner and the developers.
I was the only designer, so every part of the design work was mine, from the first flow to the files developers built from.
- Working through problems and new ideas with the owner and the team
- User flows and high-fidelity screens for the web app and the staff view on mobile
- Clickable prototypes for sales demos and for developers
- A component set in Figma that developers built from
Approach
Keep the habits. Fix what surrounds them.
Old software is often hard to use for reasons that have nothing to do with the parts people rely on. I separated the two before changing anything.
- The colour code: red for open shifts, blue for booked, green for completed
- The day-by-day calendar schedulers read at a glance
- Where the main actions live in the navigation
- Clearer hierarchy, so the important detail on each screen is read first
- Long settings pages split into sections with a side menu
- Consistent buttons, spacing and form fields from one component set
- Layouts that work on a phone for staff away from a desk
Why the colour code stayed
It looks dated, but it is the fastest way to scan a week of shifts, and every user already knew it. Replacing it would have made the product look newer and work slower.
Healthcare first
Most of the work was shaped by hospitals and care facilities.
Most existing clients and most of the prospects the owner pitched were in healthcare, so I designed for their cases first.
- Last-minute shifts that need filling within hours, so open shifts had to stand out on every screen
- Staff qualifications and facility requirements, so the right person is suggested, not just the next free one
- Several people involved in one shift: the facility that requests it, the scheduler who fills it and the person who works it
Two roadmaps
Improving the product and selling it, at the same time.
Existing clients needed the tool to work better. New clients needed to see what it could become before they signed. Both landed in the same design queue, and priorities changed with every client conversation.
- Step 1BriefThe owner comes back from a client call with a need or an idea.
- Step 2FlowI map it out and agree the direction with the team.
- Step 3PrototypeA clickable prototype, often on a short deadline.
- Step 4DemoThe owner shows it to the client. What sells moves to development.
A prototype that helps close a sale is a design deliverable too.
I worked at two speeds: careful, gradual changes for people using the product every day, and fast, convincing prototypes for people deciding whether to buy it.
Exploring options
Options first, with the tradeoffs written down.
For the staff view on mobile I designed three layouts for the same list of open shifts, each with a short note on what it gains and what it costs. That way the choice was made with the reasons in front of everyone, not on taste.
Option A
A card per shift
Gains: every detail is easy to read. Costs: a long scroll on busy days.
Option B
Cards laid out like a table
Gains: shifts are faster to compare. Costs: denser to read on a small screen.
Option C
The week calendar, scrolling sideways
Gains: it matches the desktop calendar people already know. Costs: some shifts sit off screen, so the blocks are bigger and the last one is cut off to show there is more.
Handoff
Designed so developers could pick up one piece at a time.
I kept a component set in Figma, so developers could build each screen from parts they had already built once, instead of interpreting every screen from scratch.
Work was often interrupted. A new client request could move the team on before a feature was finished. Shared components meant the parts that did ship still looked and behaved like each other.
Where it stands
Partly shipped, and on hold for now.
Some of my designs shipped. The assignment details repository, released in early 2025, is one of them. Others were handed off and are waiting to be built.
In March 2026 StaffPoint paused product development.
I didn't have access to usage data, so this case study focuses on the decisions and how I made them. I'm happy to go through any of them in more detail on a call.
What I would do differently
Design in smaller pieces that can ship on their own. When development stops halfway, a small finished change helps users more than half of a big one.