Figma and the UI/UX Design Workflow

Introduction

Digital products are not successful merely because they function. They must also be understandable, usable, accessible, desirable, and appropriate for the people and situations in which they are used. UI/UX design provides the practices through which teams investigate user needs, define problems, develop solutions, test assumptions, and communicate decisions.

Figma is a collaborative, browser-based design platform that supports much of this workflow. It is commonly used to create interface layouts, design systems, interactive prototypes, presentation artefacts, and developer handoff documentation. However, Figma is not the design process itself. It is a tool within a broader human-centred process. Effective designers use evidence, reasoning, collaboration, and evaluation before treating a visual design as a finished solution.

This chapter introduces the relationship between user experience, user interface design, interaction design, prototyping, and human-centred design. It also explains how Figma can support activities from research and ideation through testing and delivery.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish UI design, UX design, and interaction design;
• describe a human-centred design workflow;
• explain the purpose and limitations of prototypes;
• compare low-, medium-, and high-fidelity prototypes;
• identify the principal features of Figma used in a design workflow;
• connect research findings to design decisions;
• prepare a basic Figma file for collaboration and developer handoff; and
• recognise ethical, accessibility, and governance responsibilities in interface design.

1. UI, UX, and Interaction Design

User interface design

A user interface (UI) is the point at which a person interacts with a digital product or service. UI design concerns the visible and interactive elements of that interface, including typography, colour, spacing, icons, buttons, forms, menus, images, layout, and responsive behaviour.

UI design is not equivalent to decoration. A visual decision can influence comprehension, trust, speed, error rates, and accessibility. For example, adequate contrast can make text readable, while a clearly differentiated primary button can help users identify the next appropriate action.

User experience design

User experience (UX) refers to the perceptions, emotions, behaviours, and outcomes associated with a person’s interaction with a product, service, or organisation. UX is broader than screen appearance. It includes whether users can find information, complete tasks, recover from mistakes, understand system status, and achieve their goals with reasonable effort.

UX design is therefore concerned with the whole experience before, during, and after an interaction. It may involve content, service processes, customer support, privacy communication, onboarding, and the relationship between digital and physical touchpoints.

Interaction design

Interaction design focuses on how people and systems respond to one another over time. It addresses questions such as:

• What action can the user take?
• What does the system do in response?
• How does the user know that the action was successful?
• What happens when an error occurs?
• What choices are available at each stage?

A button’s appearance is a UI concern; the action it triggers, the feedback it provides, and the consequences of that action are interaction-design concerns. The disciplines overlap, but they are not identical.

In professional practice, one person may perform several of these roles. The distinction is still useful because it helps teams identify the question being addressed.

2. Human-Centred Design

Human-centred design (HCD) is an approach that places people, their contexts, capabilities, goals, and limitations at the centre of design activity. It does not mean simply asking users what visual style they prefer. It requires designers to understand real situations, involve relevant people, evaluate proposed solutions, and revise designs in response to evidence.

A useful representation of the process is:

Understand context → Define needs → Generate ideas → Make prototypes → Evaluate → Refine and deliver

This sequence is iterative rather than strictly linear. Research may reveal that the original problem was incorrectly framed. Testing may expose a need for further research. Technical constraints may require a revised concept. Iteration is not evidence of failure; it is a method for reducing uncertainty.

Research and discovery

Research seeks evidence about users, tasks, environments, and organisational goals. Common techniques include:

• interviews, which explore experiences, motivations, and language;
• observation, which reveals actual behaviour and environmental constraints;
• surveys, which can identify patterns across a larger population;
• competitive or comparative analysis, which examines alternatives;
• analytics review, which identifies behavioural patterns in an existing product; and
• accessibility inquiry, which considers diverse abilities and assistive technologies.

Research findings should be recorded as evidence rather than assumptions. A statement such as “users are confused by account setup” is more useful when accompanied by observations, quotations, task failures, or support data.

Synthesis and problem definition

Synthesis transforms collected information into patterns and design implications. Affinity mapping, journey maps, task models, personas, and problem statements can help a team organise evidence.

A good problem statement is specific enough to guide design without prematurely prescribing a solution. For example:

New patients need a clear way to prepare for a remote appointment because uncertainty about documents, timing, and technical requirements causes avoidable support calls.

This statement identifies a population, a need, and a context. It does not assume that the answer must be a particular screen or feature.

Ideation

