UI/UX Design

Every app, website and form you use was designed by someone, well or badly. This chapter explains what UX and UI design are, how they differ and how designers actually work. You will learn the Double Diamond, the four-phase process published by the UK Design Council in 2004, and why good designers spend so long on the problem before they draw a single screen.

You will then look at users, their goals and the context they work in, because the same screen can succeed in an office and fail on a crowded train. Finally, you will learn how teams measure good design with task success, time on task and Jakob Nielsen's ten usability heuristics. These skills matter in any role that touches a product, a service or a customer.

User experience (UX) design covers everything a person feels and does when they use a product or service: finding it, learning it, getting a task done and getting help when something goes wrong. User interface (UI) design is the part you can see and touch: the layout, buttons, type, colour and icons on each screen.

Don Norman and Jakob Nielsen of the Nielsen Norman Group give a clear example. A film review site can have an excellent search box and still deliver a poor experience if it only lists major studio films and you want a small independent release. UX asks whether the product solves the right problem. UI asks whether each screen makes that solution clear and pleasant to use.

In 2004 the UK Design Council published the Double Diamond, a simple picture of how design work moves. Each diamond first opens out, as you explore widely, and then narrows, as you choose. The first diamond is about the problem. The second is about the solution. The Design Council pairs the model with four principles: put people first, communicate visually and inclusively, collaborate and co-create, and iterate, iterate, iterate.

Laura, a product designer at a housing association in Leeds, was asked to "make the repairs form look modern". Before drawing anything, she read 200 recent repair requests and called 8 tenants. She found that 62 of the 200 requests were duplicates, which is 31 per cent (62 divided by 200). Tenants sent them again because they never received a confirmation. The real problem was not how the form looked. It was that tenants could not see what happened after they pressed Submit. Laura added a reference number and a simple status page. The visual refresh came last and took two days.

The common mistake is jumping straight into the second diamond. A team receives a request such as "add a dashboard" and starts designing screens. Weeks later it finds the dashboard answers a question nobody was asking. Discover and Define feel slow, but they are the cheapest place to be wrong.

Every design decision rests on three questions. Who is using this? What are they trying to achieve? Where, and under what conditions, are they doing it? The answers change a design far more than any style choice.

Goals sit at two levels. A task goal is concrete: book a doctor's appointment, pay a bill, choose a delivery slot. A life goal sits behind it: feel in control of money, or avoid taking a day off work. Good designers record both, because the life goal explains why people abandon a task that technically works.

Context means the device, place, time pressure, connection, skills and physical conditions around the user. ISO 9241-11, the international standard on usability, describes usability in terms of specified users with specified goals in a specified context of use. A design is never usable in general. It is usable for someone, doing something, somewhere.

The same banking app is used very differently by a commuter on a slow train connection, a shop owner serving customers at the counter and a retired teacher at home with time to read every word. Write the context down, because it is easy to forget once you are back at your desk.

Sam, a UX designer at a field services company in Denver, was redesigning a job checklist app for technicians. In the office the prototype looked fine: 10 out of 10 colleagues finished a sample job in under 4 minutes. Sam then rode along with 5 technicians. They wore gloves, worked in bright sun and often had no signal in basements. Only 2 of the 5 finished the checklist on site, a success rate of 40 per cent. Sam enlarged the tap targets, raised the contrast and let the app save offline. On the next ride-along all 5 finished, with a median time of 3 minutes.

The common mistake is designing for yourself. You are not the user. You know the product, you have a fast laptop and you are rarely in a hurry. Testing only with colleagues tells you how experts behave in ideal conditions, which is seldom how customers behave.

Good design is not a matter of taste. ISO 9241-11 frames usability through three qualities: effectiveness (did people complete the task?), efficiency (how much time and effort did it take?) and satisfaction (how did they feel about it?). Teams turn these into simple numbers they can track over time. Report time as the median rather than the average, because one participant stuck for ten minutes can badly distort an average.

Sara, a UX researcher at a bank in Kochi, tested the old and new versions of a bill payment flow with 12 customers each. On the old flow, 7 of 12 paid successfully, a task success rate of 58 per cent (7 divided by 12). On the new flow, 11 of 12 succeeded, which is 92 per cent. Median time fell from 3 minutes 40 seconds to 1 minute 50 seconds, exactly half. Those two numbers made the case to her product manager on a single slide.

You will not always have users to test with. Jakob Nielsen's ten usability heuristics, developed with Rolf Molich in 1990, refined in 1994 and still widely used, give you a checklist for reviewing a design. They include visibility of system status, match between the system and the real world, user control and freedom, consistency and standards, error prevention, and recognition rather than recall. A heuristic review finds likely problems fast, but it never replaces watching real people.

The common mistake is measuring what is easy rather than what matters. Page views and time on site can rise simply because people are lost. Always measure against the task the user came to do.

A good designer treats a request like "make it look modern" as a starting point, not a brief. They check the data, talk to real users and write down the actual problem before choosing a single colour. They set a baseline, such as task success or drop-off at one step, so the redesign can be judged on results. Visual polish still matters, but it comes after the team knows what it is fixing and for whom.