The problem with trying to design everything upfront
Before I came across Lean UX, this was already something we had learned from building software for real businesses: people make better decisions when they can see and use a system, not just read about it.
Many projects still ask clients to judge a system while it is abstract. Everyone discusses screens, fields, permissions, reports and exceptions before anyone has used anything.
That can feel thorough, but it has a weakness: people are being asked to approve something they cannot properly feel yet.
They can look at a document. They can comment on the spelling. They can ask for a few changes. But until there is something on screen, using their own language and their own data, it is still partly imaginary.
Lean UX gives a name to a different way of working. It says: do enough thinking to move safely, but don’t pretend you can design the perfect answer in a meeting room. Build something small enough to test. Put it in front of people. Learn from what actually happens.
The problem with big upfront specifications
There is a quote from The Pragmatic Programmer that says this better than I can:
“When you force a business person to sign off on a requirements document, or get them to agree to a series of features, that is the equivalent of getting them to check the spelling in a document written in Sumerian.
“They’ll make some random changes to save face and then sign it off to get you the hell out of their office.
“Give them code that runs, however, and they can play with it. That’s when their real needs will surface.”
The Pragmatic Programmer
David Thomas & Andrew Hunt
That has always felt painfully accurate.
Most people don’t know exactly what they need from a system until they have something to react to. They may know the current job is messy. They may know a spreadsheet is doing too much. They may know handovers are being missed, approvals are slow, or customer promises are being tracked in someone’s head.
But turning that into a perfect specification is hard.
When you give people working software, the conversation changes.
They stop trying to imagine the system and start using it. They notice what is missing. They spot the field that has the wrong name. They realise the list needs a different sort order. They remember the exception case that never came up in the first conversation.
That is the point. The first version teaches you things the specification could not.
What Lean UX gets right
Lean UX still requires thought. The difference is that it treats early decisions as assumptions to test, rather than facts to defend.
The basic idea is simple:
- start with the problem
- identify your assumptions
- build the smallest working version
- test it with real people
- learn from what happens
- improve it
For software, that is important because many early decisions are guesses.
You might think:
- a manager needs a dashboard, when what they actually need is a daily exception list
- the key problem is reporting, when the real issue is that nobody trusts the data going in
- a process needs ten steps, when three of them turn out to be old habits rather than real requirements
The sooner those things surface, the better.
How this shapes a Day-1 Build
This is one of the reasons behind our Day-1 Build approach.
The first version is not supposed to be the final word on how your business should work. It is supposed to replace one real spreadsheet, list, inbox process or manual job with something your team can actually use.
Once that exists, the conversation changes. People stop guessing and start reacting to something real.
They can click around. They can enter a customer. They can update a status. They can see whether the list makes sense. They can tell us what feels wrong because they are no longer talking in theory.
That teaches more than spending weeks trying to perfect a document.
The aim of a Day-1 Build is not to solve every future need. It is to get one important part of the business out of the old way of working and into a live system quickly enough that real learning can begin.
The shorter the gap, the sooner you learn
Speed is not about rushing.
It is about shortening the gap between the idea and the evidence.
A slow software project can feel safe because everyone is still talking, planning and documenting. But that safety can be misleading. If the assumptions are wrong, a longer planning phase just gives those assumptions more time to harden.
A fast first version exposes reality sooner.
That doesn’t mean building carelessly. It means keeping the first job small enough to finish properly. It means choosing a real problem, agreeing what “usable” means, and resisting the temptation to include every possible future improvement.
The first version needs to work, not cover everything.
Good enough to use is enough to learn from.
What clients should expect
This way of working can feel different if you are used to traditional software projects.
You should expect fewer abstract conversations and more practical ones.
Instead of trying to describe a perfect system upfront, we are more likely to ask:
- what job are you trying to get out of a spreadsheet?
- who uses it?
- what information do they need?
- what gets missed?
- what slows people down?
- what does someone need to see first thing in the morning?
- what would make this good enough to use?
Those questions are deliberately plain. They are not about producing impressive documents. They are about finding the smallest working version of the system.
Once that version exists, better questions appear.
What Lean UX is not
Lean UX is not an excuse for making things up as you go along.
It isn’t a reason to ignore users, skip thinking, or avoid proper decisions. It isn’t “just build anything and see what happens”.
The discipline is in choosing the right first version.
Too small, and it doesn’t prove anything. Too big, and you are back to a slow project with too many guesses baked in.
The right middle ground is a version that does one real job well enough for people to use it, question it and improve it.
That is where the learning starts.
A simple example
Imagine a business using a spreadsheet to track customer renewals.
A traditional project might start by documenting every possible renewal type, reminder, exception, report and permission. That might be necessary eventually, but it is a heavy place to start.
A Lean UX approach asks a simpler question:
What is the smallest working version that lets the team stop relying on the spreadsheet?
That might mean:
- a list of customers
- renewal dates
- status
- owner
- notes
- next action
- a simple view of what is due soon
Once the team uses that, the real detail appears quickly.
They may need a better way to handle paused customers. They may need a reminder email later. They may need a manager view. They may decide one of the fields is unnecessary.
Those are much easier conversations once the first version exists.
Further reading
Interested in learning more about Lean UX? These are good starting points: