Products and Delivery · Career & Wealth

Drawing pages as a project begins easily makes everyone feel work has started. Buttons, colors, and layouts exist and give people something to discuss. Yet a page can look complete while what its users must accomplish remains unclear.

I think several questions come first: who uses it, when, and where they go after this step. Feature names are only a contents list; connections between features determine usability. When parties understand usage differently, greater detail may mean more to overturn later.

Before design, walk through one concrete scenario. Explain what each person provides, sees, and ultimately receives. Record inconsistent understandings immediately. Once key questions are settled, turning them into pages gives communication shared grounds.

Of course, some ideas become visible only when drawn. Then use rough sketches to find problems without rushing to treat them as final. Preparation depends on what the next step must resolve. Using design to confirm requirements differs from treating unconfirmed design as development instructions.

“Hard to use” can mean many things. Someone does not know the controls, someone encounters a bug, someone finds the workflow awkward, someone wants an absent feature. Put all these into one change list, and the team quickly gets busy without necessarily solving the same kind of problem.

When problems arise, I prefer first distinguishing their nature. Unfamiliar operation needs explanation or training; promised functionality that fails needs fixing; unreasonable usage needs design review; new ideas need renewed requirements discussion. Different treatments require different participants and completion criteria.

When raising a problem, explain what you did, expected, and actually saw. Retain reproducible observations and let relevant people confirm. Discussion then moves from general usability to specific faults, and it becomes easier to judge whether changes affect existing use.

Classification cannot replace fixing or excuse delay. Advance clear problems and promptly verify unclear parts. Above all, do not call every problem user ignorance; that only deprives the product of feedback. Distinguishing problems first reduces detours and gets genuine needs handled.

Individual features can look normal while the whole task remains impossible. Submitting information does not mean the next person receives it; generating an order does not mean subsequent handling is arranged. Testing page by page easily misses problems between pages, people, and states.

I therefore focus on running the whole business process. From a real user’s position, take realistic data through the beginning, processing, and ending. View who acts, who waits, and who handles problems within one flow. A feature’s existence and a business task’s completion need separate confirmation.

Testing can advance alongside development. Check completed parts, connect available flows, and record and report problems. Waiting until everything ends for the first trial concentrates earlier misunderstandings at the finish, making once-timely adjustments rushed.

This does not mean incomplete versions can go straight to everyone. When unprepared, use sample data within a clear testing scope and know which steps cannot yet be completed. Staged testing finds problems early; final acceptance still returns to the agreed complete use. Judge less by interfaces, more by following the task.

In product discussions, ideas often multiply. Everyone adds a seemingly sensible feature, none apparently unnecessary on the list. But actual design, development, testing, and maintenance all require someone’s effort. Combined, these may leave a product perpetually almost finished.

I think we must return to the current problem. Without this feature, can the main usage flow still finish? Does it solve an existing problem or an imagined possible one? If the main purpose works without it, record it for later judgment after clear user feedback.

Explain cuts too. Tell participants what this round retains, postpones, and why. List fixes for completed parts and truly missing features for unfinished parts. Separating these shows whether the next step repairs the existing product or expands scope.

Doing less does not mean lowering basic quality or using deadlines to excuse unfinished critical flows. Preserve the completeness needed at this stage. Focusing energy on actual usage can bring a deliverable result closer than continually adding impressive-looking features.

Studying competitors’ new features is necessary. But we may not know why they built them, for whom, or alongside what business. Rushing to add every new button can turn our product into a compilation of competitors’ features.

I think updates should start with our own usage. Has the business changed, what problems do customers repeat, where is the current workflow awkward? Then examine how outside products handle similar problems. This yields comparable methods rather than a name we must follow.

When discussing features, check their connection to existing flows: who uses them, what information they need, whom completion affects. Without clarity, more features may also increase difficulty. Explaining actual operating needs gives technical updates a steadier direction.

Outside innovation may indeed reveal needs we missed. Try understanding it in a concrete scenario first, then judge adoption. Keep watching competitors while preserving choice. Products need continual change, but each change should ideally explain which user task it improves.