Part 04 of 18

Design, Product Taste, Figma, and Visual Building

1. Purpose of This Part

This part defines the design roadmap.

Design is included in the master plan because building useful things is not only about making them technically work.

A technically correct product can still be confusing.

A powerful tool can still feel hostile.

A beautiful interface can still be unusable.

A clever app can still fail because the person using it cannot understand what to do next.

Therefore, design is not decoration.

Design is the discipline of making things understandable, usable, purposeful, and humane.

In this master plan, design must serve the same larger rule as every other domain:

Learning must become action. Understanding must become output. Curiosity must become service.

For design, the output is not only visual beauty.

The outputs are:

● wireframes ● prototypes ● design systems ● product critiques ● usability tests ● accessibility improvements ● interface redesigns ● implemented frontend components ● case studies ● better user flows ● clearer products

The long-term goal is:

To design things that people can actually use, understand, trust, and benefit from.

2. What Design Competence Actually Means

Design competence does not mean knowing how to make something “look nice.”

That is only one small part.

Real design competence means being able to understand the relationship between:

user needs
business goals
product purpose
technical constraints
visual hierarchy
interaction flow
accessibility
usability
information architecture
feedback
error states
trust
emotion
clarity

A serious designer-builder asks:

Who is this for?
What are they trying to do?
What are they feeling?
What do they already understand?
What language do they use?
What is confusing?
What can go wrong?
What should be obvious?
What should be hidden?
What should be prevented?
What should happen after success?
What should happen after failure?
Can this be used with a keyboard?
Can this be used on mobile?
Can this be understood quickly?
Can this be trusted?

The standard is:

Can I design and build something that helps a real human complete a real task with clarity, confidence, and minimal unnecessary friction?

3. The Research-Backed Source Spine

Design should be learned through a combination of official tool resources, usability principles, accessibility standards, and direct product analysis.

The main source spine for this roadmap is:

Figma’s own design basics and resource library, which covers fundamentals such as

UI/UX, prototyping, wireframing, web design, typography, color theory, and design principles. (Figma)

Nielsen Norman Group’s 10 usability heuristics, which include visibility of system status,

match between the system and the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency, aesthetic and minimalist design, error recovery, and help/documentation. (Nielsen Norman Group)

WCAG 2.2 from W3C, which gives recommendations for making web content more

accessible and organizes accessibility around the principles of perceivable, operable, understandable, and robust. (W3C)

Interaction Design Foundation’s design thinking material, which describes design

thinking as a non-linear, iterative process involving empathize, define, ideate, prototype, and test. (IxDF - Interaction Design Foundation)

Material Design 3 as a practical design-system reference for layout, interaction,

accessibility, styles, and components. Material Design describes itself as Google’s open-source design system with guidelines, styles, and components for creating user-friendly interfaces. (Material Design)

The rule is:

Use Figma to make the design visible, usability principles to make it understandable, accessibility standards to make it inclusive, and real testing to make it honest.

4. The Design Builder Identity

The identity to build here is not “graphic designer.”

The identity is:

     Human-centered builder.

A human-centered builder does not only ask:

     “Can I build this?”

They also ask:

     “Should this be built this way, and can a human actually use it?”

This matters because many technical people build systems from the inside out.

They think in terms of database tables, API routes, authentication flows, and component trees.

Those things matter.

But users do not think that way.

Users think:

● Where do I click? ● What does this mean? ● Did it work? ● What went wrong? ● Can I undo that? ● Is this safe? ● Why is this asking me this? ● What happens next? ● Am I lost? ● Can I trust this?

Design is the bridge between internal system logic and human experience.

5. The Design Roadmap Ladder

The design roadmap has layers. Each layer must produce visible artifacts.

Do not merely “learn Figma.”

Use Figma to think, test, document, and improve.

Layer 0 — Seeing Design

Purpose Before designing, learn to see.

Most people look at interfaces without understanding why they work or fail.

This layer trains visual and usability awareness.

Topics

layout
spacing
alignment
hierarchy
contrast
typography
color
affordance
feedback
navigation
consistency
visual grouping
empty states
error states
loading states
trust signals
mobile responsiveness

