Start With the Problem, Not the Code

A software project often begins with a feature list: a dashboard, online payments, a mobile app, reports. Those features may all have a place. But a better starting point is a specific moment in someone’s working day that needs to improve.

Perhaps a shop owner enters the same sale in three places. Perhaps an administrator spends every Friday assembling attendance records. Perhaps customers cannot tell whether their order has been received. Each problem gives the project something concrete to solve.

Follow the work before designing the screen

Choose one everyday task and walk through it with the person who actually performs it. Ask what starts the task, what information they need, where they pause, and how they know it is finished.

Watch for the steps that happen outside the current system. A notebook beside the computer or a message sent to confirm a record can reveal a gap that a feature list misses.

Write the workflow in plain language. For example: “A customer submits an order. The team checks availability. The customer receives confirmation. The order is prepared and collected.” This is easier to discuss than a list of technical components.

Define what a better outcome looks like

A useful goal describes a change in the work. “Build a reporting dashboard” names an output. “Let the manager review today’s confirmed orders without collecting updates from three people” describes the intended benefit.

You can turn that goal into a few review questions:

• Can the right person complete the task without outside help?
• Is the information they need visible at the right moment?
• Can they correct a mistake without starting again?
• Does the system make the next step clear?

These questions give the team a practical way to assess a prototype.

Make the first release a complete small journey

A first release does not need every idea. It does need to complete the journey it promises. An order form without a way to manage received orders leaves the work unfinished.

Choose a narrow flow that includes the beginning, the important decisions, and a clear outcome. Keep a separate list for useful improvements that can wait. This makes the trade-offs visible without pretending the postponed ideas do not matter.

Review with real tasks

Instead of asking whether a screen looks good, ask someone to use it for a realistic task. Give them the information they would normally have, then observe where they hesitate.

Treat that hesitation as useful feedback. The label may be unclear, the sequence may be unfamiliar, or the system may be asking for information the person does not have yet.

The aim of planning is not to predict everything. It is to give the team a shared problem, a manageable first step, and a way to learn whether the work is helping. Code becomes much easier to judge when everyone understands what it is meant to improve.