Aydınlatma metni yükleniyor…
UX stands for user experience. UX design is the process of researching, structuring, prototyping, testing and improving the whole experience—from expectations before arriving at a website through completing a task and receiving support afterward.
The objective is not to keep people on a site for as long as possible. It is to help them complete a real goal without unnecessary uncertainty, error or repetition. On one page, a good experience may mean finding reliable information and leaving quickly; elsewhere it may mean completing an application, purchase or account task. This guide separates UX from UI and usability, then turns research, design and measurement into a practical process.
What Is UX Design?
User experience is broader than the appearance of one screen. Findability, sequence, language, form behaviour, performance, accessibility, error recovery, support and continuity across channels can all affect the experience. UX design treats this system through evidence about users and tasks rather than assumptions about what people want.
Understanding a service and making contact on a corporate website, finding and managing an order in ecommerce, and completing a role-based task in a portal are different experience problems. One “modern design” treatment cannot answer all of them. Teams first define who is acting, what they need to achieve, the context and what a successful outcome means.
UX, UI and Usability Are Different
| Concept | Primary question | Example output |
|---|---|---|
| UX design | How should the whole task and experience be structured? | Research findings, journey, architecture, flows, prototype |
| UI design | How should the flow appear on screen and controls behave? | Hierarchy, components, states and responsive rules |
| Usability | How easily and effectively can someone complete defined goals? | Task scenarios, observations, success/error records and findings |
Digital.gov describes usability as one part of the wider UX umbrella and relates it to research-based evaluation of how people accomplish goals. (Digital.gov Usability) For interface appearance and interaction states, use the UI design guide.
Understanding Users Is More Than Demographics
Age, location or occupation may provide context in some projects, but they do not explain a need or predict how a website will be used. Two people in the same demographic group may have different goals, devices, experience, accessibility needs and time pressure. Research should move beyond “our users are 25 to 45” towards evidence about tasks, behaviours and barriers.
The GOV.UK Service Manual structures user research around understanding needs, preparing sessions, analysing findings and continuing research through different design phases. Interviews, contextual observation and usability testing answer different questions. (GOV.UK User Research) Select a method according to the decision the team needs to make.
Which Method Answers Which UX Question?
The following decision matrix connects a research question to usable evidence and a product decision.
| Question | Useful starting method | Evidence | Decision supported |
|---|---|---|---|
| What is the user trying to do? | Interviews, contextual observation, support records | Tasks, context, barriers and language | Priority user needs |
| How should content be grouped? | Content inventory, card sorting, tree testing | Expected groups and finding paths | Information architecture and navigation |
| Is the flow understandable? | Task-based usability testing | Hesitation, errors, outcomes and recovery | Flow and prototype changes |
| Where is the live-site problem? | Analytics, search, form and support signals | Points with loss or repetition | Research priority—not cause by itself |
| Did a change address the problem? | Repeated task testing and suitable product measures | Comparable before-and-after evidence | Release, revise or research again |
Analytics can indicate what happened but often cannot explain why by itself. Interviews reveal what people report, while observation and task testing show behaviour. Instead of applying one method to every question, examine whether different evidence supports or challenges the same interpretation.
A Website UX Design Process
1. Separate the business outcome from the user task
A business may want more qualified enquiries; a user wants to understand which service fits, its scope and the next step. A useful problem statement does not pretend these are identical. It identifies where a user task and a business outcome meet.
One main goal is not always correct for an entire site. Define priority and secondary tasks across relevant roles. Too many equally prominent actions can make a page difficult to interpret, but removing genuine user needs in favour of one campaign target also damages the experience.
2. Inventory the current experience and content
Review pages, search terms, forms, support topics, devices, redirects and technical constraints. Content quality is not a word-count question alone: is it accurate, current, findable, necessary for the decision and assigned to an accountable owner?
Long content is not automatically poor. A complex decision may require detail. The problem is unstructured information that does not follow the task. Use headings, summaries, detail layers and comparisons to put the right information at the right stage instead of cutting useful material indiscriminately.
3. Plan research questions and participants
Replace “do users like the site?” with questions that can change a decision: Which term do people seek? What information do they need before requesting a proposal? Why do they stop in the form? Participants should represent relevant target groups, important differences and access needs.
Define the method, tasks, recording, personal-data handling, consent, observer roles and analysis approach before sessions. Clients and colleagues provide essential business expertise, but they do not substitute for evidence about user behaviour.
4. Design information architecture and task flows
Content groups, naming, navigation and search should reflect tasks and expected mental models. Flows include not only the successful path but also missing information, permission, errors, cancellation, return and support routes.
Consistency between pages matters. If the same term, action or location changes unpredictably, people may have to relearn the system. Consistency does not make every page identical; it gives similar behaviour predictable treatment.
5. Expose assumptions through wireframes and prototypes
Wireframes make content and function priority discussable; prototypes model interactions for selected tasks. A prototype is not finished software, and its fidelity should match the research question. High visual detail too early can distract from structural problems.
Use realistic headings, choices, errors and content lengths. A flow built from empty boxes may become confusing or overflow when real data arrives.
6. Conduct usability testing
Give participants realistic tasks and observe their behaviour instead of asking whether they like the design. Moderators should avoid teaching the solution and seek to understand hesitation and expectation. Record findings with the task, context, recurrence and impact rather than as one person's preference.
Usability testing is not market research or stakeholder approval. It produces evidence about how particular people used a product in defined scenarios. Results should not be presented as universal behaviour beyond the participants and test scope.
7. Implement with development, content and accessibility
UX decisions should not stop at a design file. Content, UI, software, performance and technical constraints work together. Keyboard order, labels, errors, reflow, focus and assistive-technology behaviour need review in the implemented product. WCAG 2.2 provides testable success criteria for accessible web content. (WCAG 2.2)
Constraints found during development may change a design decision. Record the change and evaluate whether the user task remains intact, rather than checking visual similarity alone.
How Can UX Be Measured?
One universal UX score is rarely meaningful. Measures should connect to a predefined user task and business context. A plan may combine:
- Task outcome: Was the scenario completed, partly completed or completed with help?
- Error and recovery: Where did incorrect choices, repetition or abandonment occur?
- Time and steps: Were the time and effort appropriate for the context?
- Perception: What did participants report about confidence, clarity or ease?
- Live-product signals: Which research questions emerge from site searches, form errors, support topics and flow loss?
- Accessibility: Can critical tasks be completed through relevant input and assistive-technology conditions?
More time on site is not automatically positive; people may remain because they cannot find information. Bounce, page-view or conversion metrics do not explain the reason for an experience without context. Interpret quantitative signals with task observation, interviews and support evidence.
UX Review Checklist
- Are priority user groups described through tasks and context?
- Are business outcomes and user needs separate but connected?
- Do navigation, search and content labels reflect audience language?
- Are success, error and recovery paths defined for priority tasks?
- Is content layered around the decision and tested with real data?
- Have forms been tested with errors and corrections, not only ideal input?
- Have mobile, desktop, keyboard and assistive-technology paths been reviewed?
- Are research findings recorded separately from stakeholder opinion?
- Is evidence or an explicit assumption visible behind important decisions?
- Which tasks and signals will be measured after launch?
Common UX Design Mistakes
- Defining UX as keeping people on a site or making them like a design
- Reducing user research to age, gender and location
- Treating a business target as if it were the user's task
- Using surveys for every question or treating analytics as proof of cause
- Designing only successful paths and omitting error, recovery and support
- Assuming long content is always bad and removing necessary decision detail
- Confusing testing with a stakeholder presentation or preference discussion
- Failing to review the live implementation against research and accessibility needs
Conclusion
UX design is not a secret or a one-off visual treatment. It is a cycle of researching user tasks, structuring an experience, exposing assumptions through prototypes, testing realistic scenarios and measuring the implemented product. Start by writing the user question, the evidence needed for a decision and the task against which success will be reviewed.
To commission this work externally, use the UI/UX design agency guide to compare methods and deliverables, and the website requirements guide to turn decisions into project scope.