Frequently Asked Questions

These common questions and their short answers are taken from Victor Lombardi’s book Why We Fail: Learning from Experience Design Failures . You can find longer answers to each in your copy of the book, either printed or digital version.

1. What kinds of products are described in this book?
   Of the ten products profiled in this book, four of them are websites (Classmates.com, Wave, Pownce, and Wesabe), two of them are services (Plaxo and OpenID), one is a software package (Final Cut Pro X), one is an operating system (Symbian), and two are hardware-based (iDrive and Zune). They were all generally created in the United States and Europe. All of them were designed for consumers rather than for businesses.
2. Why did you choose those products?
   I began my research by surveying dozens of failed products—from small unheard-of start-ups to Boo.com, which spent more than $100 million; and from early consumer software such as WordStar to the most recent video games. I then focused on products that tried to innovate. There are certainly many examples of failed products that were attempts to copy others, or were simply incremental improvements over what came previously, but those cases aren’t as interesting or instructive. I also excluded products that failed merely because the creators were incompetent or whose lessons are outdated or irrelevant.See Chapter 1 for a longer explanation.
3. How do you define “failure”?
   The failures in this book are customer experience failures. The products somehow failed to offer their audiences a good experience. As a result, the product either failed in the marketplace (e.g., Symbian) or the company was forced to change the product to offer a better experience in order to survive in the marketplace (e.g., Plaxo).Chapter 1 has more examples of this definition.
4. Isn’t a “customer experience failure” just another way to say it was a bad design?
   This was often the case in the past when products were simpler and could be judged by their list of specifications, such as the speed of the processor or how many colors the screen could display. But today’s digital products are so complex we engage with them differently. A product such as a smartphone may seem good based on how it looks and its list of specifications, and it might function perfectly fine, but we don’t know if we like it until we try it. Our reasons for using these complex new products are multifaceted, and our experiences of them are emotional and subjective. They are experiential products, and they fail in experiential ways.In Chapter 1 I point to some videos that nicely illustrate the difference between design and experience.
5. Isn’t there usually some other, underlying cause of the failure, such as hiring poorly trained designers?
   Sometimes, but for this book I tried to find stories that revealed more interesting, less obvious lessons. For example, a product might work fine for one audience but fail when given to a different audience (e.g., OpenID). Or one aspect of the experience we think might be vital, such as a website that is always available, doesn’t beat a competitor whose website is often down for maintenance (e.g., Pownce). Or two similar products might offer a similar experience to the consumer, but one might fail because of cultural and social reasons (e.g., Zune). In any case, I also look behind the experiential reason for failure to find what caused that failure.See the “Why the Experience Failed” and “The Underlying Cause” sections in the Summaries that end Chapters 2 through 8.
6. Is experience design the main way products fail?
   Products can fail for many reasons, from malfunctioning technology to ineffective marketing. This book focuses on customer experience failure because it’s relatively new and not enough has been written about it to date.
7. Isn’t learning from failure overrated?
   There’s an argument that says you should study your successes and then try to repeat those successes, making them a little better each time. That’s fine if what you’re doing is simple and is similar to something you’ve done in the past, such as designing a “Contact Us” form for a website. But what I see in the experience design field is change—a lot of change. Technology, products, customers’ expectations, and culture are all changing quickly. To think we can only repeat what worked in the past is wishful thinking. I believe we need methods to help us understand customers’ current experiences, quickly make design changes, and avoid failure on the product or project level.Chapter 1 has a longer explanation of why learning from failure is useful.
8. You recommend using a design process based on the scientific method, but how is that relevant to design?
   First, because the scientific method is a universally understood, repeatable technique that underlies our civilization’s massive progress since the 17th century. Design is about creating something that works for people, and we can use the scientific method for discovering if that something did indeed work.Second, a reason the scientific method works well is because it seeks to remove psychological biases from our work by rationally and explicitly stating how our designs should work, how we will test them, and how we should evaluate the results of the tests.Chapter 9 discusses a host of psychological problems that lead to failure, and Chapter 10 outlines how to apply the scientific method to our work.
