User-centric design starts from the people who will use the software, and checks the result against what they need. Here are ten reasons it comes first on every job, and where each one shows in the work.
Meeting user needs
Put the needs of the people who use the software at the front of the work, and what you build answers the problems they meet every day, and can be checked against them.
A better experience
It shows up as a better experience. A customer finds the hours, the menu or the booking button where they look for it, on the phone in their hand, and comes back because it worked the first time.
Less friction, less frustration
Every obstacle is a small tax on the person using the software. Designed with them in mind, it charges less of it: fewer dead ends, fewer second tries, and the job gets done.
Higher adoption
Staff keep using a tool that fits how they already work, and quietly go back to paper when it doesn’t. Software nobody uses has cost its full price and returned nothing, so adoption is part of the result.
A competitive edge
Given a choice, people lean toward the software that does their job with the least fuss, and user-centric design is how a product becomes that software.
Lower support and maintenance costs
Software that meets its users’ needs from the start needs less support and less rework, and that saving keeps paying. On the code side, the lecture Functional Programming Maintenance Strategy covers what keeps software easy to maintain: small functions, strict types, tests and documentation.
Feedback and iteration
Asking users once makes asking again a habit. Their feedback feeds the next round of work, so the software keeps up as their needs change.
Trust
Software that does what it said, every time, earns the trust of the people who use it: the cook believes the sold-out list, and the customer believes the hours.
Less risk
Knowing the need before you build cuts the risk of software nobody wants, and of a project that fails or sits unused.
The purpose of software
Software exists to serve people and help them get something done. User-centric design checks the software against that purpose, story by story, before launch.
To try it, open a page you look after on your phone and find what most visitors come for, then reach it again on a computer with only a keyboard: each place you stall is a need the page doesn’t meet yet.
User-centric design is the principle the rest of the course checks against: the stories, the scenarios and the tests all start from what a user needs. The next lesson, on defining user stories, sets out what a story contains.