Practice Method Take real products and analyze them. Examples:

YouTube
Spotify
Amazon
Notion
GitHub
Linear
Stripe
Airbnb
Duolingo
ChatGPT
Apple settings screens
banking apps
university portals
government forms

For each product, ask:

What is the main action?
Where does my eye go first?
What is visually grouped?
What is confusing?
What is hidden?
What feedback does the interface give?
What would a new user struggle with?
What happens when something fails?
What design pattern is being used?
What would I copy?
What would I improve?

Required Artifacts Create a design-analysis repository or folder called:

    product-design-teardowns

Each teardown should include:

screenshots
product name
page or flow analyzed
main user goal
visual hierarchy notes
usability notes
accessibility concerns
what works well
what fails
redesign suggestions
lessons for future projects

Completion Standard This layer is complete when:

interfaces no longer look random
spacing, hierarchy, contrast, and flow become visible
good design patterns are recognized
bad design decisions can be explained clearly
at least 20 product screens have been analyzed

Layer 1 — Figma Fundamentals

Purpose Figma is the main tool for making design ideas visible.

The goal is not to become someone who only makes pretty mockups.

The goal is to use Figma to design, prototype, communicate, and test ideas before and during development.

Figma’s resource library includes design basics, UI/UX principles, prototyping, wireframing, typography, color theory, and web design material, making it a useful starting point for this layer. (Figma)

Topics

frames
shapes
text
images
layout grids
constraints
auto layout
components
variants
styles
variables
prototyping
comments
design files organization
export settings
developer handoff basics

Required Exercises Build in Figma:

Mobile login screen
Desktop landing page
Dashboard layout
Pricing page
Settings page
Table-heavy admin screen
Modal system
Form flow
Empty state
Error state
Loading state
Mobile navigation
Desktop sidebar navigation
Component library starter
Clickable prototype

Required Artifacts Create a Figma practice archive with:

screenshots
design file links if shareable
purpose of each design
what was learned
what was hard
what was copied from references
what was original
what would be improved

Completion Standard This layer is complete when:

Figma can be used without tool panic
screens can be laid out cleanly
auto layout is understandable
components can be reused
clickable prototypes can be created
designs can be translated into frontend code

Layer 2 — Visual Design Foundations

Purpose Visual design is how information becomes understandable at a glance.

This layer builds taste and visual control.

Topics Layout

alignment
grids
spacing systems
grouping
balance
density
whitespace
responsive layout

Typography

font pairing
type scale
line height
hierarchy
readability
labels
headings
body text
microcopy

Color

contrast
semantic color
brand color
neutral palettes
error/success/warning states
dark mode
accessibility contrast

Components

buttons
inputs
cards
tables
menus
tabs
sidebars
modals
alerts
badges
tooltips
toasts
forms

Material Design’s foundations are useful here because they organize interface guidance around accessibility, layout, interaction patterns, styles, and components. (Material Design)

Required Projects Design:

Personal portfolio homepage
SaaS landing page
Admin dashboard
Mobile habit tracker
Study planner interface
AI chat interface
Research paper tracker
Bug bounty report manager
Electronics lab inventory interface
Quantum/physics simulation dashboard

Completion Standard This layer is complete when:

designs look intentional rather than accidental
spacing is consistent
typography hierarchy is clear
colors have purpose
components are reusable
screens feel coherent as a system

Layer 3 — Usability Heuristics

Purpose This layer teaches how to judge whether an interface is usable.

Nielsen Norman Group’s 10 usability heuristics are a strong foundation because they summarize broad principles for interaction design, including system feedback, matching real-world language, user control, consistency, error prevention, recognition over recall, efficiency, minimalist design, error recovery, and help/documentation. (Nielsen Norman Group)

The 10 Heuristics as Practical Questions

1. Visibility of System Status

Does the user know what is happening?

Examples:

loading indicators
save confirmation
upload progress
current step in a flow
selected state
active navigation item

2. Match Between System and Real World

Does the interface use language and concepts the user understands?

Examples:

“Invoice paid” instead of “transaction state resolved”
“Upload file” instead of “create binary asset”
“Study session” instead of “temporal learning instance”