9. How can I use this book to avoid failure in my work?
   There are at least three ways:If you make a product similar to the ones in this book, you can directly apply the lessons learned. For example, if your product involves social networking, you and your colleagues should read Chapter 6 about Pownce. Then, as a group, study the key points in the Lessons and Summary sections at the end of the chapter. Compare them to your tactics and strategy to see if you might be making the same missteps.Perhaps your products have started to be judged on their customers’ experience rather than product performance (see explanation in Chapter 1). For example, television, musical instruments, home automation, and automobile telematics are product categories currently making this transition. If so, focus on Chapters 5 and 8 to learn from other product categories (mobile phones and media players) that made this transition. Then you may want to start applying the method described in Chapter 10 to develop and test your products with your customers’ experience in mind.If you’ve had failures in the past, you can conduct a postmortem to understand why the products failed and make changes to avoid failure in the future. Use the method in Chapter 10, particularly step 1 (“Understand the Customer Experience”), and refer to the Resources section at the back of the book for more specific guidance.

back to Why We Fail

Frequently Asked Questions

These common questions about mobile design and their short answers are taken from Rachel Hinman’s book The Mobile Frontier. You can find longer answers to each in your copy of the book, either printed or digital version.

1. Why is mobile UX such a hot topic right now?
   For what felt like the longest time, mobile UX was considered a small and obscure design space that most designers felt obliged to learn more about but loathed participating in because of all the inherent design constraints. The release of the first iPhone in 2007 changed all that. The iPhone demonstrated to the mobile industry and the world what was possible when innovative mobile technology was paired with a stellar user experience. The iPhone was more than an innovative product; it was the first mobile device that got people—regular, everyday people (not just the geeks)—excited about using a mobile phone. Now, as increasingly more people are experiencing what it’s like to access and interact with information from nearly anywhere, through devices that are beautifully designed, mobile is no longer a niche topic. There’s never been a better time to design mobile experiences.
   See Chapter 1 for more.
2. What makes mobile user experience and design different?
   Practitioners of mobile UX design often cite context as the biggest difference between designing for mobile experiences and other design spaces.Developing an understanding and empathy for the depth, breadth, and design implications of the mobile context is quite possibly the most essential skill necessary in creating great mobile experiences. If you’re a practicing designer, chances are that context is your design blindside. Most designers have been steeped in a tradition of creating experiences with few context considerations, although they may not realize it. Books, Web sites, software programs, and even menus for interactive televisions share an implicit and often overlooked commonality: use occurs in relatively static and predictable environments. In contrast, most mobile experiences are situated in highly dynamic and unpredictable environments.
   See Chapter 3 for more information on designing for the mobile context.
3. What modifications to my existing design processes do I need to make to create good mobile experiences?
   Mobile UX professionals use many of the same tools and processes as other UX professionals. Designers new to mobile UX must learn to calibrate their design decision-making skills to a new medium—and prototyping is essential in developing those decision-making skills. Although prototyping is considered a luxury for many PC-based experiences, it is an absolutely essential part of creating compelling tablet and mobile experiences. The reason is simple. Chances are, if you are new to mobile, your design experience and instincts aren’t very well tuned to mobile. Unlike the PC, the mobile design space is relatively new, and design patterns have yet to be formally codified. In lieu of experience and heuristics, the best way to develop these skills is to practice turning the brilliant ideas in your head into tangible experiences you and other people can engage with. Prototyping can become your saving grace in this regard.
   See Chapter 6 for tons of info on prototyping methods.
4. How do I design for touchscreen experiences?
   One of the issues that makes designing for touchscreen experiences challenging for designers is that most of us have been steeped in a tradition of creating experiences using GUI (graphical user interface) principles. With the widespread uptake of mobile phones and tablets outfitted with touchscreens, we’re currently in the midst of a UI paradigm shift. Designers and UX professionals must now learn to create experiences that leverage NUI (natural user interface) principles. This includes learning the key differences between GUI and NUI, as well as understanding how to optimize experiences for touch.
   Chapter 2 will help you understand what makes NUI interesting and different, and Chapter 8 will give you valuable info on how to optimize screen-based experiences for touch UIs.
