By Angela Robertson
Introduction
If you have worked as a technical writer in the software development industry, the terms user experience and interaction design should be familiar phrases. Knowing exactly what these terms mean and understanding how to apply the concepts to your work might be things that you’d like to know more about, but time is limited. The following four book reviews aim to provide you with a few resources to get started.
User Story Mapping: Discover the Whole Story, Build the Right Product
Read User Story Mapping: Discover the Whole Story, Build the Right Product if you read only one book about user experience or interaction design. Patton writes an excellent resource for all things related to implementing successful design practices. There is one piece of information missing from this book: an adequate explanation that too many organizations are ill-prepared to follow the guidance provided in the 18 chapters. If you happen to work in an environment not ready to implement user story mapping principles, this book likely frustrates you because you know what life could be like if you had a more mature development organization.
The book is organized linearly so it’s best to read it once and later reference specific sections. If you are not familiar with the term user story mapping, here is Patton’s definition: User story mapping is the task of organizing user stories in a model that allows you to understand a system’s functionality. With this model, you can plan releases of code to deliver value to both users and the business.
Patton cautions that actions speak louder than words when it comes to mapping user’s stories. Specifically, technical writers can appreciate the following statement in the “Read This First” preface: “Shared documents aren’t shared understanding” (p. xxxii). We know that writing something is no guarantee that people read or understand. We have to create a framework in which people are engaged and understanding flows from this engagement.
With this introduction, the first few chapters explain why and how to create story maps. Here’s an example of how Patton frames the discussion, “It all seems important. But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful” (p. 30).
After we understand user story mapping basics, chapters 5–9 explain the implementation phase. I argue that some examples oversimplify the process, but no one can understand how messy and uncomfortable it is to engage in this type of design process until you live the process with a software development organization.
The hard work is to create an organizational understanding of the need for this design work. People want to see words on the screen and functioning code. Yet, experienced writers know that if we find users and observe people working, we can design and write about software in a way that is empathetic with the user’s needs. We do not have to write everything when we talk about who should use software, how these people “can minimize output and maximize outcome” (p. 84).
Chapters 10–18 add depth to the ideas outlined in the first nine chapters. To make User Story Mapping more appealing to engineers and people with little to no understanding of the design disciplines, I would edit this book differently. I would have presented a more logical, business-oriented argument for why businesses need to invest capital into revamping their organizations to allow for the messy work of design. Other books tackle this issue, yet this book chooses to go in depth regarding what is user story mapping.
User Story Mapping ends with a strong statement that should resonate with all readers: “Software is never really done. . . . Outcomes are never insured. . . . Improvements made after release are the most valuable” (p. 256). Too often new features and functions are tacked on after a release. After reading this book, we know that we can do better.
Designing for Emerging Technologies: UX for Genomics, Robotics, and the Internet of Things
When I agreed to review this book, I did not notice the most important fact to know about it: The book is a collection of essays where people in the industry write about designing for emerging technologies. The editor deserves praise for organizing the essays that makes reading easy and the subject matter fun.
Each section can be read like a short story; I found myself reading out of linear order. After starting with the obligatory first chapter, “Designing for Emerging Technologies,” I skipped to the last chapter, “The Changing Role of Design.” I mention that I altered the chapter order to indicate that the book can be read like a collection of short stories. You probably derive more enjoyment from the organization set by the editor, but there is no harm in reading this book out of order.
The chapter topics span from design discussion to industrial design, including chapters about the design of toys and musical instruments. There is a fun chapter about wearables, a couple of chapters about robotics, and a chapter about biology. As someone who would not have sought out essays on each of these topics, I am glad that I was obliged to read Designing for Emerging Technologies: UX for Genomics, Robotics, and the Internet of Things. I would have missed essays on topics that I find fascinating.
As I read the book, I find myself talking to people about it. People wonder if I have a favorite chapter, but what I love about this book is the use of visual design. Most of the essays include some type of visual aid that improves my understanding. The photographs are in color, which brings the subject matter to life.
Illustrations are in black-and-white text, which makes me think I am reading an issue of the New Yorker. And there are some tables and diagrams, which use a consistent visual style that mix a shade of blue with the black-and-white text. The editor took great care to ensure the visual elements tie the essays together in the cohesive form of a book. Instead of being distracted, I am impressed. As someone who understands publishing, I realize the time and care that went into these decisions.
Great time went into the resources provided at the end of the book. Appendix A is a list of companies and products referenced in the book. A 23-page index makes it easy to find whatever I want to recall. The book concludes with a biography of each contributor that saves me a trip to my computer to research who wrote what.
What, then, does Designing for Emerging Technologies have to do with technical communication? The essays showcase all of the technologies where technical communicators can bring their storytelling skills to give the audience perspective on how these technologies map to our lives and why they matter. Like the user story mapping discussed in the last review, we need storytellers who can maximize outcome while minimizing the input from the users. We can frame the technologies to show why they matter. Otherwise, emerging technologies end up in the heap of misunderstood novelties.
Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps
While writing this series review, I wondered how Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps will complement the User Story Mapping: Discover the Whole Story, Build the Right Product and Designing for Emerging Technologies: UX for Genomics, Robotics, and the Internet of Things books. The connection was evident when I read this reminder: “When we learn about things, patterns help” (p. ix). The patterns provided in Mobile Design Pattern Gallery give you a lexicon to apply to the design of smartphone apps.
I read this book after finishing the Designing for Emerging Technologies essays. After reading about a variety of emerging technologies, this book takes me back to the practical work of daily design decisions. Full of examples (more color!), Mobile Design Pattern Gallery is a reference guide for what to do when designing apps. Anyone who is working on content to be rendered on a mobile device should find a copy of this book.
While technical writers might not find every piece of information relevant to their work, it’s a great reference guide that helps technical communicators identify the best way to send and receive information with the user. The organization of content makes this book a great reference: Chapter 1: Navigation, Chapter 2: Forms, Chapter 3: Tables, and more.
Chapter 11: Anti-Patterns is my favorite chapter about the pitfalls to avoid. A loose complement to this chapter is Chapter 8: Social Patterns. I spent some time reflecting on why the editor would not pair the chapter on social patterns more closely with anti-patterns. From a pure design perspective, the two chapters are not directly correlated. However, I argue that the more casual reader does not understand this subtlety unless the writer provides a direct explanation for why social patterns are separate from the anti-patterns.
This problem could be resolved through additional Chapter Extra sections, especially for chapters 7–11. Chapter 7 ends with a Chapter Extra by Alissa Briggs, UX Manager and Principal Designer at Intuit. After a brief introduction, she walks us through a design problem that her team solved. The context she provides to each design iteration is invaluable to advancing our understanding.
Given this criticism, if I take the perspective of the writer (and editor), Mobile Design Pattern Gallery is a reference guide. However, taking time to add more context at the end of at some chapters would take this helpful resource to the level of “this is the one book that you should own” when working on smartphone app development.
Designing Products People Love: How Great Designers Create Successful Products
Designing software with intention does not happen as often as you might think. To understand why designing software is important, read Scott Hurff’s excellent book, Designing Products People Love: How Great Designers Create Successful Products. This book makes the design discipline easy to understand and should compel anyone who works on product development to ask, “Why aren’t we doing this?”
Let’s say that your company is practicing design as a part of the development process. You can read this book to deepen your knowledge of the subject and see how technical communication is a part of the design process. For example, the product guide on page 65 is a great example of how technical communicators can contribute to the design team. Chapter 4 explains how the words on the interface define, from a consumer’s perspective, much of the product. I can cite more examples, but you can see that Hurff’s book is a treasure for technical communicators who want to get involved as an active, valuable participant of the team.
If your company is new to design or skeptical of the value, you might read this book and feel frustrated that the people you work for are not smart. How can anyone not understand the essential nature of design and want to implement it in the organization? Take some deep breaths and read Designing Products People Love using a different frame. Instead of reading this book to see how technical communicators can engage in the process, use the examples provided to start conversations about how design as a part of the product development process is becoming the new normal.
The figures that Hurff uses throughout the book give you ample examples to use when talking with people. I recommend starting a pilot project. You’d need to be on the pilot project full time, for a specific period of time, but you can use this book to get started. Can you design an entire product? No. Scope your work to show the meaningful impact and explain how your work can be expanded.
You can use the “Further Reading” resources provided at the end of the book to continue learning about the design practices that Hurff explains. I’d use the resources to scope the work you are allowed to do. Hurff’s book focuses on the design of a complete product. I doubt that for a first design project you will be allowed to implement design on that large of a scale. The guidance that you read in “Chapter 9: Shipping Is an Art–and a Science” needs to be revised to apply to your specific situation.
If you do not think anyone will be willing to let the current development processes be updated to include the type of design processes described by Hurff, you could look at how support or other auxiliary teams might be willing to use a design process to update a current tool or workflow. Success breeds success and that’s why more companies are implementing design as the core of the product development process.
References
Follett, Jonathan. 2014. Designing for Emerging Technologies: UX for Genomics, Robotics, and the Internet of Things. Sebastopol, CA: O’Reilly Media. [ISBN 978-1-4493-7051-0. 480 pages, including index. US$49.99 (softcover).]
Hurff, Scott. 2016. Designing Products People Love: How Great Designers Create Successful Products. Sebastopol, CA: O’Reilly Media. [ISBN 978-1-491-92367-2. 300 pages, including index. US$39.99 (softcover).]
Neil, Theresa. 2014. Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps. Sebastopol, CA: O’Reilly Media. [ISBN 978-1-449-36363-5. 404 pages, including index. US$49.99 (softcover).]
Patton, Jeff. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly Media. [ISBN 978-1-491-90490-9. 324 pages, including index. US$34.99 (softcover).]
About the Author
Angela Robertson is a technical program manager in Raleigh, NC. She currently works in Customer Content Services with Red Hat Software. Prior to her current role, she worked in a variety of content-related roles with IBM Corporation. She has a master’s of science degree from North Carolina State University.