3. User Control and Freedom

Can users undo, cancel, go back, or escape?

Examples:

cancel buttons
undo actions
back navigation
confirmation before destructive actions
close buttons on modals

4. Consistency and Standards

Do similar things behave similarly?

Examples:

same button style for same action type
consistent navigation
predictable forms
familiar icons
standard keyboard behavior

5. Error Prevention

Does the design prevent mistakes before they happen?

Examples:

disabled submit until valid
confirmation for delete
input constraints
inline validation
sensible defaults

6. Recognition Rather Than Recall

Does the interface reduce memory burden?

Examples:

visible options
autocomplete
recent items
labels
examples
previews

7. Flexibility and Efficiency of Use

Can beginners and advanced users both work effectively?

Examples:

keyboard shortcuts
saved filters
templates
bulk actions
search
command palette

8. Aesthetic and Minimalist Design

Is the interface focused on what matters?

Examples:

no unnecessary clutter
clear hierarchy
only relevant information shown
progressive disclosure

9. Help Users Recognize, Diagnose, and Recover from Errors

Are errors understandable and fixable? Examples:

“Password must be at least 12 characters”
“Payment failed. Try another card.”
“File too large. Maximum size is 10 MB.”

10. Help and Documentation

Can the user get help when needed?

Examples:

tooltips
onboarding
help docs
examples
empty-state guidance
support links

Required Artifacts Create:

Heuristic evaluation of your own app
Heuristic evaluation of a bad university/government form
Heuristic evaluation of a popular SaaS product
Redesign based on the evaluation
Before/after writeup

Completion Standard This layer is complete when:

usability problems can be named
design critique becomes specific instead of vague
redesigns are justified by principles
your own projects are evaluated before being called finished

Layer 4 — Accessibility

Purpose Accessibility is not optional polish.

Accessibility is part of whether a product can be used by real people.

WCAG 2.2 is the key source here because it gives recommendations for making web content more accessible, and W3C summarizes WCAG around four major principles: perceivable, operable, understandable, and robust. (W3C)

The POUR Model Perceivable

Users must be able to perceive the information.

Practical examples:

● text alternatives for images ● sufficient color contrast ● captions where relevant ● readable text ● content not relying only on color

Operable

Users must be able to operate the interface.

Practical examples:

● keyboard navigation ● focus states ● no keyboard traps ● enough time to complete tasks ● clear navigation

Understandable

Users must be able to understand the content and interface.

Practical examples:

● clear labels ● predictable navigation ● helpful errors

readable language
consistent components

Robust

Content must work with different technologies, including assistive technologies.

Practical examples:

semantic HTML
proper ARIA where needed
valid markup
accessible component patterns

Required Accessibility Practices Every serious interface must check:

semantic HTML
heading structure
label/input association
button/link correctness
keyboard navigation
visible focus states
color contrast
alt text
form error messages
ARIA only when necessary
screen-reader basics
responsive behavior
reduced motion where relevant

Required Projects

Accessibility audit of personal website
Accessibility audit of React components
Keyboard-only navigation test
Form accessibility redesign
Color contrast correction pass
Accessible modal component
Accessible dropdown/menu component
Accessible table pattern
Accessibility checklist for all future projects
Accessibility case study Completion Standard This layer is complete when:

accessibility is considered during design, not after
forms are usable with labels and errors
keyboard navigation works
focus states are visible
color is not the only way information is communicated
accessibility notes exist in project documentation

Layer 5 — UX Research and Design

Thinking Purpose Design should not be based only on personal taste.

A product exists for people.

UX research and design thinking help connect design to real user problems.

The Interaction Design Foundation describes design thinking as a non-linear, iterative process used to understand users, challenge assumptions, redefine problems, prototype, and test solutions. Its common five phases are empathize, define, ideate, prototype, and test. (IxDF - Interaction Design Foundation)

The Five Practical Stages

1. Empathize

Understand the user.

Methods:

interviews
observation
surveys
diary notes
support-ticket analysis
watching people use a system
reading complaints and reviews

2. Define

State the problem clearly.

