Strand 2 (Design): UX/UI Design Process — From Research to Usable Interfaces

Understanding the UX/UI Design Process (vision → journey mapping → wireframing → prototyping → strategy)

UX vs UI—what you’re actually designing

User Experience (UX) is the end-to-end quality of a person’s interaction with a product or system—how easy it is to accomplish goals, how confident they feel, and whether the product fits into their real life. User Interface (UI) is the specific set of screens, controls, visuals, and interaction patterns a user directly manipulates (buttons, menus, layouts, typography, icons, etc.).

They’re tightly connected: UX sets the “what and why” (what problem are we solving, for whom, and how will we measure success), while UI expresses the “how it looks and behaves” (what the user sees, taps, reads, and hears). A beautiful UI can still produce bad UX if it’s confusing, slow, or doesn’t match user goals.

Step 1: Vision—define the problem and success

A vision in UX/UI is a clear statement of what you’re building, who it’s for, and why it matters. It prevents the common failure mode of “designing screens” before you’ve agreed on the purpose.

A solid vision usually includes:

• Target users (not “everyone”) and their context (busy? low connectivity? on-the-go?)
• Primary jobs-to-be-done (the real-world goal, not just app features)
• Constraints (platform, time, brand rules, accessibility, legal)
• Success metrics (task completion rate, reduced support tickets, conversion, time-on-task)

If you skip vision, you often end up with a feature list disguised as a product—lots of functionality, but no coherent experience.

Step 2: Platform strategy—designing for the targeted platform

“Targeted platform” means the environment that shapes what good design looks like:

• Graphics/visual artifacts (posters, infographics, digital signage): success depends on attention, legibility, hierarchy, and message clarity.
• Applications (mobile/desktop/web): success depends on navigation, interaction patterns, responsiveness, accessibility, and error handling.
• Programming/interactive systems (tools, dashboards, games): success depends on workflow fit, feedback, performance, learnability, and system status visibility.

The same “feature” can require different UI solutions across platforms. For example, filtering items on mobile might need a bottom sheet and thumb-friendly controls, while desktop might use a persistent sidebar.

Step 3: Journey mapping—see the experience over time

A journey map is a structured view of the user’s experience across stages (before, during, after), including actions, emotions, pain points, and touchpoints.

Why it matters: users don’t experience your product as isolated screens. They experience it as a sequence—discover, decide, do, recover from mistakes, and return later. Journey mapping reveals where the real friction lives (often outside the “main feature”).

How it works (typical components):

• Persona or user segment (who the map represents)
• Scenario (what they’re trying to accomplish)
• Stages (e.g., discover → sign up → first task → ongoing use → support)
• User actions/thoughts (what they do and think)
• Pain points and opportunities (where you can improve)

Example (short): For an event-ticket app, the painful moment might not be “select seats” but “finding the confirmation email at the venue.” That insight changes design priorities (clear in-app ticket access, offline mode, QR brightness toggle).

Common mistake: making a journey map that describes the company’s internal process instead of the user’s lived steps.

Step 4: Information architecture and flows—decide how things are organized

Before drawing screens, you typically define:

• Information architecture (IA): how content/features are grouped and labeled
• Task flows/user flows: the step-by-step path through the system to achieve a goal

This matters because navigation problems are expensive to “paint over” later. If a user can’t predict where something is, no amount of visual polish fixes the underlying confusion.

Step 5: Wireframing—design the structure before the styling

Wireframes are simplified layouts that show structure and hierarchy without final visuals. They let you focus on:

• What elements are on the screen
• Relative priority (what stands out)
• Interaction placement (where actions live)

Why it matters: wireframes are fast to change, so you can explore multiple ideas before you’ve invested in high-fidelity styling.

Example: A checkout wireframe might test whether shipping details should be one page or a stepper flow. You can validate the flow with users before committing to UI detail.

Common mistake: treating wireframes as “already the design” and ignoring interaction details like error states and empty states.