Ideation generates possible responses to a defined problem. Sketching, “how might we” questions, storyboards, user-flow diagrams, and collaborative workshops are useful because they encourage alternatives before the team commits to one design.

Ideation should be separated, at least initially, from evaluation. If every idea is criticised immediately, teams may select the first familiar solution rather than explore better possibilities. Evaluation becomes essential after alternatives have been made visible.

3. Prototypes and Fidelity

A prototype is a representation of a proposed product or interaction that allows an idea to be examined before full implementation. A prototype may be made from paper, static screens, connected frames, coded components, or a combination of media.

The appropriate fidelity depends on the question being investigated. Fidelity refers to how closely the prototype resembles the intended product in appearance, content, behaviour, and technical realism. Fidelity is not a simple quality scale: a low-fidelity prototype may be more appropriate than a polished one when the team is testing structure or concept direction.

A prototype should be judged by its purpose. If the question is “Can users understand the navigation structure?”, a wireframe may be sufficient. If the question is “Does the error message clearly explain how to recover?”, realistic content and interaction states are needed.

Prototype scope

A prototype is usually selective. It may cover one critical task rather than every feature. A narrow, testable prototype is often more valuable than a large but superficial collection of screens. Designers should identify:

1. the user task being represented;
2. the assumptions being tested;
3. the screens or states required;
4. the level of realism needed; and
5. the evidence that would influence the next decision.

States and transitions

Interactive products are not composed only of static screens. They have states such as default, hover, focus, loading, success, empty, disabled, and error. A useful prototype represents important states and the transitions between them. Omitting an error state can conceal a significant usability problem.

4. Figma’s Role in the Workflow

Figma supports design work through several connected capabilities. Its value is greatest when it reduces friction between thinking, making, discussing, testing, and communicating.

Files, pages, and frames

A Figma file can contain pages for research artefacts, exploration, wireframes, visual design, prototypes, and handoff. Frames represent screens, device canvases, or sections of a design. Clear page names and frame names help collaborators understand the file.

A practical structure might include:

• Research and constraints
• User flows and sketches
• Wireframes
• Visual exploration
• Components and styles
• Prototype
• Usability findings
• Handoff

The structure should reflect the project rather than become an administrative burden.

Shapes, text, and layout

Basic Figma objects include shapes, text layers, images, and vector paths. Auto Layout allows elements to respond to content and spacing rules instead of relying entirely on fixed coordinates. This is particularly useful for buttons, lists, cards, navigation bars, and responsive arrangements.

Constraints communicate how an object should behave when its parent frame changes size. Together, Auto Layout and constraints encourage designers to model relationships rather than draw isolated pictures. This improves maintainability and helps designs better represent different screen sizes.

Components and variants

A component is a reusable design object with defined structure and behaviour. Examples include buttons, input fields, navigation items, and cards. Components support consistency and reduce repeated editing.

Variants group related component states or properties, such as:

• Button: primary, secondary, destructive;
• Button state: default, hover, focus, disabled; and
• Input: empty, filled, error, success.

Components should not be created merely because reuse is fashionable. They should represent a meaningful recurring pattern. Poorly designed components can hide differences that actually matter, making the system difficult to adapt.

Styles and design systems

Styles or tokens can standardise colour, typography, spacing, borders, and effects. A design system combines these foundations with components, usage guidance, accessibility requirements, and governance. It is more than a library of attractive objects.

A design system should explain when a component is appropriate, what content it accepts, which states it supports, and how it behaves. Naming conventions, documentation, version control, and ownership are important when multiple designers and developers contribute.

Prototyping in Figma

Figma’s prototyping functions connect frames through interactions and transitions. A simple prototype might connect a home screen to a product-detail screen. A more developed prototype may include overlays, scrolling areas, variables, conditional paths, and interactive component states.

The prototype should represent the intended task flow, not merely demonstrate that screens can be clicked. Connections should have understandable triggers, such as tap, click, drag, or keyboard input, and should provide appropriate feedback. Designers should test prototypes on the target device or at a realistic scale because an interaction that appears clear on a large monitor may be difficult on a phone.

Collaboration and handoff

Figma enables multiple contributors to inspect and comment on the same artefact. Collaboration is most effective when comments identify a decision, question, or evidence rather than expressing vague preference. For example, “This label may be unclear to first-time users; interview participant 3 used a different term” is more actionable than “I do not like this.”