Bad problem statement:

    “Build a dashboard.”

Better problem statement:

“Students need a way to see what to revise next because their notes, flashcards, deadlines, and weak topics are scattered.”

3. Ideate

Generate possible solutions.

Methods:

sketches
user flows
crazy 8s
feature alternatives
“how might we” questions
competitor comparisons

4. Prototype

Create a low-cost version.

Examples:

paper sketch
Figma wireframe
clickable prototype
fake-door test
simple HTML mockup
no-backend demo

5. Test

Observe whether the design works. Methods:

watch someone use it
ask them to complete a task
note where they hesitate
record confusion
ask what they expected
improve the design

Required Artifacts Create a UX research folder for each serious project.

It should include:

target user
problem statement
assumptions
user stories
user flows
wireframes
prototype
test plan
test notes
design changes
final decision log

Completion Standard This layer is complete when:

designs are based on user goals
assumptions are written down
prototypes are tested before full build
user confusion leads to design changes
product decisions are documented

Layer 6 — Information Architecture and

User Flows Purpose Information architecture is how information is organized so people can find and understand it.

User flows show how people move through a product to complete tasks.

This layer matters because many products fail not because the UI is ugly, but because the structure is confusing.

Topics

navigation
page hierarchy
user journeys
task flows
content grouping
labeling
search
filtering
sorting
breadcrumbs
onboarding
dashboards
settings organization
empty states
progressive disclosure

Required Exercises For each app idea, create:

Sitemap
Core user flows
Primary action path
Failure path
New-user path
Returning-user path
Admin path if relevant
Mobile flow
Edge-case flow
Permission-based flow Example: Study Planner Flow User goal:

“Know what to study today.”

Flow:

Open dashboard
See upcoming exams
See weak topics
See recommended session
Start timer
Complete session
Mark confidence
Generate next recommendation

Failure cases:

no topics added
no exam date set
user skips session
user marks topic as still weak
user has too many overdue tasks

Completion Standard This layer is complete when:

products have clear structure before coding
navigation is intentional
user flows include failure states
screens are connected by task logic
users are not forced to guess where to go next

Layer 7 — Design Systems

Purpose A design system is a reusable set of design decisions, components, patterns, and rules. It prevents every screen from becoming a new invention.

Material Design is useful as a reference because it provides a broad open-source system of guidelines, components, and styles for user-friendly interfaces. (Material Design)

Topics

design tokens
colors
typography
spacing
shadows
border radius
components
variants
states
icons
form patterns
table patterns
navigation patterns
accessibility rules
documentation
component usage guidelines

Required Design System Components Build a personal design system containing:

Colors
Type scale
Spacing scale
Buttons
Inputs
Textareas
Selects
Checkboxes
Radio buttons
Toggles
Cards
Modals
Tables
Tabs
Sidebar
Top navigation
Alerts
Toasts
Badges
Empty states
Loading states
Error states
Charts/dashboard components
Command palette later
Mobile navigation

Required Artifacts Create:

Figma design system file
React component library
Storybook or component showcase later
usage documentation
accessibility notes
design decisions document

Completion Standard This layer is complete when:

new screens can be assembled from reusable components
component states are designed
frontend components match Figma
spacing and typography are consistent
design rules are documented

Layer 8 — Product Taste

Purpose Product taste is the ability to judge what should exist, what should not exist, what should be simple, what should be powerful, and what should be removed. Taste is built by exposure, critique, building, and watching people use products.

It is not only visual.

It includes judgment about:

● usefulness ● simplicity ● timing ● clarity ● scope ● feature priority ● workflow ● emotional feel ● trust ● speed ● user motivation ● product positioning

Product Taste Questions For any product, ask:

● What is the core promise? ● What is the first moment of value? ● What is unnecessary? ● What does the product make easy? ● What does it make hard? ● What does it assume about the user? ● What does it hide? ● What does it expose? ● What would make this 10x clearer? ● What would make this 10x more useful? ● What would make this feel trustworthy? ● What would I remove? ● What would I delay? ● What would I make impossible?

Required Artifacts Create:

1. Weekly product critique 2. Product teardown essays