Step 6: Prototyping—make it testable

A prototype is a representation of the product that users can interact with. Prototypes range from:

• Low-fidelity (paper sketches, clickable wireframes)
• High-fidelity (near-final visuals and interactions)

Why it matters: prototypes turn assumptions into observable behavior. People are often polite in interviews; prototypes reveal what they actually do.

How it works:

• Choose fidelity based on what you need to learn.
• Prototype the risky parts (new navigation, critical form, onboarding).
• Include realistic content when comprehension matters (labels, instructions).

Example: If you’re redesigning a settings menu, a clickable prototype can reveal whether users look for “Privacy” under “Account” or “Security.”

Step 7: Iteration and strategy—decide what to build and what to postpone

Strategizing is prioritizing design and development work based on user value, feasibility, and risk. In real projects, you cannot design everything perfectly at once—so strategy answers:

• What must be correct for the first release (core tasks)
• What can be improved later (secondary features)
• What data you’ll collect to guide iterations

A practical output of strategy is a plan for incremental improvement: test → refine → release → measure → refine.

Exam Focus

• Typical question patterns:
  • Given a scenario, identify which UX/UI step is most appropriate next (e.g., journey map vs wireframe vs prototype).
  • Explain how platform constraints change design decisions (mobile vs desktop vs static graphic).
  • Describe what each artifact (journey map, wireframe, prototype) is used for.
• Common mistakes:
  • Confusing UX with UI (describing colors/fonts when asked about user goals and flows).
  • Jumping to high-fidelity mockups before clarifying tasks and navigation.
  • Treating the process as strictly linear—real design is iterative.

Conducting and Analyzing End-User Research (focus testing, beta testing)

Research exists to reduce guessing

In UX/UI, research is how you replace “I think users will…” with evidence. The key is keeping the end user in mind—your goal is to understand their needs, context, mental models (how they expect things to work), and pain points.

Good research is not just collecting opinions. It’s observing behavior and interpreting it carefully.

Focus testing (commonly: moderated user testing) and why it matters

“Focus testing” is often used to mean structured sessions where you watch users attempt tasks and you learn where they succeed or struggle. (Some courses distinguish focus groups—group discussions—from usability tests—task-based observation. In many classrooms, “focus testing” points to the task-based kind.)

In task-based testing, you:

1. Define key tasks (e.g., “Create an account,” “Find and export a report”).
2. Recruit representative users (people similar to your target audience).
3. Run sessions (moderated or unmoderated), asking users to think aloud when possible.
4. Collect observations: errors, hesitation, backtracking, misclicks, questions.
5. Analyze patterns and prioritize fixes.

Why it matters: usability problems are often invisible to the design team because you know the system too well. Users reveal mismatches between your labels/structure and their expectations.

Example: You label a button “Submit Request.” In testing, multiple users say, “I’m not requesting anything—I’m just sending a message,” and hesitate. The fix might be as simple as renaming to “Send message,” but you wouldn’t reliably find that through internal debate.

Common mistake: asking leading questions like “Was that easy?” Instead, ask open prompts (“What are you thinking now?”) and rely on observed behavior.

Beta testing—learning from real-world use

Beta testing releases a near-finished product to a limited audience to catch issues before a full launch. Unlike lab-like usability sessions, beta testing exposes:

• Real devices and network conditions
• Real data, real accounts, real time pressure
• Edge cases you didn’t anticipate

Beta testing is especially valuable for:

• Performance and reliability issues
• Compatibility problems
• Confusing flows that only appear with real content

Example: Your prototype worked well with short sample names. Beta reveals that long names in real customer accounts break layout and hide critical buttons.

Common mistake: treating beta feedback as a vote (“people want Feature X, so build it”). Beta feedback needs triage: is it a bug, a usability issue, a misunderstanding, or a true feature gap?

Analyzing research—turning notes into decisions

Analysis is where many teams fail because it’s less exciting than running sessions. Strong analysis usually includes:

• Affinity mapping (grouping observations into themes)
• Severity and frequency ratings (how bad, how common)
• Root-cause thinking (why did this happen?)
• Actionable recommendations (what to change, not just what’s wrong)

A useful way to phrase findings is: Observation → Impact → Recommendation.

• Observation: “3/5 users missed the filter icon.”
• Impact: “They couldn’t narrow results, increasing time and frustration.”
• Recommendation: “Add a ‘Filter’ label and place it near the results count.”

Exam Focus

• Typical question patterns:
  • Distinguish what you learn from focus/usability testing vs beta testing.
  • Given user feedback, identify what data is meaningful and what is misleading.
  • Propose a simple research plan for a feature (tasks, users, what to observe).
• Common mistakes:
  • Testing with non-representative users (friends/classmates) and assuming results generalize.
  • Recording only opinions instead of behaviors (time, errors, confusion points).
  • Ignoring analysis—listing feedback without prioritizing or proposing changes.

Designing or Selecting Appropriate Icons for User Interaction Elements

What icons do in an interface

An icon is a small visual symbol used to represent an action, object, or status. In UI, icons often serve as:

• Action controls (search, share, delete)
• Navigation (home, back)
• Status indicators (battery, sync, warnings)
• Category cues (media types, file types)

Icons matter because they are a form of visual language. If the language is unclear, the user’s interaction becomes guesswork.

Choosing the right icon starts with the interaction element

A good icon choice depends on what the element is supposed to do:

• Primary actions should be obvious and often benefit from text labels, especially for less universal actions.
• Destructive actions (delete, remove) need clear signaling and often confirmation.
• Toggle states (mute/unmute, show/hide) require icons that communicate both states, not just one.

Think in terms of the user’s question: “What will happen if I tap this?” If the icon doesn’t answer that quickly, it’s risky.

Principles for designing/selecting icons

When you design or select icons, evaluate them against these principles:

1. Recognizability (semantic clarity): The symbol should match the user’s mental model. A magnifying glass for search is widely understood; a random abstract shape is not.

2. Simplicity and legibility at small sizes: Icons are often used at small scales. Too much detail turns into noise.

3. Consistency: Icons should match each other in style (stroke weight, corner radius, perspective) and meaning (don’t reuse the same icon for different actions).

4. Affordance and signifiers: A button needs to look tappable/clickable. The icon alone may not provide enough of a signifier, so the surrounding UI (button shape, hover state, placement) matters.

5. State and feedback: If the icon represents a state (favorite, muted), it should visually change when the state changes.

6. Accessibility: Icons should not rely on color alone to convey meaning. Where possible, include labels, tooltips, or accessible names so assistive technologies can interpret them.

Concrete examples

• Trash can vs “X” for delete: A trash can suggests deleting/removing content; an “X” often means close/dismiss. Mixing them can cause destructive mistakes.
• Gear for settings: Common convention. If you use a different symbol, you may increase search time and errors.
• Heart vs star for save: A heart often implies “like/favorite,” while a star can mean “favorite,” “bookmark,” or “featured” depending on context. If your feature is “save for later,” a bookmark icon may be clearer.

Common mistake: choosing icons based on what looks modern rather than what users recognize. Visual fashion changes; mental models change slowly.

Exam Focus

• Typical question patterns:
  • Given a UI scenario, select the most appropriate icon for an action and justify your choice.
  • Identify why an icon is ambiguous and propose a redesign (icon + label, different metaphor, better placement).
  • Explain how icon style consistency affects usability.
• Common mistakes:
  • Using an icon with multiple common meanings without supporting text.
  • Designing icons with too much detail to be legible.
  • Forgetting state changes (an icon that doesn’t reflect “on/off” causes confusion).

How Appropriate Iconography Impacts User Experience

Iconography is a speed tool—when it’s done right

Iconography is the system of icons used across a product. Good iconography improves UX because it reduces the effort needed to:

• Find actions
• Recognize functions
• Learn the interface
• Recover from mistakes (clear warnings and statuses)

If icons are consistent and familiar, users rely on recognition (seeing and knowing) instead of recall (remembering from scratch), which is cognitively harder.

How icons influence key UX outcomes

1. Efficiency: Users can act faster when icons are easily recognized and located.
2. Error rate: Ambiguous icons increase misclicks, including dangerous errors (e.g., confusing “delete” with “archive”).
3. Learnability: A consistent icon system teaches users the product’s “visual vocabulary.”
4. Perceived quality and trust: Sloppy or inconsistent icons make the product feel unreliable.

When icons hurt UX

Icons can damage UX when:

• The metaphor is culturally specific or outdated (users may not recognize it).
• Multiple icons look too similar at small sizes.
• Icons are used without labels for non-universal actions.
• Icon meaning changes across screens (“star” means “save” here, “rate” there).

Example: A paper airplane icon is sometimes used for “send.” If users interpret it as “share” or “forward,” they may hesitate at a critical moment (messaging, submitting a form). Adding a “Send” label can remove doubt.

A practical rule: label when the cost of misunderstanding is high

If misunderstanding causes:

• Data loss
• Money spent
• Public posting
• Account/security risks

…then rely less on icons alone. Combine icon + text, add confirmation dialogs, and provide clear feedback after action.

Exam Focus

• Typical question patterns:
  • Explain how icon consistency and recognizability affect usability outcomes (speed, errors, learning).
  • Diagnose a UX problem caused by icon misuse and propose fixes.
  • Compare icon-only navigation vs icon+label navigation for different audiences.
• Common mistakes:
  • Assuming “minimal” always means “better”—removing labels can increase confusion.
  • Overestimating how universal an icon is (users differ by age, culture, experience).
  • Ignoring the cost of errors when choosing icon-only controls.

Design Methodologies (Bottom-Up, Top-Down, Agile): Strengths and Weaknesses

Why methodology matters

A design methodology is a structured approach to planning and executing design work. It matters because your process affects:

• How quickly you can learn from users
• How well the final system holds together
• How easily you handle change

Different projects benefit from different approaches.

Bottom-Up design

Bottom-Up design starts by building and refining small components first (buttons, cards, form fields, micro-interactions), then assembling them into larger screens and flows.

Why it’s useful:

• Encourages consistency through reusable components
• Works well with design systems and component libraries
• Helps teams scale UI across many screens

Weaknesses:

• Risk of building polished parts that don’t solve the right user problem
• You may optimize components but miss flaws in the overall journey

Example: You perfect a “date picker” component, but later discover users rarely need to choose exact dates—they need quick presets (“This weekend,” “Next month”). The component-first focus delayed the more important insight.

Top-Down design

Top-Down design begins with the big picture (user goals, overall flow, information architecture), then drills down into screens and components.

Why it’s useful:

• Keeps design aligned with user outcomes
• Helps ensure the experience is coherent end-to-end
• Reduces the chance of local optimizations that harm the whole journey

Weaknesses:

• Can be slower to produce tangible UI artifacts early
• Without iteration, it can become overly theoretical

Example: For a healthcare portal, mapping the patient journey (appointments, results, billing, messaging) first prevents a situation where each section is designed in isolation with inconsistent navigation.

Agile (iterative, incremental development)

Agile is an approach where work is delivered in small increments, with frequent feedback and adaptation. In UX/UI contexts, Agile often means:

• Designing and validating in smaller chunks
• Collaborating closely with development
• Iterating based on real user feedback and data

Strengths:

• Handles changing requirements well
• Encourages continuous improvement
• Reduces risk by testing assumptions early

Weaknesses (common in practice):

• UX can become fragmented if there isn’t a guiding vision or design system
• Teams may focus on short-term deliverables and neglect holistic journeys
• If research is squeezed out, you end up with “Agile delivery” without “user learning”

A key Agile UX skill is balancing near-term sprint work with longer-term experience coherence.