Developer handoff involves communicating dimensions, spacing, typography, assets, states, interaction rules, content requirements, and unresolved questions. Inspection panels can assist, but measurements alone do not specify behaviour. Handoff is therefore a communication activity, not an export button.

5. From Research to Testable Design

A disciplined workflow maintains a traceable relationship between evidence and design decisions.

From evidence to requirements

Research findings can be translated into experience requirements. A finding might be that users need to compare appointment times before selecting one. A corresponding requirement could be: “The booking flow must allow users to view available times and compare them without losing entered information.”

Requirements should distinguish:

• user needs, such as understanding or completing a task;
• business goals, such as reducing support demand;
• technical constraints, such as available data or platform rules; and
• compliance or accessibility obligations.

User flows

A user flow maps the steps required to complete a goal. It should include decision points, alternative paths, and failure or recovery routes. For instance, a payment flow may involve selecting an item, reviewing an order, entering payment details, receiving validation feedback, and confirming the transaction.

A flow is not the same as a screen inventory. One screen may support several states, while one task may cross several channels. The flow helps the designer decide which states and transitions must be represented in the prototype.

Testing

Usability testing asks representative participants to attempt realistic tasks while the team observes behaviour and listens to explanations. A basic test plan identifies the objective, participant characteristics, tasks, measures, procedure, consent process, and criteria for interpreting findings.

Useful qualitative observations include hesitation, repeated taps, misinterpretation, workarounds, and requests for clarification. Quantitative measures may include completion rate, time on task, or error count, but these measures require consistent task definitions and careful interpretation. A small test can reveal severe usability problems, but it should not be treated as statistically representative of an entire population without appropriate sampling and analysis.

Testing should avoid leading participants. Instead of asking, “Do you like this button?”, a facilitator might say, “You want to change your appointment. Please show me what you would do.” The purpose is to observe behaviour in relation to a goal.

6. Illustrative Case: Designing a Clinic Appointment Booking Flow

Background

The following is a fictional illustrative case. A community clinic wants to improve its appointment booking experience. Patients currently telephone reception because the online form is difficult to understand, especially on mobile devices.

Problem

Initial stakeholder discussions suggest that the problem is “the booking page needs a better visual design.” Research reveals a broader issue. Patients are uncertain about appointment types, cannot easily compare times, and receive weak feedback when information is missing. Some users also share devices with family members and are concerned about privacy.

Analysis

The design team conducts interviews with patients and reception staff, observes several booking attempts, reviews support-call themes, and examines the existing form. The team identifies four important needs:

1. explain appointment types in plain language;
2. make available times easy to compare;
3. provide immediate, specific validation feedback; and
4. communicate what personal information is collected and why.

The team defines a primary task: “Book a routine appointment using a mobile phone.” Secondary paths include no available appointments, an invalid date, and a session timeout.

Approach and solution

The team first creates paper sketches and a low-fidelity Figma wireframe. It tests the information structure before spending time on colour and visual polish. Participants compare two approaches: a long form and a staged flow. The staged flow performs better because it presents one decision at a time and preserves context.

The next Figma iteration uses medium-fidelity frames with realistic appointment labels. Auto Layout is used for appointment cards, and components represent input fields in default, focus, error, and completed states. A prototype connects the main path and includes an error recovery path.

After further testing, the visual design is developed using accessible text sizes, sufficient colour contrast, descriptive labels, and a clear confirmation screen. The confirmation includes the appointment date, time, location, cancellation instructions, and a reference number. A design-system page documents the components and states for developers.

Outcome

In this illustrative case, the team does not define success as producing attractive screens. Success is defined as enabling patients to complete the booking task with fewer misunderstandings and giving them confidence that the appointment has been recorded. The final design is delivered with a tested prototype, component specifications, content guidance, and unresolved-risk notes.

Learning points

The case demonstrates that:

• the initial visual complaint may conceal a workflow problem;
• low fidelity can prevent premature commitment;
• realistic content is essential for testing comprehension;
• error and privacy states are part of the experience, not optional additions; and
• Figma supports communication, but evidence and judgement determine design quality.

7. Accessibility, Ethics, and Responsible Practice

Designers have responsibilities to people who may be affected by their decisions. Accessibility should be considered from the beginning rather than added after visual design is complete. Relevant considerations include keyboard access, focus visibility, readable type, colour contrast, touch-target size, captions, meaningful headings, alternative text, plain language, and compatibility with assistive technologies.