Feature prioritization notes
Before/after redesigns
Product strategy one-pagers
“What I would change” essays
User-flow comparisons between competing products

Completion Standard This layer is complete when:

feature decisions become more disciplined
unnecessary complexity is easier to spot
good products can be explained clearly
bad products can be critiqued fairly
your own projects become simpler and stronger

6. Design Project Ladder

The design roadmap should produce a visible body of work.

Level 1 — Interface Copywork Purpose:

Train the eye and hand.

Copy high-quality interfaces in Figma.

Examples:

Stripe dashboard
Linear issue page
Notion document page
Apple settings screen
GitHub repository page
Airbnb listing page
Spotify playlist page
YouTube video page Rules:
copy spacing carefully
copy hierarchy carefully
identify components
write what was learned
do not claim it as original work

Output:

Figma file
screenshot
analysis notes

Level 2 — Redesign Bad Interfaces Purpose:

Learn improvement.

Choose confusing interfaces and redesign them.

Examples:

university portal
government form
old booking page
bad checkout flow
messy dashboard
confusing settings screen
poorly designed mobile form

Output:

original screenshot
problem list
heuristic evaluation
redesigned wireframe
final redesign
explanation of improvements Level 3 — Design Your Own Small Apps Purpose:

Connect design to your own project ideas.

Examples:

habit tracker
study planner
flashcard dashboard
revision calendar
bug bounty note manager
research paper tracker
electronics lab inventory
AI prompt/eval dashboard
personal finance tracker

Output:

user problem
user flow
wireframes
final Figma screens
clickable prototype
frontend implementation

Level 4 — Design Systems Purpose:

Create reusable product language.

Output:

Figma design system
React component library
documentation
accessibility notes
usage examples Level 5 — Usability-Tested Product Purpose:

Design against reality.

Choose one real project.

Process:

Define user and task
Create prototype
Ask 3–5 people to use it
Watch silently
Record confusion
Improve design
Test again
Write case study

Output:

test plan
notes
before/after screens
decisions
final prototype
case study

Level 6 — Portfolio Case Studies Purpose:

Turn design work into public proof.

Each case study should include:

problem
user
constraints
research
flows
wireframes
visual design
accessibility
usability testing
implementation
results
what changed
lessons learned

7. How Design Connects to Software

Design and software should not be separate worlds.

Every serious software project should have a design trail.

That trail should include:

Problem statement
User definition
User flow
Wireframes
Figma screen
Component list
Accessibility checklist
Implementation
Usability review
Post-build improvement notes

This makes software more serious.

Instead of building random features, you are building from human needs toward technical implementation.

8. How Design Connects to AI

AI products especially need design discipline.

AI systems can be powerful but confusing.

Good AI design asks:

What can the AI do?
What can it not do?
What should the user trust?
What should the user verify?
How are limitations shown?
What happens when the AI is wrong?
How are sources shown?
How does the user correct the AI?
What does the AI remember?
What should it not remember?
How does the user control outputs?
How are failures explained?

AI interface artifacts should include:

prompt input design
response display design
citation/source display
confidence or uncertainty display
edit/regenerate controls
memory controls
tool-use transparency
error messages
human review flows
evaluation dashboards

The design rule for AI:

Never design AI as magic. Design it as a powerful but fallible system that helps humans act better.

9. How Design Connects to Research and

Philosophy Design is not only visual.

It is also conceptual.

Research needs design because:

papers need structure
diagrams need clarity
experiments need readable presentation
dashboards need interpretation
literature maps need organization

Philosophy needs design because:

arguments need structure
concepts need definitions
distinctions need visual clarity
complex ideas need understandable presentation

Useful design artifacts for research and philosophy include:

concept maps
argument maps
literature maps
visual timelines
comparison tables
ontology diagrams
paper summary templates
research dashboards
interactive explanations

Design therefore supports the wider life plan, not only web apps.

10. How AI Should Be Used in Design

AI can help design, but it must not replace taste, judgment, or user contact.

Correct AI Use Use AI to:

critique a user flow
generate alternative layouts
identify missing states
create usability-test tasks
summarize user interview notes
suggest accessibility issues
write clearer microcopy - generate design checklist items

