Design Principles

01 Design Meaningful Systems, Products, or Services

Why it matters

A system that works but doesn't matter isn't a success. Meaningful design asks whether the thing you built actually changes something for the people using it - makes their work easier, their decision clearer, or their experience less frustrating.

If ignored

Teams can spend an entire semester building something technically correct that no one needed. Function is the floor, not the ceiling. Without meaning, the work has no lasting value.

Checklist

We have clearly defined what "success" looks like for the people using this system.Not just features shipped - but impact felt.
The system solves a real problem that real people actually have.Confirmed through interviews and evidence, not assumptions.
We have asked "does this matter?" at each milestone - not just at launch.
The measure of success is impact on real people, not just technical delivery.

Reflection Questions

→If this system disappeared tomorrow, would anyone notice?

→What specifically changes in someone's life or work because of this?

→Are we measuring the right things - or just the things that are easy to measure?

→Would the people we built this for say it was worth it?

02 User-First Design

Why it matters

You cannot design a good experience without deeply understanding who you are designing for - their context, their device, their environment, and their goals.

If ignored

You end up designing for yourself or your assumptions. The system may work technically but be completely misaligned with how real people work - leading to poor adoption and frustration.

Checklist

I know who my users are.Identify by role, context, and behavior - not assumptions.
I understand why they are here and what they are trying to accomplish.
I know what device and environment they will be using.Desktop, tablet, mobile, on the go, in the field - design for their reality, not yours.
Every decision has been filtered through the user's perspective.Ask: how does this add value to the user's experience?
The design is intuitive - users can get started without a manual.If they need training to do something basic, the design has a problem.
If asking users to do something, the value justifies the effort.Extra work must be proportionate to the benefit it delivers.

Reflection Questions

→Does this design match how users actually do their work?

→Would a user on a phone have the same quality experience as one on a desktop?

→Would a first-time user know what to do without being told?

→Am I adding friction without a clear payoff?

03 Remember the Why - Every Decision Should Add Value

Why it matters

The purpose of the system is the compass. Every feature, element, and interaction should trace back to it. Losing sight of the why is how projects drift, bloat, and fail.

If ignored

Teams build things because they can, not because they should. The product becomes unfocused, users get confused, and the core experience suffers under the weight of unnecessary decisions.

Checklist

The purpose of this system is clearly defined and documented.Why does it exist? What problem does it solve?
Every feature and element traces back to that purpose.If you cannot connect it to the why, reconsider it.
Value is real and felt by the user - not just assumed by the designer.
The core experience works well before anything else is added.Resist building bells and whistles on a shaky foundation.
We have returned to the why after launch - is the system still delivering on its purpose?

Reflection Questions

→Why does this feature exist?

→Who benefits from this, and how?

→If we removed this, would users notice or care?

→Are we building this because it adds value, or because it seemed like a good idea?

04 Everything on the Screen is Intentional

Why it matters

Every element - text, color, spacing, button, icon - directs the user's attention. Elements without purpose create noise, compete for attention, and make the experience harder to navigate.

If ignored

Cluttered interfaces overwhelm users, obscure what matters, and signal a lack of care. Users lose trust in a system that looks and feels unpolished.

Checklist

Every element has a clear reason to exist.Remove anything you cannot justify.
Visual hierarchy guides the user's eye to what matters most.
There is no decorative clutter.Visual elements serve communication, not the designer's taste.

Reflection Questions

→Can I explain why this element is here?

→Does removing it change the user experience in any meaningful way?

→Is this adding signal or adding noise?

→Where does the user's eye go first - is that the right place?

05 Accessibility as a Foundation

Why it matters

Accessibility is not a niche requirement - it is a baseline. Cal State LA is required by ADA Title II to meet WCAG 2.1 Level AA standards. Designing accessibly means designing clearly, which benefits every user.

If ignored

Excluding users with visual, motor, or cognitive differences is both an ethical failure and a legal one. Retroactively adding accessibility is far more expensive than building it in from the start.

Checklist

Reflection Questions

→Can someone with low vision or color blindness use this?

→Is this navigable without a mouse?

→If there is video or audio, can a Deaf or hard-of-hearing user access the same information?

→Have I tested with an accessibility checker?

→Would this hold up to a Cal State LA compliance audit?

06 Feedback Loops

Why it matters

Users need to know the system heard them. Designers need to know whether the system is actually working. Feedback - from the system to users and from users back to the team - is how trust is built and quality improves over time.

If ignored

Users feel lost, unsure whether their actions did anything. Teams ship without knowing if the product is working. Problems fester because there is no channel to surface them.

Checklist

The system provides real-time feedback to users.Confirmations, progress indicators, status - the user always knows what is happening.
There are structured channels to collect feedback from users.Feedback is a feature, not an afterthought.
Ways of working include a post-implementation feedback step.Design the loop that follows launch, not just the launch itself.

Reflection Questions

→How does the system communicate success or failure to the user?

→Where does a user go when something goes wrong?

→Is there a mechanism to capture improvement ideas over time?

→When was the last time we actually talked to a user about their experience?

07 Look, Presentation, and Content All Matter

Why it matters

A well-designed system needs all three: intentional visual design, clear presentation, and meaningful content. Weakness in any one dimension undermines the whole experience - even if the other two are excellent.

If ignored

Great content buried in a confusing layout goes unread. A beautiful interface with inaccurate content destroys trust. Poor visual design makes users question the quality of the entire system.

Checklist

The visual design is intentional and reflects the purpose of the system.
Presentation is clear - the right information surfaces at the right time.Structure and hierarchy guide the user's eye.
Content is accurate, current, and written for the audience.Not for the developer or the database schema.
All three dimensions - look, presentation, and content - have been reviewed.

Reflection Questions

→Does the look reinforce the purpose, or distract from it?

→Is the most important information the most prominent?

→Is the content written the way a user would think about it, not the way the system stores it?

08 Consistency

Why it matters

Users build mental models of how a system works. Consistency lets them transfer what they learned on one screen to every other. Inconsistency forces them to relearn constantly.

If ignored

Users feel disoriented, make more errors, and lose confidence. Inconsistent design also signals the team wasn't communicating - which erodes trust in the product as a whole.

Checklist

Similar actions look and behave the same way throughout the system.
Terminology is consistent - the same thing is always called the same thing.
The visual language (colors, fonts, icons, spacing) is applied uniformly.
The system behaves predictably - users are not surprised by unexpected outcomes.

Reflection Questions

→If I learned how to do something on screen A, does that knowledge transfer to screen B?

→Are we using the same word for the same thing everywhere?

→Would a user be surprised by anything this does?

09 Error Prevention and Recovery

Why it matters

No system is perfect and no user is infallible. Good design anticipates mistakes, makes them hard to make in the first place, and - when they happen - makes recovery fast and painless.

If ignored

Users make irreversible mistakes, lose work, or give up entirely. One bad experience can permanently change how a user feels about a product.

Checklist

The design makes common errors difficult to make.Guard rails, confirmations for destructive actions, smart defaults.
Error messages are clear, helpful, and tell the user exactly what to do next.
Users can undo or recover from mistakes.Irreversible actions are clearly marked and require explicit confirmation.
The system handles edge cases and unexpected inputs gracefully.

Reflection Questions

→What is the worst thing a user could accidentally do - and is there a guard against it?

→When something goes wrong, does the user know what to do next?

→Can a user recover from a mistake without losing significant work?

→Have we tested what happens when users do the unexpected?

10 Creative Exploration

Why it matters

Real design requires real curiosity. It means bringing your full human perspective - your experiences, your empathy, your willingness to question - to every problem. The best solutions rarely come from the obvious path. Diverse ways of seeing and thinking lead to solutions that genuinely serve people.

If ignored

Teams lock onto the first plausible idea and build it. The result is a solution that is technically valid but misses opportunities to be truly useful, elegant, or well-suited to the people it serves.

Checklist

We generated at least three meaningfully different approaches before committing to one.Different - not just variations on the same idea.
We asked "what if" and "why not" before asking "how".Question the problem before you solve it.
We drew on the diverse perspectives on our team.Different backgrounds and experiences surface blind spots.
We stayed curious about the people we are designing for throughout the project - not just at the start.
We were willing to discard a good idea when we found a better one.

Reflection Questions

→Did we explore the edges of this problem, or just the center?

→Whose perspective are we missing?

→Is the solution we chose the best one we could find, or just the first one that worked?

→What assumption are we making that we have never actually tested?

In-Class Content

Design Principles