5. Should I design a native mobile app, a mobile Web app, or a mobile Web site?
   Many experts in the mobile industry have deeply held philosophical viewpoints on this question and have been willing to fight verbal cage fights with those whose opinions differ. The short answer is: “It depends.” Chapter 4 covers some of the pros and cons of each approach. A word of caution: While this is an important implementation question to answer, it’s not necessarily the first question you should be asking at the beginning of a mobile user experience project. Ultimately, your goal should be to create a great user experience. Technology and implementation choices can help guide your design and decision-making process–but they should not dictate it.
   More on identifying mobile needs in Chapter 3.
6. What does the future hold? What’s next for mobile user experience?
   In the near future, many designers and UX professionals will focus on pioneering the parts of the mobile frontier that have already been discovered. And that is a good place to be. But there’s a vast space just beyond what’s been discovered that some brave souls have already begun to explore. There are three mobile trends I’ve been tracking that I believe will have a profound impact on the future. These themes will not only redefine mobility, but they’ll also irrevocably alter the relationship we have with computing. They are: the shifting boundary between computers and the human body, the shifting boundary between computers and the environment, and mobile experiences for emerging markets.
   These topics will all be covered in Chapter 9.

back to The Mobile Frontier

Frequently Asked Questions

These common questions and their short answers are taken from Nathan Shedroff and Christopher Noessel’s book Make It So: Interaction Design Lessons from Science Fiction. You can find longer answers to each in your copy of the book, either printed or digital version.

1. The topic of this book is a fun idea, but how is science fiction relevant to design?
   Design and science fiction do much the same thing. Sci-fi uses characters in stories to describe a possible future. Similarly, the design process uses personas in scenarios to describe a possible interface. They’re both fiction. Interfaces only become fact when a product ships. The main differences between the two come from the fact that design mainly proposes what it thinks is best, and sci-fi is mostly meant to entertain. But because sci-fi can envision technology farther out, largely freed from real-world constraints, design can look to it for inspiration and ideas about what can be done today.
   See Chapters 1 and 14.
2. Do you distinguish between science fiction and sci-fi?
   In a 1997 article, Harlan Ellison claimed the term “science fiction” for the genre of story that is concerned with science and “eternal questions,” with an implied focus on literature. We wanted to look at interfaces, and this led us quite often into that other category of story that he characterized as a “debasement” and “a simplistic, pulp-fiction view of the world” called “sci-fi.” We don’t entirely agree with his characterization, and it’s true that we didn’t look at literature for this project, so we don’t make the same distinction. We just use sci-fi as an abbreviation for science fiction to save space. Hopefully Mr. Ellison won’t be too mad.
3. Where is [insert an example from sci-fi here]?
   To misquote Douglas Adams: Sci-fi is big. Really big. We couldn’t get to everything, and we didn’t have the room to include everything we got to. Fortunately, many sci-fi examples build on very similar ideas. Sometimes we passed over one example in favor of another that might be more well known or, alternatively, we included an unsung one that deserved some credit. Most of what we’ve reviewed is sci-fi from the United States, but we’ve also ventured into sci-fi from other countries. Even given what we’ve managed to achieve, we’ve barely scratched the surface.
   You can find additional material on our website: www.scifiinterfaces.com.
4. Why didn’t you talk about [insert interaction design principle here]?
   The lessons are derived from sci-fi, not the other way around. If no example in the survey pointed us toward, say, Fitts’s Law, then it doesn’t appear, and some principles didn’t make the final cut due to space constraints. Another style of investigation would have been to write a textbook on interaction or interface design using only examples from sci-fi, which would be interesting, but isn’t this project.
5. Wouldn’t this have worked better as a movie or an ebook that can play video clips?
   Because our lessons and commentary involve moments from movies and television, it’s a little problematic to publish them in a medium that doesn’t allow us to show these interfaces in action. But because our focus was on studying interfaces and deriving lessons, we’ve started with media that would work best for later reference: traditional book, ebook, and website. If you’re eager to see some of these interfaces in action, certainly check out the original movies or TV shows, or come to one of the workshops and lectures we give on the subject, where we share relevant clips. And be assured that we’re exploring alternative media for these lessons and ideas next.