● compare design patterns ● help structure case studies ● produce first-draft product requirements

Incorrect AI Use Do not use AI to:

● invent fake user research ● pretend a design was tested when it was not ● generate pretty screens with no user logic ● avoid learning Figma ● avoid accessibility standards ● avoid watching real people use the product ● copy designs without understanding them ● replace product judgment

The AI Design Rule AI can generate options, but humans must judge usefulness.

11. Common Design Traps

Trap 1 — Pretty but Unusable A beautiful interface that confuses users is a failed design.

Rule:

     Test whether users can complete the task.

Trap 2 — Designing Without a User If there is no user, there is no design target.

Rule: Every design starts with a person and a task.

Trap 3 — Skipping Wireframes Jumping straight to polished visuals can hide structural problems.

Rule:

    Flow first, wireframe second, polish third.

Trap 4 — Copying Without Understanding Copying great products can train the eye, but blind copying creates shallow taste.

Rule:

    Every copied interface must include analysis notes.

Trap 5 — Ignoring Accessibility Accessibility cannot be added at the very end without cost.

Rule:

    Accessibility is part of the design from the beginning.

Trap 6 — No Error States Most beginner designs show only perfect success paths.

Rule:

    Design empty states, loading states, error states, and failure paths.

Trap 7 — Overdesigning Too many animations, colors, cards, and features can weaken clarity.

Rule:

    Remove until the purpose becomes obvious.

Trap 8 — Treating Figma as the Final Product A Figma file is not the product.

Rule:

    The design must eventually survive implementation and use.

12. First 12 Serious Design Artifacts

These are the first major design artifacts to create.

Artifact 1 — Product Teardown Archive A collection of interface analyses from real products.

Artifact 2 — Figma Fundamentals Practice File A file containing layout, typography, components, grids, and prototype exercises.

Artifact 3 — Personal Design System Colors, typography, spacing, components, states, and usage rules.

Artifact 4 — Personal Website Redesign A complete Figma-to-code redesign of your own public presence. Artifact 5 — Study Planner UX Case Study A full design case study for a real study/revision planner.

Artifact 6 — Admin Dashboard Design A table-heavy, filter-heavy, data-heavy dashboard.

Artifact 7 — AI Chat/Product Interface A serious AI interface with memory, citations, uncertainty, and tool-use states.

Artifact 8 — Research Paper Tracker Design A design for managing papers, notes, summaries, tags, and literature maps.

Artifact 9 — Electronics Lab Inventory Design A design for tracking components, datasheets, circuits, PCBs, and test equipment.

Artifact 10 — Accessibility Audit Report An accessibility review and improvement pass on one of your own projects.

Artifact 11 — Usability Test Case Study A documented test with real people using one of your prototypes or apps.

Artifact 12 — Design-to-Code Component Library A Figma component system implemented in React/TypeScript.

13. When to Move Forward

Do not move forward because you watched design videos. Move forward because artifacts show competence.

Move past Figma basics when:

screens can be built cleanly
auto layout is understandable
components and variants are usable
clickable prototypes can be made
designs can be exported or implemented

Move past visual basics when:

spacing is consistent
typography hierarchy is clear
color has purpose
components feel coherent
screens do not look accidental

Move past usability basics when:

heuristic evaluations can be performed
problems can be explained specifically
redesigns are justified by principles
your own products are reviewed before shipping

Move past accessibility basics when:

semantic structure is considered
keyboard navigation is tested
contrast is checked
forms are properly labeled
accessibility issues are documented

Move into advanced product design when:

real users have tested prototypes
design decisions are documented
product scope is controlled
usability feedback changes the design
design systems support multiple projects

14. The Design Standard

The final standard for this domain is:

I can understand a user, define a problem, design a clear solution, prototype it, test it, improve it, implement it, and explain every major design decision.

This is not about becoming a decorative designer.

It is about becoming a builder whose work is usable by actual humans.

Design is the discipline that prevents technical ability from becoming self-centered.

It forces the builder to ask:

  Did this actually help the person it was meant to help?