A colour-only distinction is inadequate for many users. For example, an error should not be communicated only through red; it should also use text, an icon where appropriate, and a clear explanation of how to recover. Accessibility requirements vary by jurisdiction and product context, so teams should consult applicable standards and legal guidance, including relevant web accessibility standards.

Ethical practice includes obtaining informed consent during research, protecting participant data, avoiding unnecessary collection of sensitive information, and explaining how recordings or quotations will be used. Designers should be cautious with dark patterns: interfaces that manipulate users into actions they did not freely intend, such as hidden fees, confusing cancellation paths, or preselected marketing consent.

Figma files may contain personal information, research recordings, unpublished product plans, or credentials accidentally included in screenshots. Teams should use appropriate access controls, anonymise research data where possible, and follow organisational information-security policies.

AI and contemporary practice

AI-assisted tools can help generate copy alternatives, summarise notes, create exploratory variations, or identify possible accessibility issues. They do not replace research, professional accountability, or participant involvement. AI-generated content may contain inaccuracies, bias, privacy risks, or inappropriate assumptions. Designers should verify outputs, avoid placing confidential data into unauthorised services, and record where automated assistance materially influenced a decision.

8. Common Challenges and Best Practices

Common challenges

A frequent challenge is confusing stakeholder approval with user evidence. Stakeholders provide essential domain knowledge, but their preferences do not automatically represent user behaviour. Another challenge is polishing high-fidelity screens before the problem and flow are understood. This increases the cost of changing direction.

Teams may also create overly complex Figma files, duplicate components, use inconsistent naming, or fail to document states. A prototype can become a performance rather than an investigation if facilitators explain what users should do instead of observing what they naturally attempt.

Best practices

• Begin with a clearly stated user problem and intended outcome.
• Keep assumptions visible and identify which ones require testing.
• Match prototype fidelity to the decision being made.
• Use realistic content, especially for labels, errors, and confirmation messages.
• Model empty, loading, error, focus, success, and permission states.
• Use components and Auto Layout where they express genuine recurring relationships.
• Name pages, frames, layers, and components consistently.
• Record design rationale and unresolved questions.
• Test with representative users and realistic tasks.
• Include accessibility, privacy, and ethical review throughout the workflow.
• Treat handoff as an ongoing conversation with developers and stakeholders.

Chapter Summary

UI design concerns the visible and interactive elements of a product, while UX design addresses the broader quality and consequences of the experience. Interaction design focuses on the dialogue between people and systems, including actions, responses, states, and recovery from errors. These areas overlap and commonly operate together in professional practice.

Human-centred design is an iterative process of understanding context, defining needs, generating ideas, prototyping, evaluating, and refining solutions. Prototypes make assumptions visible and allow teams to investigate ideas before implementation. Low-, medium-, and high-fidelity prototypes serve different purposes; greater visual detail is not automatically better.

Figma supports research synthesis, wireframing, visual design, components, design systems, interactive prototypes, collaboration, testing, and developer handoff. Its effectiveness depends on how thoughtfully it is used. A strong workflow connects research evidence to requirements, user flows, interface states, tests, and delivery documentation. Accessibility, privacy, informed consent, ethical persuasion, and responsible use of AI are essential parts of contemporary UI/UX practice.

Key Terms

UI design: Design of the visual and interactive interface elements of a digital product.

UX design: Design of the overall user experience, including usability, usefulness, emotions, and outcomes.

Interaction design: Design of the actions, responses, states, and transitions between users and systems.

Human-centred design: An approach that centres people, their contexts, needs, and capabilities in design decisions.

Prototype: A representation of a proposed product or interaction used for learning and evaluation.

Fidelity: The degree to which a prototype resembles the intended product in appearance, content, behaviour, or realism.

Wireframe: A simplified representation of interface structure and information hierarchy.

User flow: A representation of the steps and decisions involved in completing a task.

Component: A reusable design object with defined structure, appearance, or behaviour.

Variant: A related version of a component representing a property or state.

Auto Layout: A Figma feature that arranges objects according to spacing and sizing rules.

Constraint: A rule describing how an object responds when its parent frame changes size.

Design system: A governed collection of design foundations, components, guidance, and usage rules.

Usability testing: Evaluation in which representative users attempt realistic tasks while researchers observe and learn.

Accessibility: The practice of making products usable by people with diverse abilities and technologies.

Information architecture: Organisation and labelling of content so that it can be found and understood.

Dark pattern: A manipulative interface practice that steers users toward unintended actions.