Comparison table

Exam Focus

• Typical question patterns:
  • Given a project scenario, choose a methodology and justify with constraints (time, complexity, uncertainty).
  • Compare strengths/weaknesses of Bottom-Up vs Top-Down for consistency and user-goal alignment.
  • Explain how Agile supports iterative UX improvements—and what can go wrong.
• Common mistakes:
  • Treating Agile as “no planning”—you still need vision and research.
  • Assuming one methodology is always best; answers should be context-driven.
  • Describing methodology without connecting it to user outcomes (usability, coherence, learnability).

How Attention, Memory, Perception, Conditioning, and Learning Shape UX

The user’s mind is part of the interface

UX/UI design is applied human psychology. You’re designing for limited attention, imperfect memory, and fast (sometimes biased) perception. If your design fights human cognition, users will feel lost even if the system is “logically correct.”

Attention—what users notice (and what they miss)

Attention is the limited mental resource users allocate to information. Interfaces compete for attention using contrast, motion, placement, and relevance.

Why it matters: users often scan instead of read. If the most important element doesn’t stand out, users may never see it.

How it affects actions:

• Users miss critical instructions when they look like decoration.
• Too many competing elements cause attention dilution—nothing stands out.

Example: A sign-up screen with three equally bright buttons (“Continue,” “Learn more,” “Contact us”) may cause hesitation. Strong hierarchy (one primary action) guides attention.

Common mistake: adding more visual emphasis to fix confusion, creating even more noise.

Memory—recognition beats recall

Memory in UX often comes down to this: it’s easier to recognize something than to remember it unaided.

Why it matters: when your interface forces users to recall information (where a feature is, what an icon means), errors increase.

How to design for memory:

• Use familiar patterns and labels.
• Keep navigation consistent.
• Provide visible options rather than hiding everything.

Example: An icon-only toolbar may look clean, but if icons are unfamiliar, users must memorize them. Adding labels or tooltips shifts the burden from recall to recognition.

Perception—users interpret patterns, not pixels

Perception is how users organize and interpret visual information. People naturally group items, infer relationships, and prioritize what appears important.

Design implications:

• Group related controls together; separate unrelated ones.
• Use consistent alignment and spacing to communicate structure.
• Ensure text contrast and size support readability.

Example: If “Cancel” is placed close to “Save” with similar styling, users may perceive them as equally safe choices and make accidental taps. Separation and hierarchy reduce that risk.

Common mistake: assuming users perceive the interface the way designers do—especially when designers know what to look for.

Conditioning—behavior shaped by consequences

Conditioning (in a UX sense) means user behavior is influenced by feedback and outcomes. If an action reliably leads to a rewarding result, users repeat it. If the result is confusing or punishing, they avoid it.

In UI terms, conditioning shows up as:

• Clear feedback after actions (submitted, saved, error)
• Predictable outcomes (buttons that always do what they say)
• Reduced “gotchas” (unexpected fees, surprise deletions)

Example: If clicking “Save” sometimes fails silently, users learn not to trust the system and start taking workaround actions (screenshots, duplicate entries). Good feedback builds confidence.

Learning—your interface teaches users over time

Learning is how users build a mental model of your product. Interfaces that are consistent and predictable teach quickly; inconsistent ones force repeated relearning.

How to support learning:

• Use consistent patterns across screens.
• Provide onboarding only where it helps (not as a wall of text).
• Let users safely explore (undo, previews, confirmations for destructive actions).

Example: If swipe gestures do different things in different lists, users can’t generalize. If swipe always reveals the same actions, users learn once and reuse everywhere.

Exam Focus

• Typical question patterns:
  • Explain a UX problem using cognition terms (attention, memory, perception) and propose a fix.
  • Analyze why users make repeated errors and connect it to learning/conditioning (feedback, predictability).
  • Given two UI options, choose which better supports recognition over recall.