6. These interfaces weren’t designed to be studied or for users in the real world. Aren’t you being a little unfair?
   Indeed, we are using real-world criteria for interfaces that aren’t in the real world—the vast majority of which aren’t meant to be. But as fans and designers, we can’t help but bring a critical eye to bear on the sci-fi we watch, and with most of the world becoming more technologically savvy as time goes on, audiences will become so, too. But it’s the “outsider” nature of these interfaces that make them fascinating to study, as their creators produce both blunders and inspired visions.
7. What was the most interesting thing you discovered when writing the book?
   We were surprised at how productive it was to investigate the “bad” interfaces. The “good” interfaces often serve as reminders of principles with which we are already familiar. Sometimes they are inspiring. But the “bad” interfaces, because they still worked at a narrative level, revealed the most surprising insights through the process of “apology,” discussed in Chapter 1.
8. What was left on the editing room floor?
   One of our early ideas for the book was to include interviews with sci-fi makers and science practitioners. The interviews didn’t make it into the final iteration of the book, but these people gave their time and shared much with us, and we’d like to acknowledge them individually with special thanks: Douglas Caldwell, Mark Coleran, Mike Fink, Neil Huxley, Dean Kamen, Joe Kosmo, David Lewindowsky, Jerry Miller, Michael Ryman, Rpin Suwannath, and Lee Weinstein.Additionally, we had early draft chapters on sci-fi doors, chemical interfaces, weapons, and spacesuits/spaceships. Early reviews of the sheer size of the book forced us to make some hard choices. Perhaps in some future work we will be able to develop this content further, but for now it will have to wait.
9. Why didn’t you mention [insert title] more?
   Several movies and TV shows are incredibly seminal and culturally influential. Star Trek, Minority Report, and 2001: A Space Odyssey are three we can name off of the top of our heads. But we didn’t want to lean too much on a small set of movies and shows. Rather, we wanted to use these examples for their most salient aspects, then branch out into other examples from the survey when the topic warranted.
10. What about other speculative technology found in video games, futuristic commercials, or industry films?
    The hard-core genre nerds know that conversations about defining science fiction often lead to conversations about speculative fiction instead, which is a much broader topic of interest to us, but isn’t the focus of this project.
    Anyone interested in these related media should read Chapter 14.

back to Make it So

Sample Chapter: Design That Scales

This is a sample chapter from Dan Mall’s book Design That Scales: Creating a Sustainable Design System Practice. 2023, Rosenfeld Media.

Chapter 1

Why Design Systems?

Think about all the Google products you used today. Maybe you checked your email using Gmail during some early part of your day. Perhaps you drove to your office or to an appointment using Google Maps to help with directions. You probably needed more info about something, and you looked it up on Google Search, perhaps using Google Chrome. Maybe you collaborated with a colleague on a Google Doc or Google Sheet. Maybe you watched a video on YouTube. Maybe you did all of that on an Android mobile device.

As a user, you probably didn’t give much thought as to what it took on the Google end to make this kind of day possible for you. And you shouldn’t! All you should care about is whether or not you’re getting the experience you want from using these applications.

Systems Connect Organizations

But what does it take for Google to deliver this holistic experience for you? As of this writing, Google—technically Google’s parent company, Alphabet Inc.—employs almost 140,000 people. Google also works with many external partners and agencies to help them accelerate and innovate on the digital products they create for their users. Keeping thousands of people aligned from a design and engineering perspective requires some kind of system, a set of things working together as parts of a mechanism or an interconnecting network. For organizations that make digital products, one of those systems is called a design system. Here’s my definition:

A design system is a connected, package-managed, version- controlled software product that contains the smallest set of components and guidelines a particular organization needs to make digital products consistently, efficiently, and happily.

This is a mouthful! I’ll explore and explain each of these words and phrases in greater detail in Chapters 2, “Design System Fundamentals,” and 9, “Success Metrics for a Design System.”

Google’s design system is called Material Design. In Google’s own words, Material Design is “an adaptable system of guidelines, components, and tools that support the best practices of user interface design.” (See how close that is to my definition?) Without Material Design, Google employees and partners would be left to design and build each product and screen and interaction and element from scratch each time, creating an incredible amount of effort and unwarranted variation. Having a shared system like Material Design means Google designers and engineers can quickly reference common solutions (Figure 1.1) that are ready for implementation.

