The notification nobody thought about until the dev asked.

Process · 5 min read

The prototype was done. The client had reviewed it. The design looked solid. Then we got on a call with the developer to walk through the build, and within the first few minutes, one question changed the project.

The client was looking at the permit dashboard and said "when something escalates, does that automatically send an email to the manager? Or a text? Or do they have to log in to see it?" And I realised we hadn't designed for that. The escalation was visible in the interface. It turned red on the dashboard. But if the manager wasn't looking at the screen at that moment, they'd miss it entirely. A critical safety alert, sitting there unseen, because nobody had thought about what happens when the user isn't in the app.

The gap between design and reality

This happens in every project, not just safety apps. The design shows what the user sees when they're using the app. It doesn't always show what happens when they're not. Notifications, background alerts, emails triggered by system events, those sit in the gap between design and development. The designer is thinking about screens. The developer is thinking about systems. And the systems need to work even when nobody is looking at a screen.

In our case, the developer also asked about authentication flows. There were no sign-in or sign-up screens in the prototype. We'd focused on the product experience and skipped the entry point. The developer needed to know how workers get onboarded. Does the manager invite them by email? Do they get a temporary password? Can they sign up on their own? Those questions sound simple but each one is a flow that needs to be designed and built.

Then came the insurance details. The worker profile showed insurance information, but there was no flow for where that data came from. Does the worker enter it? Does their company provide it? Does the manager input it on their behalf? The screen showed the data. The system needed a source for it.

Developers see what designers don't

This is not a criticism of the design process. It's an argument for why the developer conversation is essential. Designers think in flows. Developers think in systems. A flow shows what the user does step by step. A system asks where the data comes from, where it goes, what triggers what, and what happens when something fails. Both perspectives are necessary and neither one catches everything on its own.

The developer on this project asked about seven or eight things that weren't in the prototype. Not because the prototype was bad. Because prototypes are intentionally focused on the user experience, not the back-end logic. That's appropriate for design. But before a single line of code gets written, someone needs to ask the system questions. And those questions almost always surface gaps.

Every gap found now saves money later

Here's the thing. Every one of those gaps was identified before development started. That means the notification system could be designed properly and included in the scope. The authentication flow could be added to the prototype. The insurance data source could be confirmed with the client. If those questions had surfaced during development instead, the developer would have had to stop, ask, wait for answers, potentially redesign, and then rebuild. That's expensive. Finding the gaps during the handoff conversation costs nothing except time.

If you're about to hand a design to a developer, expect this conversation. Welcome it. The questions they ask aren't holes in your design. They're the bridge between what the user sees and what the system needs to do. And that bridge needs to be solid before anyone starts building.

Sources
Design Handoff Best Practices (Nielsen Norman Group) - How to structure the transition from design to development for better outcomes.
Software Development Lifecycle (IBM) - The stages of software development and why requirements gaps compound as a project progresses.

Related blog posts:

Your developer is not your vendor →

What happens between the prototype and the App Store →

The difference between a designer and a developer →