Last edited
Feb 5, 2023 9:00 AM
In-class slides
This is a quick summary of guiding principles we find ourselves using again and again. We'll keep referring back to these ✨ magic rules ✨ in critique. Without context, the details here might seem a bit random or vague — "Just do it right!" Hopefully, as we repeat these in our feedback to you, the meaning will become clearer. Always feel free to ask us questions for clarification!
Design for consequences, not for artifacts.
What:
- Think about what behavior you want to encourage in people, and design to make those behaviors easiest.
Why:
- The artifact (e.g. your portfolio project) is not the end goal of your work. Artifacts are simply a tool for you to communicate your ideas.
- Sometimes, the consequences you want to design for won't even have a corresponding artifact. e.g., "To make sure people don't get too distracted, this app will only send notifications once a day"
How:
- Start a design process by asking "what behavior do we want to promote?" instead of "what screen do we want to design?"
- Always ask yourself: "How might this feature I'm working on be abused? Should this feature or product or advertisement even exist?"
- If a social product / any product where you can interact with another person: "How might an angry ex use this to hurt someone?"
- Technology can break easily, in ways you might never expect. Ask yourself, "If this product or feature stops working, what are the consequences? What's the backup plan?" The failure mode is also part of the experience.
- You don't need to innovate on every detail and make each artifact super unique. People don't use software in a vacuum, so they'll remember an interaction from one app and probably try to do it in another app. Keep the unimportant things familiar; you can usually only introduce one big new concept/interaction pattern at a time.
- You don't need to put everything on the screen — don't fall into that trap! Remember that people can scroll, or tap through to different views, or be shown the right information at the right time. e.g. via notifications
Always ask why.
What:
- Always try to discover the root cause for any phenomena in your projects.
- Always have a reason for any design decision you make. ("It was the fastest/cheapest" is also a valid reason! Just always be aware of why you're doing the things you're doing.)
Why:
- If you assume you know how something works, or why something is the way it is, you might miss the root cause, and end up creating something that solves a problem that doesn't exist. (e.g. Juicero)
How:
- Ask yourself, why are you solving this problem? e.g., is it because it's a problem that the company's customers have been complaining about? Because you are the person/team/company best suited to address it? Because someone powerful higher-up is emotionally attached to this problem?
- Ask your teammates why they made certain decisions. Sometimes, decisions get made by accident, or aren't made at all ("Why this color? Oh, it was the default color in this program")
- Five whys
- https://hbr.org/2017/01/are-you-solving-the-right-problems
Have a goal.
What:
- What is the highest-level goal for your work? Are you trying to make money? Are you trying to make visually beautiful work? Are you working in hypotheticals, or actually trying to solve a problem in a real situation?
Why:
- If you don't have a clear goal, your work can lead you in circles, always reacting to the latest information or ideas without having a clear end in sight. It's hard to choose which ideas to focus on without a clear goal. You can change your goal, of course, if you learn something that makes your goal invalid — but you should then have an updated goal, with an even better reason.
How:
- Write down your goal before starting a project.
- Use "even over" statements to set priorities. (e.g. we want this project to be done quickly even over quality of visual design.)
- Discuss your goal and priorities with teammates before making big decisions. It's hard to agree on decisions if, for example, someone's goal is beautiful typography and someone else's goal is designing something easy to build.
Have a point of view. Be open to it changing.
What:
- Every sketch or mockup you make includes hundreds of decisions you might not have been aware you were making — typeface, navigation pattern, what device you're designing for, etc. That's a reflection of your point of view!
Why:
- Having a point of view is a byproduct of thinking critically about the problem, and about the work.
- As a designer, you're one of the team members in charge of helping visualize different paths for the future, and helping the team make decisions about which path to take. If you don't have a point of view, it will be impossible to come up with ideas for future paths in the first place.
How:
- If you're asked why you made a decision, you should have an answer. "It would be the easiest/cheapest option" is a valid answer!
- Whenever you have multiple options, always have your own opinion about which one is the most appropriate given the goal and constraints. (Sometimes it will be close, and that's fine!)
- If you get new information (user data, feedback from your teammates, changing goals, etc.), think about whether your previous opinions and decisions are still appropriate. You'll get new information all the time, so check in regularly and adapt your plans as necessary.
Test, learn, and iterate.
What:
- You can learn a lot more from 4 quick tests than 1 long process without testing your assumptions. If your idea fails, that's great! You learned that quicker by testing than you would by waiting until you're done with everything.
Why:
- Feedback is a gift! It lets you learn how people interpret your ideas.
- You'll never have perfect information — make assumptions, make decisions based on your assumptions, and revise those assumptions once you learn more.
How:
- "Testing your ideas" can be as simple as showing a friend a mockup to get their reaction. What are they confused by? What questions do they ask you?
- You don't have to take all feedback, but you should have a rationale behind why you decided not to take it.
- See: Prototyping lecture notes
Make liberally, edit critically.
What:
- Instead of spending lots of time making one artifact, start by exploring lots of directions and then take time to decide which direction is the most appropriate.
Why:
- The first idea or thing you come up with is probably not the best thing.
How:
- Force yourself to come up with multiple ideas in a time frame (e.g. 10 ideas in 30 minutes)
- Organize and edit down your ideas by trying to understand the essence of each iteration or direction. If 3 of 10 ideas are all along the same vein, you can probably combine them into 1 bucket — and voila, suddenly you've edited things down to 6 ideas. Keep bucketing things until you have distilled things down to ideas that are as different from each other as possible.
- When evaluating what ideas to cut, think again about your goals and constraints. What gets you closest to achieving your goals within the constraints?
- If you can't decide what to cut, you can always test your ideas and ask others for feedback! With time and experience, you'll develop an instinct for how to prioritize.
- See: Brainstorming lecture notes
Design in context.
What:
- Think about when and where your user might be interacting with the thing you're designing. Are they out and about? Are they at home? Are they busy and distracted? How does the thing you're making fit into their life?
- Tip: People usually spend much less time than you'd hope looking at the thing you're designing. True for portfolios, marketing sites, features... (But for tools people use a lot, small decisions / frictions add up!)
- "Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan" — Eliel Saarinen
Why:
- You won't be able to fully understand the consequences of your design if you aren't trying it out in context. The better you can simulate the actual experience of interacting with the thing you're designing, the more easily you can create a successful end result.
- Most people, even the designer, can't get a good feel for the design if they see someone else panning around in Figma, or if they click through mobile mockups on the computer.
How:
- If you're designing for a phone, look at and use the design on your phone. If you're designing for a TV, put it on a TV. etc. This will help you make sure the actual interactions and sizing feels appropriate.
- Tip: things that look properly-sized on a mobile mockup on your computer, will probably look too small on your phone!
- Similarly, when sharing or presenting your designs, show them on the right device.
- Test things out in as real-life of a scenario as possible — whether testing it out in your own life, or via user research. If you're working on a live product, use the new feature internally for a while if possible.
- See: Prototyping lecture notes
Communication is half the job.
What:
- Think of your artifacts as a tool for communication, rather than the final thing you're making. (Design for consequences, not for artifacts!)
- You're not making wireframes just because everyone else makes wireframes at the beginning of designing. Have a reason for why you're making this screen. (Always ask why!) Have a strategy for how you'll use this sketch/wireframe/mockup to communicate your idea.
- A designer's communication responsibilities are 1) communicating internally amongst your team (to get everyone to agree and to move projects forward), and 2) communicating with any end user or audience (drawing their focus towards certain messages, features, etc.)
Why:
- The hardest work you will do in your career is not producing mockups or artifacts, but in convincing others that your ideas are worth making real. If you take 20 hours designing pixel-perfect mockups, but don't explain your idea well, it can be less effective than napkin sketches presented well.
- In today's world, hardly any work happens alone. On teams, designers often have the job of creating artifacts that visually communicate what everyone has agreed to build.
How:
- Always think about your audience!!!!!!!!!!!!!!!11!11111!1!! What context do they have? What do they care about? Make sure you're explaining your design and justifying your decision in terms they understand. e.g., if you talk to businesspeople, you'll probably want to frame your website design in terms of conversion and sales, rather than talking about the elegance of the typography and color palette
- Be flexible about what artifacts you make — whatever is needed to communicate your idea. Sometimes it's spreadsheets, sometimes it's wireframes, sometimes it's an interactive prototype.
- When presenting, walk us through your key design decisions.
- Not just "A happened and then B happened" — explain why A led to B.
- Lead with the end result so people know where this is all going. People zone out after a few minutes!
- Typos & mistakes are distracting! No pixel jumpies! Control people's focus and attention.
- See: Communication lecture notes (coming soon)
Everything is connected.
- What:
- Interaction design involves more things than you probably think it does. It could include privacy concerns, legal concerns, copywriting, making something easy to build/maintain, etc.
- Why:
- Interaction design is about defining a human's experience with something. People don't think about software in discrete terms like, "The UI design is polished, but the CTA labels are confusing." Rather, they're more likely to think in general terms, like "I feel confused" or "I have fun using this." Making the overall experience successful will require thinking about things beyond the layout of the pixels on the screen.
- How:
- Be curious about things beyond just design. Read widely about whatever interests you, but fields like psychology, technology, and writing are particularly relevant.
- When working with non-designers, be curious about what they care about, what their goals are.
- Even within "design," brand design and UI design and UX design and writing and research are all connected. Don't be afraid to try all of it. They all end up informing the same end experience.
- Tip: Don't use meaningless placeholder copy (like "lorem ipsum") in your mockups. Write something yourself! The words in an interface can have a huge impact on the end experience, even if it's not something you'd think of as "design."