Here’s a moment every owner who has paid for custom software will recognize. The mockups are approved. They look right. Engineering has them. Design, as a line item, is finished. From here on it’s just building.
It’s a milestone, not the finish line. Treating it as the finish line is one of the quieter ways a project ends up over budget and under-adopted.
What design is, for the person paying
Design isn’t pictures of screens. The pictures are the output. The work is figuring out what your people are actually trying to do, what the business needs the system to enforce, and where those two pull against each other. Then making something that resolves the tension in a way people will use without a training manual.
Design is where user needs and business objectives meet. Both keep moving during a build, so design has to keep moving with them. That’s why we run Strategy, Design, and Engineering as one team, not as three vendors handing documents to each other.
What changes after the mockups are approved
More than you’d expect, and most of it is predictable:
- Engineering hits a constraint the mockup didn’t account for. The data doesn’t exist the way the screen assumed, or the third-party system won’t return it that way. Someone has to redesign the screen, or you get an engineer’s best guess.
- The first working build goes to real users and they use it differently than the mockup imagined. The click-through was convincing. The real data and the real workload aren’t as tidy.
- The business changes. A new service line, a new location, a new compliance requirement, a big new customer with a specific demand. Six months is long enough for any of these to land.
- Scope gets controlled. Something has to be cut to fit the budget, and cutting a feature well is design work. Cutting it badly leaves a hole users fall into every day.
If design has left the building, each of these gets decided by whoever is closest: an engineer, a project manager, sometimes nobody. The system ships with the decisions baked in, and you find out about them from your people.
What it costs when design stops
The original version of this article listed six risks. Reduced to what an owner actually feels:
- Late changes are the expensive ones. A change on a mockup costs an hour. The same change after it’s built, tested, and wired to the database costs days. Multiply by everything engineering discovers along the way.
- People don’t adopt it. A system that doesn’t match how the work flows gets worked around. The spreadsheet comes back. You paid for a system of record and got a second one.
- Launch slips. Problems found late are found at the worst time, in the final weeks, when the fix is hardest and the date is already promised.
- You miss what the system could be. A designer who stays close to users spots the second and third thing the system should do. Nobody else on the project is looking for that.
The benefits are the same list run forward: issues caught while they’re cheap, a system people use on day one, a launch that holds its date, and a roadmap for what’s next that came from actual use rather than a guess in a conference room.
How we run it
Design starts in the VDP Sprint: a two-day face-to-face workshop, then design sessions about twice a week for three to four weeks, ending in click-through mockups of the key screens, written requirements, a tech-stack recommendation, and a roadmap with the investment. That’s where most of the validation happens, before we build anything.
Then design stays on the team. Through the build, the designer sits in the same meetings as the engineers, reviews what’s shipping against what was intended, puts each working release in front of the same small group of users, and adjusts. When scope has to be controlled to fit the budget, the designer is in that conversation, because deciding what to cut and how to cut it is exactly the skill.
After launch, the work shifts to what usage shows. Where people stall, what they never touch, what they ask for. That feeds the next release, and it’s a large part of why software is never done.
What to ask your partner
If you’re evaluating a firm, or you’re already in a build, three questions:
- Who owns design after the mockups are approved, and are they still on the project in month four?
- When do real users next see working software, and who is watching them use it?
- When scope has to be cut, who decides how?
If the answer to the first is “the developers” and the answer to the third is “the PM,” you’re paying for design as a one-time deliverable, and you’ll pay again later to fix what nobody was watching.
First step
For a new system, a VDP Sprint is where design starts, and where you find out what the system should be before you commit to building it. For a system that shipped and isn’t getting used the way it should, a System Evaluation is one to four weeks and tells you whether the problem is design, engineering, or something else entirely. Book a discovery call and we’ll tell you which one fits.