Figure 1.1

No matter what Google application you use, the floating action button component always provides easy access to the primary action of a screen in the bottom-right corner.

Design systems aren’t just better for the designers, engineers, product managers, and rest of the team creating digital products. Design systems prove better for users, too, because they don’t have to relearn interaction conventions from application to application. A 2016 Forrester study found that consistency in customer experience led to a 24% increase in revenue, and design systems tend to create interface consistency by their nature (Figure 1.2).

Figure 1.2

Even if you’ve only used one Google product header, you know how to use them all.

But maybe you don’t use Google products.

Maybe you use Microsoft products. Microsoft takes the same approach with their Fluent Design System.

Maybe you use IBM products. IBM takes the same approach with their Carbon Design System.

Maybe you use Salesforce products. Salesforce takes the same approach with their Lightning Design System.

The list goes on and the point is clear: organizations that create and maintain two or more digital products often turn to design systems to help them solve the problem of digital product management at scale. If your organization wants to scale digital products, design systems aren’t just a good idea, they’re an inevitability.

Common Benefits of Design Systems

Design system aficionados often espouse three main benefits of design systems:

• Using a design system advocates efficiency. Starting from scratch and reinventing the wheel each time a digital product is made is a major culprit of digital overspending. Having proven solutions at the ready helps teams address problems more quickly.
• Using a design system generates consistency. Design systems prioritize reusability across digital products, and reusability is the main ingredient in consistency.
• Using a design system spawns innovation. Moving designers and engineers from creating everything from scratch to reusing common interface and interaction remedies frees up their time to address unfamiliar problems and invent solutions for them.

I also like to add a fourth:

• Using a design system bestows relief. Digital product teams regularly stress over unrealistic deadlines and wicked problems. Design systems give them a cheat code that gives them time and space back so they can breathe more easily.

Realizing these benefits is easier said than done. Many success- ful design system initiatives instigate cultural and organizational transformation, and unsuccessful attempts frequently die due to organizational politics. An ingrained and lasting design system practice is necessary to bring about these benefts.

Who Are Design Systems For?

Anyone who works on a digital product team can beneft from a design system. While this book focuses primarily on the roles of the famed “three-legged stool”—design, engineering, and product— design system work includes many other disciplines like content, QA, research, illustration, business analytics, behavioral science . . . any discipline typically found on a digital product team.

Unsurprisingly, these are also the roles useful in making a design system for an organization. It’s natural for a design system to start within a particular discipline like design, IT, or UX. These design systems often fail to gain traction, because it’s too easy for the rest of the organization to see it as “someone else’s library.” A design system needs to belong to everyone, which means it can’t really belong to anyone. Working on, contributing to, and maintaining a design system is truly a democratic and collaborative exercise. The rest of this book will show you how to avoid a siloed birth for a design system and instead create one that eventually represents an entire organization.

Questions for Reflection:

• Does your team or organization manage two or more digital products?
• What kind of efficiencies in tools and processing could your organization benefit from?
• Do you already have a design system in your organization?

Succeeding in Design Systems

Hayley Hughes is a seasoned design system expert who has worked at some of the largest and well-known enterprise organizations of our time. I asked her a few questions about her experience with design systems and what it takes to succeed in the space.

What is a design system to you?

To me, design systems are a community of practice made up of diverse teams within an organization. This practice involves teams collaborating in an ever-evolving feedback loop of observing, making, and reflecting on what a quality experience means for their users, and how to deliver it. The community creates and governs shared platforms and tooling for scaling insights, standards, assets, and services across an enterprise.

You’ve worked on design systems at the largest scale at some of the world’s largest organizations. What skills do you need to work at that level?

At larger organizations, the design system supports thousands of people, from in-house teams to external partners. It needs to work for diverse audiences in a variety of geographies and environments using different devices and technologies. With so many use cases, the system needs to enable unity, not uniformity—rallying teams to create cohesion across experiences, while giving them flexibility and a wide range of expression.

Going from small to large companies is as much a mindset shift as it is a skillset. You stop thinking of systems as a purely pixel-and-code craft and start thinking of systems as a state craft of operationalizing people and practices.

