Fewer screens, a clearer product

To simplify a product interface, remove screens that do not hold their own decision. Two steps that ask the same question should be one step. A product gets clearer when the person can see the choice, make it, and recognize the result without passing through rooms that only exist because the file grew.

Extra screens feel like progress in a design review. They look like a map. In use, they spend attention before the job appears. Nielsen Norman Group's summary of page-visit research puts the average visit at a little less than a minute. A flow that opens five screens before the decision has often spent the visit on navigation.

Merge steps that share a decision

List the screens in the order a person meets them. Under each name, write the decision that screen requires. "Pick a lead." "Confirm the lead." "Choose a status." "Save." If two lines are the same decision in different clothes, they are one screen.

A confirmation screen is the usual duplicate. The person chose the lead, and the next screen asks whether they meant it, with no new information. Put the choice and the consequence on the same view. Let them undo. A separate "are you sure" page is justified when the action is destructive and hard to reverse. It is a stall when the action is ordinary.

Wizards create the same problem one page at a time. A wizard is right when each step needs different information the person could not have known earlier. A wizard is wrong when it is a form cut into four URLs so the team could ship incrementally. Combine the fields that belong to one object. Keep a step only when the answer changes what the next question means.

Got Next and Leadly, both public product interfaces in Hanabi's selected work, show the value of a focused surface. One helps someone discover and track what matters. The other helps a team move a lead. Neither promise depends on a long corridor of setup screens. When you are tempted to add a screen "so it has a home," ask which decision would be homeless without it.

Show less, keep the decision in reach

Simplifying is sometimes a merge, and sometimes a demotion. The screen stays, and the secondary material stops competing with the choice.

A trading or lead tool gets worse when it shows everything. Prices, notes, history, owners, tags, and charts all feel important to the person who built them. The person in the job needs one figure to change and one control to act. Trade Moai, a public trading-interface concept, is organized around fast scanning and clear positions for that reason. The rest can live one click away, in a detail view that opens only when someone asks.

Use this order on a crowded screen:

• The object, named in the product's words.
• The fact that changed, or the fact that requires a decision.
• The single primary action.
• A way to the supporting detail, closed by default.

If you cannot name the primary action, the screen is still a pile. Do not decorate the pile. Remove until the action is obvious, then put back only the detail that prevents a wrong action. A lead's company name prevents a wrong call. A lead's entire email history usually does not, not on the first view.

Density has a place. A person who does the job all day wants more on the screen than a first-time visitor does. Give the daily user a compact view after they have learned the path. Keep the first view sparse. Two densities is a smaller design than five pages that each show a slice of the same record.

How a screen sneaks back in

Screens return through reasonable requests. Watch for these, and answer them without a new page.

"We need a place for the edge case." Put the edge case on the same screen, behind the condition that makes it true. A new page for a rare branch teaches everyone the rare branch.

"Legal wants this visible." Place the sentence at the moment of the decision, beside the button. A policy page in the flow is where completion goes to die. Link out for the long text.

"The metric is important." If it changes an action, it belongs in the scan line. If it is for a monthly meeting, it belongs in a report, not in the daily tool.

"The empty version needs explaining." A sentence and one action can live on the empty screen you already have. An intro page before the empty screen is another door.

"The engineer already built the route." A route is cheap to keep and expensive to ask a person to understand. Removing a route is part of design. On a codebase the team owns, deleting a view is a normal change, not a retreat.

Write the reason next to any screen you keep. "This screen exists because the payment method changes the total" is a reason. "This screen exists because we had a route" is a clue that it can go.

A practical cut

Do this on the current flow before you redraw it.

1. Screenshot every step, including empty and error.
2. Write the decision under each shot.
3. Circle decisions that repeat.
4. Merge those steps on paper.
5. Cross out any shot with no decision.
6. Walk the shorter flow with one person who knows the job and did not design it.

Stop at the first merge that scares the team. Talk about the fear. Often the fear is "they might miss a field." Try the field on the merged screen, labeled, before you restore a whole step. Often the fear is "we will look smaller." A shorter product that completes is larger in the only sense that matters.

Keep a single parking list for what you removed. Review it when real use shows a missing decision. Restore a piece because someone failed a job, not because the list feels untidy.

The cut should survive contact with content. Try the merged screen with the longest real record you have. If the merge only works with a tidy demo row, the screen is still hiding a decision under a scroll. Split again only at that point, and split by decision, not by the old sitemap.

What clarity looks like afterward

The navigation gets shorter. The primary button shows up in the same place on the steps that remain. New people ask fewer "where do I go" questions and more "is this the right record" questions. The second kind of question means they have reached the job.

You will feel the absence of screens you were proud of. That feeling is not a requirement. If a removed screen solved a real decision, the test in step six will catch it within a day. Put that decision back. Leave the corridor out.

A small team can hold a short flow in their head. That is an operational advantage. The next engineer, the next founder demo, and the next customer all meet the same few screens. Document those screens, their empty states, and their errors. Ignore the slides that showed the product as a city of modules.

When the remaining screens are the ones people scan all day, the quality of that scan becomes the work. How to design a dashboard people can scan picks up there: what changed, what needs a decision, and what can wait.