About the Book
Designing experiences for humans requires balancing many needs – business, behavior, technology, and aesthetics to name a few. But before there’s a designed experience, there are countless activities and artifacts that go into understanding the problem, aligning stakeholders, and exploring possible solutions.
The Practical Guide to Experience Design provides guidance for the process of designing experiences in four phases: discover, define, refine, and build. Each chapter covers a single methodology, providing insight via detailed descriptions, step-by-step guidance, and high-fidelity examples. The book can either be read front to back or by following along with one of the five sample projects within.
Whether you’re new to or experienced in the field of experience design, this book will support you in your practice as you make decisions, influence stakeholders, and bring experiences to life.
Will people buy my product? How much will they spend? Can we produce the product? For how much?
What underlying technology is essential to my product or service? Does my company have that capability?
Are other companies solving similar problems? What are their solutions? What are their unique selling points?
Who is important to the success of my project? What do stakeholders think I should know? What risks should I be prepared for?
What questions should I ask to learn what I don't know? Where can I find experts to interview?
What are my users' pain points? What are their favorite moments? How do I frame questions to get the most honest answers?
Can I learn from other companies? What non-adjascent experiences can offer relevant input to my project?
How can I get the best understanding of my users' contexts? How do I reduce the impact of my presence?
What is the current experience? How can I communicate the experience with less subjectivity?
Who will use my product or service? What are their unique needs? What are the bounds of their understanding?
How do users understand my product or service? What relevent knowledge and expectations do they already possess?
How do we think outside the expected? What solutions does my team already have in mind?
How do we keep features user-centric? How do we capture all aspects of a feature so that they don't get lost?
How do we get stakeholders to align on a direction? How do we stay true to our original vision?
How does the user move through different channels and touchpoints? What are users interacting with at different points in time?
How does the user feel throughout their experience? How can we find opportunities for our experience to shine?
Where should we focus our effort? What are other things the user might be experiencing alongside our product or service?
How do we balance user needs with ease of implementation? How do we maintain a long-term vision while focuses on the details of now?
How can we ensure that we have many perspectives represented in the design process? When should we bring in users to enrich our process?
How should our product or service be organized? When do we know enough to define an architecture?
How do we organize all of our features so that the user can intuitively access all of them?
How do we keep from overwhelming the user? How do we prioritize what a user sees and interacts with?
Which combinations of ingredients should we explore? How will different aesthetics make our users feel?
What different ways could our product or service look and feel? How do we align stakeholders on a single aesthetic direction?
How does our product or service look, feel, and sound? How do we communicate this simply to stakeholders?
How does the product behave over time? What feedback does the user get when interacting with the experience?
How do we ensure that designs stay consistent across time and teams? How do we keep ourselves organized?
How do we ensure that our intentions are carried forward by other teams? Where do we keep track of decisions?
When are we ready to dive into the details? How do we prioritize what we design for communication purposes?
How do we communicate a complex system without hundreds of pages of documentation?
What type of prototype should we build? How do we get realistic feedback from users?
How much documentation is too much documenation? How do we communicate dynamic designs?
How do we ensure quality through execution? What should we expect when collaborating with implementers?
What do engineers and developers need to bring a product to life?
How do we make sure our product will survive in the wild? When should we seek feedback from users?
Where do we put ideas and features that we don't have time or budget for?