Operational skills like facilitation, coaching, and diplomacy help you organize movements and manage change with large groups of people. That means you drive alignment conversations between a dozen teams. You coordinate rollouts that cascade changes across hundreds of products. You create educational materials for training design system trainers. You build domain knowledge in the product development cycle and identify ways that systems can improve institutional capacity. You look for patterns—matchmaking people and resources. Pixels and code still matter, but you hire others with the skills that it takes to do those jobs, while coaching them on the skills it takes to scale systems.

What are some commonalities between every design system you’ve worked on?

I’ve worked on a handful of design systems at IBM, Airbnb, Nike, and Shopify. One reason I chose to work on these systems is because the people leading them have common values. First, they understand that the purpose of design systems is to improve the quality of decision- making on teams versus just shipping faster. Second, they really care about driving collaboration across teams and introducing changes in a thoughtful way. Third, these teams prioritize equitable work in areas like accessibility, inclusion, localization, and ethics.

From a team size perspective, most systems I’ve worked on had a core team of designers and developers that might range anywhere in size between a handful to a few dozen people at any given time. They’ve all had a shared design language, component libraries, documenta- tion site, and enablement program for training and partnering with product teams. Usually, the system has been positioned horizontally, reporting in through a design, operations, or infrastructure function.

What are some differences in organizations that make each of their design systems unique from one another?

Every design system I’ve worked on has been at a different stage of maturity. IBM’s design system was built from the ground up, devel- oping a design language for everything—not just the software and hardware, but also the physical buildings, business cards, events, advertisements, you name it. Airbnb had trouble getting people to use the system, so I was asked to help drive adoption. Shopify wanted to expand to become a system of systems. This meant focusing on governance and enabling teams to create local systems. Nike’s system needed to become more fexible to support more differentiation across brands, geographies, and use cases. Every system has similar problems, but depending on which stage of maturity they’re in, you might be prioritizing one over another.

How did your career path prepare you to work on design systems so effectively?

There is no one career path that leads you to being effective in design systems. I’ve had teammates who were former biologists that were experts in feedback loops or lawyers who knew how to handle open source licensing. People in design systems come from all different kinds of backgrounds.

A common theme in a design system career path is the idea of being hybrid, or showing interest and capability in multiple domains. This concept most often refers to hybrid skills in design and development, but there are many types of hybrids. Part of becoming a hybrid involves trying on many hats before defining your role in design systems. By doing so, you become an interdisciplinary thinker with more empathy for others.

I wouldn’t call myself a hybrid, but I have spent most of my career doing interdisciplinary thinking. I first worked at nonprofits focused on influencing political and environmental systems. Then I worked at restaurants and art museums that created hospitality, brand, and wayfinding systems. In grad school, I studied healthcare and local food systems. Now, I’m focused on design language systems.

What advice would you give to someone looking to break into a design system career?

Look for the holes. If you’re able to sell the holes as an actual problem, then you can put yourself in a position to fix them. Do the research to show that you know what teams need. For example, if you’re seeing issues with accessibility in a product experience, dig deeper. The business should also care because it probably has requirements it has to meet around compliance to avoid litigation. Combine the user needs and the business requirements into a compelling opportunity, and solve for that.

You don’t even need to say the words design system at first, even if that’s what you’re technically making. Once you solve it, you’ve built trust to ask for more investment, perhaps another teammate or resources to keep filling other “holes.” Keep tracking and measuring the outcomes of the problems you’re solving. Eventually, these things snowball where you can share full case studies and reveal the system that powers them.

What encouragement would you give to design system veterans?

If you’re in an organization that struggles to reward systems work and promote systems people into higher levels, don’t give up. There are periods in your career when no matter what you say, people just won’t “get” systems. Maybe it’s because they require a tolerance for some degree of complexity. There will be other times where you’ll have incredible advocates who not only “get” systems but invest in you and your team. There’s some peace in knowing that this is an endless cycle, as stakeholders and investors come and go over the years.

What we have control over is the ability to apply the holistic approach we take to solving any type of problem within an organization. Don’t just make decisions. Study how decisions get made. People who move into a systems leadership role need to shift their practice toward understanding: How are decisions made, contributed, governed, learned about? Our jobs are to make sure that process, that decision workflow is as seamless and easy to do and conducive to good outcomes as possible. That’s system lifecycle work.

Lastly, remember to ask: Where is the most impact you can make inside or even outside your organization with your skills in design systems? Your answer might be about helping people work better together. It might be about training people to be systems thinkers. Maybe it’s about bringing together the entire organization and the end-to-end user experience. The bounds of systems are only where you draw the line for yourself, on your team, and within your organization. Keep dreaming and let your imagination be your guide.

back to Design That Scales

Civic Design 2022 Program

Lisanne Norman on Why She Left UX Research

You’ve got the paperback copy – now get the digital edition!

For Prospective Authors

Should you write a book?

Writing a book is a difficult, time-consuming, and occasionally painful undertaking. It’s also a gift: it’s rare to have the opportunity, with sufficient time and ample support, to develop an idea that you care deeply about.

Before you proceed, ask yourself these questions:

1. Do I really want to spend most of a year (or more) of my evenings and weekends on such a challenging pursuit?
2. Is a book the best format to bring my idea to life, especially when other formats may play better to both my strengths as a communicator and to the topic itself?

If your answer is ‘no’ to either question, writing a book is probably not your best option.

Should you write a Rosenfeld book?

We’re glad that Rosenfeld Media is on your radar!

Founded in 2005, Rosenfeld Media is a small, independent publishing house that works closely with its authors to develop and promote books on user experience design, product design, and related topics. We typically publish no more than ten books annually, and we lavish each with tender loving care throughout the processes of writing, production, and marketing. Please note that we are not a hybrid publisher—we’re not “pay for play”.

There are two things you should know before you propose a book to us:

1. Approach: We’re unusually collaborative—and you will need to be too. That means we don’t accept manuscripts that have already been written, or that you don’t want to work together to develop. Our approach is to work with you from proposal to publication. That’s true of marketing your book too; book marketing works best when author and publisher partner.
2. Audience: Our core audience is user experience designers, researchers, writers, and product designers.

If you’ve got a different audience in mind, or don’t feel the need to collaborate on your writing, or expect your publisher to handle the bulk of book marketing, we are not the right publisher for you.

What Rosenfeld is looking to publish

Most of our books cover user experience design principles, tools, and methods. UX is a broad field that synthesizes ideas from many disciplines—from architecture to graphic design to human factors to librarianship—with the goal of helping people use and enjoy their experiences with all kinds of products and services.

• Our UX books teach craft and actionable skills to designers, researchers, writers, and other people who care about delivering great user experiences. These books tend toward practical advice: a rule of thumb is 25% “what and why” content, and 75% “how” content.
• We also publish another imprint, Two Waves Books, that explores the convergence of business and design. These titles cover topics that may have originated in the design world or benefit in special ways from a designer’s perspective, but are important to related audiences, like product managers, data scientists, and customer experience professionals.

Regardless of imprint, our house voice and tone emphasize warmth and accessibility as much as intelligence. Through the use of plain language and a conversational tone, our authors serve as trusted guides and facilitators as much as authoritative experts.

The ideal length of our books is 45,000-75,000 words (150-250 pages). Our authors use illustrations, examples, and stories to show as much as tell. And we prefer topics that are “evergreen”: while some of their examples might be especially current, each book’s principles and frameworks should stand the test of at least a few years’ time.

What Rosenfeld avoids publishing

Never say never, but we generally avoid publishing books that are:

• On topics we’ve addressed in a recent book. We avoid covering the same topics twice in the space of a few years; it’s simply not fair to our authors. Please review what we’ve published or are planning to publish and make sure we don’t already offer a recent book on your topic.
• Already written. Most publishers love receiving a manuscript that’s “ready to go.” We’re not one of those publishers. We prefer to pool your ideas with ours about the topic, its audience, your research, and the writing and production of the book. If you’ve already written a manuscript, it’s actually more work for us to produce your book.
• Compilations written by multiple authors. Regardless of how good you are at herding cats, compilations often suffer from uneven coverage, voice, tone, and quality.
• Repackaged blog entries. “Writing short” can be a good way to test your ideas and content in public, and it can get you part of the way toward a full manuscript. But a book is more than the sum of its parts; you’ll still need to make significant changes to your individual entries before they work together as a book.
• Based on a proprietary process or method. You or your company may be promoting a unique and novel approach. But is it broadly relevant and generalizable for readers?

Other things to know about Rosenfeld

• Our philosophy. Whether we’re co-creating books, workshops, conference programs or presentations, our approach comes down to three words: inclusion, collaboration, and iteration.
• Research equals promotion. Collaboration goes beyond you and us. We’ll work together to engage influencers, subject matter experts, and the broader community with your ideas with two goals in mind: to help you improve your content, and to give them a sense of and stake in the final outcome. The more people who feel a part of your book’s development, the more will support and promote it once it launches.
• We invest, you invest. We assign a developmental editor to each book. They work with you as a writing coach/project manager to get you through the process. And our marketing team works directly with you from development through launch. Both of these things are rare in our industry. In return, we expect you to be at least an equal partner in creating and launching your book—not just writing it but working hard to promote it.
• Speak with, not to readers. We want the world to be a better place thanks to your ideas and expertise. So we work with our authors to avoid jargon and other forms of poor communication that can get in the way of our readers learning from our books.
• We don’t play favorites. Our books receive an equal amount of editorial and marketing support, and all are consistently produced to meet our uncommonly high quality standards. If we’ve signed you, we are about you as much as any other author.
• Book formats. Our paperbacks are 6” x 9” (15.24cm x 22.86cm), and are printed with four-color covers and, in most cases, interiors. Our ebooks come in ePUB and DAISY DRM-free digital formats. We also market foreign language and audiobook rights to your book to major publishers in those channels.
• Business terms. We pay royalties twice annually on net sales (the money left over after production and printing costs are covered, as well as from audiobooks and translations). Our royalty rates are typically higher than the industry standard. We don’t pay advances. You own the copyright to your book, and license it to us.
• Distribution. We sell directly via our website and fulfill orders globally. We also sell via Amazon and other major retailers and wholesalers that do business with Ingram Publisher Services, the world’s largest book distributor.
• Covers. We’re glad to have your input, but the final design up to us. We’ve worked with the acclaimed design team from The Heads of State to develop each of our covers.

Ready to propose a book?

If you got this far, you’re probably ready to propose your idea for a book. Here’s what to do next:

If you’re at the idea stage:

Send us a pre-proposal that’s no more than one page, and includes:

• Working title: Ideally both descriptive and engaging.
• Elevator pitch: No more than 100 words that address both the challenge or problem readers need your help addressing, and what your solution is.
• Primary audience: Describe who the book must reach. Please be specific; “everyone” or “all humans who design” is too general. Also list any secondary audiences you’d love to reach if possible.
• 3-5 take-away bullet points: Explain how your idea will benefit your audience. What will they be able to do after reading your book?
• Your objective: What does success look like once your book is published?

If you’re further along with your proposal:

Send us a complete proposal that includes everything above, plus:

• Table of contents: Include a sentence or two that describes the goal of each chapter, some bullets describing what each chapter will contain, and how many pages (at 300 words/page) you estimate for each chapter. Also let us know the total number of pages you estimate the book will be. (Our sweet spot is 150-250 pages.)
• Writing sample: 2-3 pages, ideally from the proposed book; we’re also happy to read other samples of your professional writing.
• Competitive review: What other books will your book compete with, and how will your book be different from those titles?
• About you: Why are you the right person to write this book?
• About your ability to market your book: How will you market your book? Are you well-known in the field? Do you have a strong following on social media, a newsletter, or something else?

When you’re ready, email us your document. As you might imagine, we receive a lot of proposals. We do our best to review them at least once per quarter; please keep that in mind if you don’t hear from us right away. And if you decide to go in another direction, please let us know.
Thanks and good luck!

Support for your book club

If you’re a book club organizer, please let us help!

Please complete this short form and we’ll:

• Send you a code for a whopping 30% discount for you to share with your book club members
• Send you a complimentary copy of the book (paperback and ebook versions to US-based clubs, ebooks only outside the US)
• Cajole (if you like) the author into joining the discussion via Skype or equivalent; they’re usually quite willing!

Resources

Accessible UX principles and guidelines