Developer handoff: Communication of design specifications, assets, behaviour, states, and decisions to implementation teams.

Design rationale: The reasoning and evidence supporting a design decision.

Review Questions

5 Short Answer Questions

1. What is the principal difference between UI design and UX design?
2. Why is interaction design concerned with states and feedback?
3. What is the purpose of a prototype?
4. Name two advantages of using components in Figma.
5. Why should accessibility be considered during early design stages?

5 Long Answer Questions

1. Explain the human-centred design workflow and discuss why it should be treated as iterative rather than linear.
2. Compare low-, medium-, and high-fidelity prototypes, including suitable uses and limitations for each.
3. Describe how Figma can support a project from wireframing through developer handoff.
4. Explain how research evidence can be transformed into requirements, user flows, and testable interface designs.
5. Discuss the ethical responsibilities of a UI/UX designer when collecting research data and designing user choices.

3 Analytical / Application Questions

1. A team has created polished screens for an online booking service, but users cannot identify which appointment type to select. Analyse what may have gone wrong in the workflow and propose an appropriate sequence of research, prototyping, and testing activities.
2. Design a Figma file structure for a small mobile banking project. Justify your choice of pages, component groups, prototype states, and handoff documentation.
3. A product manager requests a red-only error indicator because it matches the brand. Evaluate this request from a UI, accessibility, and interaction-design perspective, and propose a more responsible solution.

Multiple Choice Questions with Answers

Question 1

Which statement best describes user experience design?

A. It concerns only colour, typography, and visual decoration.

B. It concerns the overall quality, usefulness, and consequences of a user’s interaction with a product.

C. It is limited to writing software code.

D. It is the process of exporting assets to developers.

Correct Answer: B. It concerns the overall quality, usefulness, and consequences of a user’s interaction with a product.

Question 2

What is the primary purpose of a prototype?

A. To guarantee that the final product will have no defects.

B. To replace all forms of user research.

C. To represent a proposed solution so that assumptions and interactions can be examined.

D. To provide a permanent substitute for production software.

Correct Answer: C. To represent a proposed solution so that assumptions and interactions can be examined.

Question 3

Which prototype is generally most suitable for testing basic information structure before visual polish?

A. Low-fidelity wireframe

B. Final coded product

C. High-fidelity marketing page

D. Production analytics dashboard

Correct Answer: A. Low-fidelity wireframe

Question 4

What does interaction design primarily address?

A. Only the selection of brand colours

B. The actions, system responses, states, and transitions in an interaction

C. Only the legal ownership of images

D. The physical manufacture of a device

Correct Answer: B. The actions, system responses, states, and transitions in an interaction

Question 5

Which Figma feature is especially useful for arranging elements according to spacing and sizing rules?

A. Auto Layout

B. Comment deletion

C. Asset compression

D. Version naming only

Correct Answer: A. Auto Layout

Question 6

Why are component variants useful?

A. They prevent a design from having any interactive states.

B. They group related versions of a reusable component, such as default, focus, or disabled states.

C. They automatically conduct user interviews.

D. They replace the need for content design.

Correct Answer: B. They group related versions of a reusable component, such as default, focus, or disabled states.

Question 7

Which activity best represents usability testing?

A. Asking a stakeholder whether they like a colour palette

B. Observing representative users attempt realistic tasks with a design

C. Measuring the number of layers in a Figma file

D. Exporting every frame as a bitmap

Correct Answer: B. Observing representative users attempt realistic tasks with a design

Question 8

Which is an example of an accessibility problem?

A. Providing text and an icon in addition to colour for an error

B. Using visible focus indicators for keyboard users

C. Communicating an error only through the colour red

D. Writing clear instructions in plain language

Correct Answer: C. Communicating an error only through the colour red

Question 9

Why should a design team include error and recovery states in a prototype?

A. Users interact only with successful screens.

B. Errors and recovery paths are part of realistic product behaviour and can reveal usability problems.

C. Error states are required only for visual decoration.

D. They make research unnecessary.

Correct Answer: B. Errors and recovery paths are part of realistic product behaviour and can reveal usability problems.

Question 10

Which practice is most consistent with responsible human-centred design?

A. Collecting all possible personal data in case it becomes useful

B. Designing hidden cancellation paths to improve retention

C. Testing assumptions with representative users and protecting their research data

D. Treating stakeholder preference as conclusive evidence of user behaviour

Correct Answer: C. Testing assumptions with representative users and protecting their research data