11. Design

Estimated time to read: 138 minutes

Why wait?

"If I had asked people what they wanted, they would have said faster horses." (often attributed to Henry Ford, though historically unverified)

What this quote gets wrong: Users CAN tell you about their problems (slow travel, expensive upkeep, unreliable transportation).

What it gets right: Users might not envision solutions that don't exist yet (automobiles).

Lesson for designers: Don't ask users to design solutions. Understand their problems deeply through research, then design solutions they can evaluate through prototypes.

What you probably discovered:

• Your user didn't know where to start
• They expected feedback that wasn't there
• They couldn't find the "save" button
• They got confused by your labels
• The workflow felt clunky

Good news: These aren't YOUR failures - they're universal design challenges.

Now: Read the theory below. Every principle directly addresses a problem you just experienced. When you see "Visibility of system status" (Heuristic #1), you'll remember your user saying "Did it save?"

11.1 Design Theory (Fachgespräch 1)

Good design is not a talent you either have or don't — it is a craft, built on a set of learnable principles. Once you know the rules, you can systematically create, evaluate, critique, and improve any interface.

Why Design Matters

The design flaw: "Mr Gore's name was the second name on the left of the ballot paper, but voters had to punch the third hole to vote for him."

What prototype testing would have caught:

• Ask 5 voters: "Show me how you'd vote for Al Gore"
• Observe: "Why are you punching hole #3?"
• Fix: Redesign before printing millions of ballots

Your takeaway: Every principle in this chapter exists because someone, somewhere, shipped a bad design that caused real harm. Learn from their mistakes BEFORE you build.

11.1.1 Prototyping Approaches

Prototyping will save money and will help to produce the right product.

There are different types of prototypes. We will focus on horizontal prototypes.

• Horizontal: Basically the user interface for all features.
• Vertical: Implement a proof of concept of all your technologies and frameworks and validate how they fit together, learn, what is easy, what is tricky, get an idea for the implementation risks. The vertical prototype goes through all layers for a single feature -- not part of this course!

11.1.1.1 Fidelity Levels

Usually, one distinguishes between low fidelity and high fidelity prototypes

• low fidelity: e.g. paper prototypes are easy to create, easy to change, even by the customer itself and on the fly;
• high fidelity: digital mostly, could be clickable prototypes

11.1.2 Nielsen's 10 Usability Heuristics ¹

These heuristics are the industry standard for usability evaluations and hence for the design of a usable product.

1. Visibility of system status

   • System always shows what's happening (feedback within 0.1-1 second)
   • Example violations: No loading indicator, no save confirmation
   • Example fixes: Progress bars, "Saving..." messages, status updates

2. Match between system and real world

   • Use language and concepts from user's perspective, not system perspective
   • Example violations: Technical error codes ("ERR_404"), jargon
   • Example fixes: Plain language, familiar metaphors, user-centered terms

3. User control and freedom

   • Users need "emergency exit" (Undo, Cancel) for accidental actions
   • Example violations: No back button, can't cancel operation, no undo
   • Example fixes: Clear exit options, undo for destructive actions

4. Consistency and standards

   • Same words/actions mean the same thing everywhere in the system
   • Example violations: "Delete" in one place, "Remove" elsewhere for same action
   • Example fixes: Consistent terminology, follow platform conventions

5. Error prevention

   • Better to prevent errors than write good error messages
   • Example violations: Ambiguous buttons, no confirmation for destructive actions
   • Example fixes: Constraints (disable invalid options), confirmation dialogs

6. Recognition rather than recall

   • Make options visible instead of requiring users to remember information
   • Example violations: Must remember syntax, hidden features, unclear icons
   • Example fixes: Tooltips, visible menus, clear labels

7. Flexibility and efficiency of use

   • Shortcuts for experts, without hindering novices
   • Example violations: No keyboard shortcuts, can't customize workflow
   • Example fixes: Keyboard shortcuts, customizable settings, quick actions

8. Aesthetic and minimalist design

   • No irrelevant content – it competes for attention
   • Example violations: Cluttered screens, decorative elements, unnecessary text
   • Example fixes: Remove non-essential elements, progressive disclosure

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

   • Error messages in plain language, show problem and solution
   • Example violations: "Error 500", no guidance on how to fix
   • Example fixes: "Your session expired. Please log in again"

10. Help and documentation

    • If needed, easy to search and task-focused
    • Example violations: Generic FAQs, no search, not contextual
    • Example fixes: Context-sensitive help, searchable docs, tooltips

Suggested team activity: read and discuss examples, then map them to your own prototype issues:

• 10 Usability Heuristics Applied to Complex Applications
• Mobile Heuristic Principles
• 16 little UI design tips that make a big impact

Cross-reference: Many heuristic failures can be re-framed with concepts from the introduction (feedback, signifiers, mapping, cognitive load). Use both vocabularies when you argue for changes.

11.1.3 Gestalt

Gestalt Principles are principles/laws of human perception that describe how humans group similar elements, recognize patterns and simplify complex images when we perceive objects.

Hence, they are a great way to use them instead of frames or boxes etc.

11.1.4 Visual Hierarchy

Check your layout for a clear visual hierarchy

11.1.5 Color

The most emotional tool in your design toolkit.

Color does more than make an interface look nice — it directs attention, sets mood, and communicates meaning before a single word is read. But it's also the easiest tool to misuse. A jarring color palette drives users away instantly; an inaccessible contrast ratio makes your app unusable for millions of people.

Color is one of the most powerful tools in visual design because it can evoke emotions and change people's moods. A poor color scheme can immediately drive someone away from your website or web app if it is too intense and causes a visceral reaction.

11.1.5.1 The Color Wheel and Color Relationships

Don't guess — use structure. Color relationships defined on the color wheel give you schemes that are guaranteed to work together.

11.1.5.2 Shades, Tints, and Saturation

You don't need dozens of colors — you need one well-chosen base color and the ability to vary it.

• Tint = base color + white → lighter, softer (good for backgrounds, subtle emphasis)
• Shade = base color + black → darker, heavier (good for text, strong emphasis)
• Saturation = intensity of the color → high saturation = vivid, low saturation = muted

In practice: Most apps use 2–3 tints and 1–2 shades of their primary color. This keeps the palette cohesive while giving you enough variation to create hierarchy.

11.1.5.3 Color and Emotion

Color carries cultural and psychological associations. These aren't universal rules — they shift across cultures — but they are strong enough to consider when choosing your palette.

Different colors mean different things and convey certain types of emotions and feelings. If you're stuck trying to decide on a color scheme, think about the kind of feeling you want to evoke from your design and pick primary colors based on that.

11.1.5.4 Color and Accessibility

This is where color design becomes critical — not optional.

Rule 1: Contrast matters. Use a contrast checker — don't eyeball it.

Rule 2: Never use color alone to convey information. Some users can't distinguish red from green (color blindness affects ~8% of men). Always pair color with a second signal: icons, labels, patterns, or position.

Accessibility should be considered when picking color schemes, so use a contrast tester to ensure your text color is readable. Also, avoid using solely color to convey information, and include additional context like icons or labels along with the color.

Tools:

• WebAIM Contrast Checker — paste two colors, get instant pass/fail
• Figma accessibility plugin — check contrast directly in your designs
• Coolors — generate and explore color palettes with accessibility filters

Figma Color Wheel

Color Palettes Generator

Material Design Palette

We will discuss further accessibility issues in later in Diversity & Accessibility.

11.1.6 UX Laws

Why a choice is faster / safer / less error-prone

UX laws help you justify why a redesign likely improves efficiency and reduces errors. Use them selectively where they fit your findings.

Check the reference collection:

• Laws of UX

Fitts' Law figure and reference:

Typical applications

• Fitts' Law → touch targets, spacing, placement of primary actions (especially on mobile)
• Hick's Law → reduce visible choices, see also Working Memory Limitations.

11.1.7 Mobile Reach and "Zones"

Design for how people actually hold phones

Some users operate one-handed; many use two thumbs; grip varies by device and context. Use reachability as a basic check before moving to Figma.

Rule of thumb: primary navigation and frequent actions belong in easier-to-reach areas (often the lower portion of the screen).

11.1.8 UI Controls

Patterns reduce cognitive load and prevent errors

Before you digitize your prototype, make sure your screens use common control patterns appropriately. This reduces learning cost and supports "recognition over recall".

Decision/Form Controls:

• Radio buttons: one choice among a few mutually exclusive options (with a sensible default)
• Checkboxes: multiple independent selections (including none)
• Toggle/Switch: like a single checkbox with immediate effect (e.g. dark mode on/off)
• Dropdown/Select: many options, limited space, or >15 items
• Slider: continuous or discrete value within a range (e.g. volume, distance filter)
• Stepper: increment/decrement a numeric value (e.g. number of repetitions)
• Date/Time picker: structured date or time input — avoid free-text fields for dates
• Search bar: filter or find within large content sets
• Text field: free-text input — use input type (number, email) to trigger the right keyboard

Navigation controls:

• Bottom navigation bar: primary sections of the app (3–5 destinations, always visible)
• Tab bar: switch between related content views within one screen
• Hamburger menu: secondary navigation when screen space is limited — use sparingly on mobile
• FAB (Floating Action Button): single most important action on the screen
• Back button / AppBar: return to previous screen or parent context

Feedback controls:

• Snackbar / Toast: short, non-blocking confirmation ("Workout saved!")
• Progress indicator: linear or circular — always show when the app is working
• Dialog / Modal: requires user decision before continuing (confirm, cancel)
• Chips / Tags: compact labels for categories, filters, or selected values

Also:

• Icons need text labels for critical actions (especially for novices)
• Error messages should be clear, placed near the field, and avoid premature validation
• Onboarding only when there is a clear justification (unique workflows, required setup, strong personalization)

11.1.9 Guidelines

Each platform and big companies have their guidelines for UI-design. Follow the guidelines.

• Apple
• Google's Material Design
• Microsoft
• IBM
• SAP Fiori

11.1.10 Diversity & Accessibility

Make your design for all users and inclusive. You are the developer, you are responsible to code in a way, your app may be used by blind people, with different special input devices, you are responsible to remove the hurdles. It is only a little effort for you, if you do it from the first line of code, and it makes a big difference for people with a handicap. In addition, make your forms such, that only really relevant data is asked and avoid binary salutation. If you think of default values, take real statistics as a reason for the default value and not the majority of your dev team.

In general consider the following

• in forms ask for as few data as possible, include divers/other if salutation is required by the law
• check contrast (about 8% of the male are color-blind)
• check resizing font
• check tap size of targets and margin between targets
• check interaction with different input devices, do not rely on touch only
• check semantics, i.e. add text for fields, images, icons
• check simplicity, i.e. simple language, short sentences
• check if your layout works for right to left

11.2 Design Practice (For Project Phase - After FG1)

11.2.1 Paper Prototyping

Paper prototyping is the fastest way to explore and align on structure before investing in design or code.

• Why use it
  • Fast: 6–8 screens in 2–3 hours
  • Low cost: Paper, pens, sticky notes
  • Disposable: Easy to discard and redo—no sunk cost
  • Focused: Emphasizes structure, flow, and content over visuals
  • Accessible: Can be discussed with users or clients immediately and adjusted on the fly, without any tool knowledge
• Benefits
  • Easy to explore and compare alternatives
  • Encourages iteration and shared ownership
  • No design or technical skills required
  • Low barrier for stakeholders: users and clients can point, annotate, rearrange, and suggest changes directly
  • Reduces authority bias: Rough sketches invite honest feedback instead of polite approval
  • Supports collaboration: Everyone can participate equally, not just "the designer"
  • Keeps conversations at the right level: Decisions focus on structure and meaning, not colors or fonts
• Limitations
  • No real interactions (touch, gestures, animations)
  • Limited insight into visual polish or "look and feel"

For mobile app development paper prototypes are a good start for ideation. Create many as different as possible prototypes and test them with users. However, don't expect to come up with the perfect paper prototype with the first try.

Tips

• Use real device dimensions (print phone frame)
• Number screens (Screen 1, 2, 3...)
• Draw arrows for navigation
• Use sticky notes for:
  • Modals/overlays
  • Alternative states (loading, error)
  • Dynamic content

11.2.2 Quick Validation (Not Formal Testing)

Paper prototypes are for exploration. Before you invest serious time in a high-fidelity tool like Figma, you should stress-test your core ideas with quick user tasks and a small set of proven principles.

This is NOT formal usability testing (see Usability Evaluation for that). This is a quick sanity check to catch obvious problems early.

11.2.2.1 Task-based "Thinking Aloud — light"

At this stage, run a simplified usability test with your paper prototypes. You are not "testing the user" — you are testing your design assumptions.

What you need

• Paper prototypes of your MVP's core screens (6–8 screens are usually enough)
• 5–8 goals/tasks derived from your user stories (no click instructions)
• 1 moderator, 1 note-taker (optional), 1 participant (student of different team)

Good tasks describe the goal and context, not the UI actions.

• ✅ "You want to quickly check your last chest workout before starting today's session."
• ❌ "Tap the History tab and open the last workout."

How to run it (10–15 minutes per person)

1. Set context: "We're testing the prototype, not you."
2. Give one task at a time (written on a card).

3. Ask the participant to think aloud:

   • "What are you trying to do?"
   • "What do you expect will happen if you do that?"
   • "What are you looking for right now?"

4. Do not coach. If they get stuck, use neutral prompts:

   • "What would you do next?"
   • "What do you think this means?"

5. Capture breakdowns:

   • where they hesitate
   • where they misinterpret labels
   • where they take detours
   • where they expect feedback that isn't there

Cross-reference: Use the Gulf of Execution ("How do I do this?") and Gulf of Evaluation ("What happened?") from the introduction to categorize breakdowns.

Output: Short list of

• top 3–5 usability problems
• the evidence (what happened / quotes)
• suggested fixes (don't implement yet—first understand the cause)

For systematic usability testing: See Usability Evaluation chapter (5+ users, formal protocol, metrics)

11.2.2.2 Navigation

Make navigation and interaction deliberate

After your quick tests, your navigation should not be "random". Rehearse and document 3–5 core user flows for your MVP — one flow per core task.

Consider common navigation patterns (mix if needed):

Guideline: Keep important and frequent paths short.

There is no single standard for flow documentation. Create a small legend, sketch the flow, and check with your team if it is clear.

11.2.2.3 Apply Design Principles

Use heuristics to explain observed problems — not to "decorate" prototypes

After you have observed real breakdowns in your quick validation tests, apply the design principles you learned (Nielsen's heuristics, Gestalt, visual hierarchy, UX laws) to:

• name the problem precisely
• justify why it is a problem
• guide your redesign choices

Category your findings from the paper prototype test and check them against the principles you learned in FG1. Fix them before you go to the digital prototype.

11.2.3 Ready for Figma

When your paper prototype has survived:

• a quick task-based test (thinking aloud light),
• refined core user flows,
• a heuristic check informed by real observations,

…then you are ready to move to digital prototyping.

11.3 Figma or AI Tools

11.3.1 Path A: Design-Focused Teams

Flutter & Figma MCP

11.3.2 Path B: Fast Iteration (AI Tools)

11.4 Figma

Start with wireframes and then add details, colors, ... The most popular tool is Figma -- with your student account it is free.

• Wireframes show a skeleton view of the UI
• Identify screen areas where content is displayed
• Focus is on page layout not interaction

Figma is a great tool for digital prototypes. Make sure to learn it properly. There is more than squares.

Start with a page for your minimal design system Before digital prototyping, define your design tokens:

• Colors
  • Primary/Secondary (from brand or Material 3)
  • Semantic colors (success, error, warning)
  • Neutrals (backgrounds, borders, text)
• Typography
  • Heading scales (H1-H6)
  • Body text sizes
  • Font weights
• Spacing
  • 4pt/8pt grid
  • Consistent padding/margins

Then create a page with all your screens of your app, i.e. one page holds all screens.

To be able to do so, learn the basics:

• Frames
• layout grid
• styles
• components
• click prototype
• figma-shortcuts

If you prefer videos, check out

• basics
• styles, first 4 min
• grid
• auto-layout

With styles and components, you have one place where you need to change something. It is the same as with proper programming.

Further Reading

• Designing Consistently Using Grids, Colors, and Typography
• Creating and coding a Design System from scratch
• Designing and Prototyping Interfaces with Figma - Third Edition

11.5 Self-Assessment

11.6 Further Reading

Jenifer Tidwell, Charles Brewer, and Aynne Valencia. Designing interfaces: patterns for effective interaction design. O'Reilly, third edition edition, 2020. ISBN 978-1-4920-5196-1 978-1-4920-5191-6.

Jaleh Afshar. Chief design officers at work: insights and strategies from CDOs on the frontlines of innovation. Apress, 2025. ISBN 979-8-8688-1136-4 979-8-8688-1137-1 978-979-8868-81-8.