A design process can include interviews and still leave users with little influence over the result. If the roadmap is fixed before research begins and the release date leaves no room to act on testing, consultation becomes a record of problems the team has already decided to tolerate.
User-centered design makes an understanding of users, their tasks and their circumstances part of how a product is developed and evaluated. It is an approach to the process, not a single workshop or research method. Its commitments have a formal counterpart in ISO 9241-210 on human-centred design for interactive systems.
Understand the work before specifying the solution
In a fictional scheduling service, staff might request a faster way to change an appointment. Research could show that the real difficulty is coordinating the change with another person who cannot see the same calendar. The team still needs to design a solution, but it now has a more accurate account of the task and its constraints.
User research can establish who is involved, what they need to accomplish and which situations make the work difficult. Translate that understanding into requirements and evaluation goals that remain connected to the original need. “People can rearrange an appointment without losing the agreed time” is more useful than “the new calendar should feel intuitive”.
Users do not have to invent the solution for the process to be user-centered. Designers contribute alternatives and judgement, while research helps examine the assumptions behind them.
Give evaluation a chance to change the design
Build representations that can test the important questions at an appropriate level of detail. A sketch may be enough to discuss a workflow, while interaction, language or accessibility questions may require a more realistic prototype.
Use formative research to investigate difficulties and revise the design, allowing time for another round when significant questions remain. Later evaluation can assess performance against the intended goals. The process is iterative because learning can send the team back to its understanding of the task, not merely to the colour of a button.
Involve relevant disciplines in that work. A problem may require changes to policy, support or technical permissions as well as the interface. Treating the whole experience as a sequence of screens can leave the central obstacle untouched.
Make trade-offs visible
Different users may have conflicting needs. Administrators may want tighter controls while occasional users need a straightforward route through them. Research should clarify those tensions rather than invent an average user whose needs conveniently align with the proposed design.
Business and technical constraints still apply. Explain where a decision compromises an identified need, what the consequence may be and how the team will evaluate it. That is more accountable than labelling the final result user-centered simply because participants were consulted.
After launch, continue examining whether the product works in the circumstances it was designed to serve. Baseline measures, targeted research and feedback can help identify where the design needs to change as the service and its audience evolve.