• Common mistakes:
  • Using psychology terms as buzzwords without linking them to interface choices.
  • Assuming users read everything—many users scan.
  • Ignoring feedback and error recovery, which strongly shapes learning and trust.

Usability Heuristics: Building a Better End-User Experience

What heuristics are (and what they are not)

Usability heuristics are widely used rules-of-thumb for designing and evaluating interfaces. They don’t replace user testing, but they help you quickly spot likely issues—especially early, when you’re working from wireframes and prototypes.

Why they matter: heuristics turn “this feels confusing” into a reasoned critique with a fix. They give you a shared vocabulary to evaluate design quality.

Common usability heuristics and how they improve UX

Below are heuristics frequently taught in UX education (often associated with Jakob Nielsen’s well-known set). The goal is not memorization for its own sake—the goal is to apply them to real screens.

1) Visibility of system status

Users should know what’s happening (loading, saving, syncing, errors).

• Improves trust and reduces repeated taps.
• Example fix: show progress indicators, success messages, and clear error states.

2) Match between system and the real world

Use language and concepts users understand—avoid internal jargon.

• Improves comprehension and reduces learning time.
• Example fix: rename “Initiate transaction” to “Pay now,” if appropriate.

3) User control and freedom

Users need exits: undo, cancel, back.

• Reduces anxiety and supports exploration.
• Example fix: allow undo after delete (when feasible) or provide confirmation for destructive actions.

4) Consistency and standards

Follow platform conventions and be consistent inside your product.

• Reduces cognitive load because users can transfer learning.
• Example fix: keep navigation placement consistent; don’t change icon meanings.

5) Error prevention

Prevent problems before they happen.

• Better than good error messages because it reduces harm.
• Example fix: disable “Submit” until required fields are valid; confirm destructive actions.

6) Recognition rather than recall

Make options visible; don’t rely on memory.

• Supports faster, more accurate interaction.
• Example fix: show formatting options in a toolbar instead of hiding them behind an unlabeled gesture.

7) Flexibility and efficiency of use

Support both novices and experts.

• Improves long-term productivity.
• Example fix: keyboard shortcuts on desktop; saved filters for power users.

8) Aesthetic and minimalist design

Avoid irrelevant information that competes with what matters.

• Improves attention and comprehension.
• Example fix: remove duplicate prompts; simplify copy; use whitespace for hierarchy.

9) Help users recognize, diagnose, and recover from errors

Error messages should be clear, specific, and constructive.

• Reduces frustration and support burden.
• Example fix: “Password must be at least 8 characters” instead of “Invalid input.”

10) Help and documentation

When help is needed, it should be easy to find and task-focused.

• Supports users in complex or high-stakes workflows.
• Example fix: contextual help near tricky fields; searchable help center.

Heuristic evaluation in practice (how you apply them)

A heuristic evaluation is a structured review where you inspect a design (wireframe, prototype, or product) and note where it violates heuristics.

A practical workflow:

1. Pick key tasks (the most important user goals).
2. Walk through the interface as if you’re the user.
3. For each friction point, name the heuristic being violated.
4. Propose a fix that addresses the cause, not just the symptom.

Example: Users repeatedly submit a form and nothing happens.

• Likely heuristic violations: visibility of system status (no feedback), error recovery (unclear errors).
• Fix: show inline validation, a clear loading state, and a success confirmation.

Common mistake: using heuristics to justify personal preference (“I don’t like this color”). Heuristics are about usability outcomes—clarity, efficiency, error reduction—not taste.

Exam Focus

• Typical question patterns:
  • Identify which heuristic is violated in a described interface problem and suggest an improvement.
  • Compare two design options and argue which better follows key heuristics (consistency, recognition vs recall, error prevention).
  • Explain why heuristic evaluation is useful before (and alongside) user testing.
• Common mistakes:
  • Naming a heuristic without explaining the user impact.
  • Proposing fixes that add complexity and create new problems (violating minimalist design).
  • Treating heuristics as strict laws—context matters, and user testing is the final check.