Making the Case for a Design-Led Transformation

Written by: Alejo Jumat

When you hear about problems in the healthcare space, the list can be long enough to require a prescription of its own.

They can be concerns that we as individuals face.

  • Coping with a disease or condition and understanding your care choices
  • Figuring out how to make decisions to improve your health and maintain a healthier life
  • Determining which insurance plan is best
  • Determining which hospital to go to for a particular surgery

From a healthcare delivery perspective, the issues can be frightening.

  • Thousands of medical errors made annually
  • Increasing rates of hospital-acquired infections
  • Complicated data displays in electronic medical records that can cause medication errors
  • Wrong site surgery
  • Information hand-offs at shift change and unit transfers
  • Dysfunctional cultures within clinical care teams where people are afraid to speak up if they think something is about to go wrong for fear of retaliation

Given all the local and systemic challenges in healthcare, designers have the opportunity to make an impact in a high-risk environment that can one day be linked directly to the improvement of patient outcomes.

Design for Care, by Peter Jones, makes the case for a design-led transformation across the entire spectrum of healthcare to help solve these various problems. To read a little more about why we should be listening to Jones, particularly in the context of designing in the healthcare space, check out his credentials.

Jones describes various types of problems in healthcare:

  • Simple problems, such as fixing a broken bone
  • Complicated problems, such as surgical operations due to many moving parts and many ways to fail
  • Complex problems, like chronic diseases such as asthma, cancers, and autoimmune diseases
  • Wicked problems, those complex problems with uncertain interventions as well as uncertain outcomes such as come with aging populations with multiple chronic diseases

Jones offers a lens in which to tackle these problems. He cites design strategists Garry VanPatter and Elizabeth Pastor from Humantific with the four stages of design evolution:

Design 1.0: Traditional Design (traditional craft design processes)

Design 2.0: Product/Service Design (industrial and interactive product design)

Design 3.0: Organizational Transformation Design (organizational level transformation design)

Design 4.0: Social Transformation Design (transformation across a large healthcare institution)

When building a product/service/application in healthcare, a significant shift in design practices and methods is required as the relative scale of problem solving increases from Design 1.0 to Design 4.0.

Throughout the book, Jones gives real-world examples of Design 1.0 through Design 4.0 and illustrates the methods used by practicing healthcare researchers and designers. Each section of Design for Care offers a look at specific areas throughout the system of healthcare, and almost every chapter ends with a case-study that concludes with “tips on techniques” and lessons learned.

To further illustrate the problems in healthcare, Jones begins each chapter with a persona (“Elena”) and her journey across the continuum of care. An Elena vignette  introduces each chapter and brings to life a journey that we can all relate to.

Another way to look at the problems in healthcare (particularly when designing and building a product/service/application) is through the lens of the “sociotechnical” system. Jones writes, “Information and interfaces are integral parts of a sociotechnical system–the social system that organizes work and tools into a meaningful function in an organization. When technological systems are merely ‘installed’ into complex operations, social practices change to adapt. If the systems are not integrated well, entire system installations can be rejected at great administrative cost.”

Through several chapters, Jones hones in on electronic medical record (EMR) design and the unfortunate effects he feels EMR implementations have had on clinical settings. This was probably the most frustrating section of the book for me, not because of Jones but because of the impact (or lack thereof) that EMRs have had in the clinical setting. According to research by Jones, “Major EMRs reveal critical interface design and clinical workflow challenges… and can trigger potentially hazardous situations at every level of function.” Other organizations such as the Institute for Healthcare Improvement and the National Patient Safety Foundation have found similar issues.

It is maddening to me that the creators of these EMRs didn’t take into account this “sociotechnical” system. In my training as a user experience designer, this is one of the first things that I learned: When designing a system that helps people do their job, the design of the system must integrate into their workflow. You must take into account the people, their context and their activities.

In the clinical setting, user experience designers should’ve been employed from the beginning (classic story right?) to ensure that EMRs support the needs of clinicians to make clinical work more safe and efficient.  Jones goes into great detail on why EMRs are the way they are today and how to eventually innovate the EMR design.

As a user experience designer in healthcare, Design for Care has given me new ways to look at the problems that I’m trying to solve. Jones has illustrated different forms of user research methods–such as empathic design research and cognitive engineering–that I’ve yet to use and brainstorming techniques–such as bodystorming— that I can start applying on certain projects.

To me, Design for Care is a call to all designers out there to join in on the quest to “do no harm” by  “designing no harm.” One thing Jones makes very clear though in this book: Working in this space will require a long-term commitment. He says that to be effective, we have to acquire a much deeper level of domain knowledge than in other industries/service areas. Jones explicitly states, “The complexity of healthcare IT applications requires that designers make a personal and usually long-term commitment to the domain, involving years of learning, practice, and patience with slow progress.”

You will need to shift your thinking from your standard problem solving to “design thinking” and to “systems thinking.” The problems are “complex and wicked” and the standard user-centered design methods aren’t enough. The standard user-centered design methods are fine for traditional design and product/service design. However, when you get into organizational transformation design and social transformation design, new design strategies and methods are needed.

According to Jones, the presence of designers in healthcare organizations is quite new. Some of the best examples, he says, are in-house designers who learn the field from within. He says that the typical digital agency model is not recommended for this type of design because of the significant requirement to understand actual patient care.

I agree with Jones here. In my experience in healthcare, I’ve made the most impact by being “in-house,” where I’m directly connected to healthcare domain experts and share in the responsibility/accountability of creating a product and service that is geared toward keeping patients safe while in the hospital.

Healthcare needs design. Badly. After a dozen years working in various industries doing user experience design, I realized I was at a crossroads in my career and I wanted to do something that was more meaningful to me personally. I wanted to find those wicked problems that I could help solve and work with the people that were solving them. I found healthcare, specifically the clinical setting. The problems can be daunting since lives are actually at stake. Design for Care has reminded me of why I work in this industry and the vast opportunities for design to make an impact and improve patient outcomes.

The Distant Summit of Enterprise Design

Written by: marianne sweeny

Lately, I have been fascinated by mountain climbing. I am reading every book that I can find on the subject. As I sat down to write this review, I found the mountain climbing as a metaphor for enterprise design sticking with me. Milan Guenther’s book Intersection does an excellent job of showing us the view of enterprise design from the top of the mountain. Yet, I came away from reading it without the necessary lessons one gains from actually climbing to the summit.

On page 183, the author seems to reveal the why of what we’re reading:

“The intent of the Enterprise Design approach is to capture the enterprise in both design context and subject in a holistic fashion. To envision a future state beyond the isolated problem setting, designers need to be aware of the enterprise context it is embedded in…to develop conceptual models of the enterprise, to capture details that are necessary and useful during the design process by looking at the enterprise from a particular viewpoint.”

However, what follows is light on specifics for this conceptual modeling, either by example or application of this framework.

I was delighted to see that the author presents concepts similar to those found in Peter Checkland’s Soft System Methodology (SSM). In Checkland’s methodology, a design project must look at the enterprise as a larger system comprised of smaller systems. “Basically, all human endeavors have reached a level of scale and complexity that makes them interdependent on an ecosystem of interrelated organizations and technology.” (p18)

SSM also finds that developers are often asked to solve the wrong problems and that designers often find themselves in non-design roles. To avoid these problems, SSM also promotes an enhanced discovery stage, cross-discipline communication, and concept modeling to ensure that all viewpoints are captured.

In Intersection, Guenther’s foundation is that there are new kinds of information systems–people, processes, content management applications, network– that are smarter, pervasive, embedded, and ubiquitous. These systems are modular, often co-created, open (sourced) and interconnected, ubiquitous and mobile, intelligent and adaptive. They require a new approach.

Intersection is in three major segments:

Part 1: Design Enterprise–This section presents those concepts most similar to SSM.
Part 2: Enterprise Design Framework–This section is the most theoretical, making it difficult to rearticulate the exact nature of the author’s framework.
Part 3: Enterprise Design Approach–Here the author delivers the most practical application of his framework by mapping action to problem-specifics.

Gerd Waloszek has done Olympian work of synopsizing Intesection’s 463 pages in his SAP Design Guild Review of Intersection, with my gratitude for not having to repeat this labor.

The Enterprise Design Framework (part 2) is a connective framework that sees integrative or design thinking focused on connecting different domains, problem spaces, and viewpoints. To accomplish, it promotes:

  • Cross-silo cooperation

  • A focus on the big picture over core discipline challenges

  • A design scope that expands to include visuals, interactive systems, and service, and which continues to expand.

  • The design of (signs, objects, interaction, systems) that become the building blocks of an enterprise-minded design. “Design connects the enterprise with its cultural environment, and leads to a discourse on a meaningful, viable and feasible future.” (p 78.)

I would have liked the author to drill a bit further into this and provide some detail or examples of the meaningful, viable, and feasible future that would result from the application of his framework.

Content strategy and management fares less well with the author’s seeming viewpoint that content’s design goal is to merely enhance the meaning of content. Surely, that cannot be its only purpose. As @mikeatherton said at UX Cambridge 2013 “Content is the whole damned point” and so should exist beyond service to design or brand messaging. The subject of the enterprise, its “aboutness,” exists long before design emerges.

It does not seem rational to me that all other elements serve design. The enterprise content management industry will also take issue with the author’s generalization that “today content elements are only seldom regarded as assets for a potential enterprise-wide use” (p 171). The author then goes on to take enterprises to task for ignoring the “…mass of potentially relevant content lying asleep in archived email threads” (p. 171). Not only do these concepts run contrary to core content strategy beliefs, they are not problems solved through application of the framework.

The Good

  • This is a beautifully designed book with visually segmented content, headings, and color separation.

  • The At a Glance sections that end each chapter are helpful in retaining core concepts presented.

  • Part 3: Chapter 9, where the author directly applies the Enterprise Design Framework along with specifics that illuminate its seven phases:

    • Prepare (getting started)

    • Discover (explore the problem space)

    • Define (develop a solution approach)

    • Ideate (give form to the solution components)

    • Validate (prototyping for simulation and testing)

    • Implement (start the production and development)

    • Deliver (deploy to begin the transformation)

Each state is accompanied by state-specific activities, challenges, and typical techniques. It is here that the author’s convention of big picture components (identity, architecture, experience) and anatomy components (actions, touchpoints, services, and content) have better context and do not seem forced as in the chapters that precede it.

  • The VDA case study on p 176 and Instagram case study in Part 3 are the best at presenting a detail-oriented, mapped application of concepts to chapter topic.

The Merely OK

  • References to design, experience, and the enterprise are as high-level concepts throughout the book.

  • There are too many obtuse, sweeping statements that make the reader stop and think “Say what?” instead of “Tell me more.” For example, from page 212: “It is the user who attributes function.” Here I said to myself, “Say what? It is more like the user anticipates an outcome of function that is based on emotion, environment, or mental model.”

  • There is an emphasis on function modeling, with no examples or direction on how to accomplish this.

  • Many of the case studies do not do a good job of illuminating abstract thinking and concepts discussed prior, especially for the more esoteric concepts.

  • The table of contents in front and back of book index are beautifully designed yet not functional for re-finding specific concepts represented in the book. For example, the index lists a single reference to relevance for the entire book found on pages 225-226. Going to page 225, there is a section “RELEVANCE: placing a “spotlight” on a subset of objects which are important to the enterprise with regard to the business objectives, the people being addressed, and the structural context.” And, that’s it for relevance for the entire book, according to the Index.

  • White text on black background is not a fun reading experience.

Conclusion

This is a thoughtful tome, dense with deep, contemplative thinking on enterprise design. It has a rightful place on the bookshelves for designers that are intrigued by the challenge of cross-discipline collaboration.

However, designers looking for a better understanding of technology will be disappointed, and technologists looking for an understanding of the design world will be baffled.

In my armchair mountain climbing, I came across what has turned out to be a great life lesson from a climb master, the individual who remains at basecamp as the one to give the go/no go on summiting: “Success is not reaching the summit (of the mountain). Success is getting back to basecamp alive.”

I am glad to have my well-thumbed, heavily underlined copy of Intersection on my shelf as a reminder of the importance of the view from the mountain top. Now I need many of the Rosenfeld Media books to tell me how to get back to basecamp.

Intersection by Milan Guenther

Morgan Kaufman 2013

ISBN: 978-12-388435-0

An Answer to the Pains of Integrating Agile and UX

Written by: Ambrose Little

I recently attended UXPA 2013 in D.C. Although I was attending as a sponsor/exhibitor for Indigo Studio, I did manage to break away to go to the “There’s more than one way to skin a cat: Integrating UX into an Agile environment” session. It tied in quite nicely with the book I’m reviewing here.

As sometime director of Design at Infragistics, I personally have had first hand experience trying to integrate UX into an existing, established Agile engineering process with large-ish teams. So I’m always interested in seeing how others are faring and what ideas they might have to address pain points.

Interestingly enough, in that session, all panelists identified a key pain point that resonated with my experience as well. They all attempted some flavor of the now well-known staggered sprints approach, and they all felt the pains that such an approach introduces, namely being torn in too many directions at the same time–trying to do research and initial design for upcoming sprints while supporting the implementation of the current dev sprint. Sadly, none of them really had solutions to that problem. It was kind of a “yeah, it’s painful, and we don’t really know what to do.” The strategies employed were coping strategies rather than success.

One of the attendees during the Q&A essentially went on a rant about how “Agile is a developer process,” essentially suggesting that we UX folks know better and shouldn’t even be trying to make Agile work. He used the term “developer” as if it were an epithet, and unsurprisingly, a lot of the audience cheered him on. Clearly, the problems of integrating UX practice into Agile are a common source of pain for UX people.

The real challenge with the standard approach to integrating UX into Agile is fundamental to the staggered sprint model. The challenge is essentially that it is not wholly effective to try to be working ahead on the upcoming backlog items while at the same time supporting the development team, answering their questions, reviewing what they’re doing, and providing ongoing feedback/microiteration with them. “Microiteration” is a term I coined at Infragistics—it is extremely timely iteration within a sprint where you work hand-in-hand with devs to review stuff right as they build it, provide feedback, and iterate.

When following this staggered approach, either research, evaluations, and up front/initial design suffers, or seeing through the implementation of the design suffers. One is always pulled in different directions, and that usually results in things falling through the cracks.

Enter the book

It turns out that Jeff Gothelf, author of Lean UX (the book I’m reviewing here) has also faced the same challenges. I liked his honesty in relating how he came to an epiphany when he, as manager, thought things were going along hunky dory, but then he got not-so-subtle indicators from his folks that his view of reality and the reality they were living were quite divergent. Jeff was different from the session presenters in that he offered a potential solution to the staggered sprint pains.

The answer situates itself within the Lean approach to product development. A lot of people seem to confuse Lean with Agile, and while they share some common characteristics, I would say that Lean is far more prescriptive. As Gothelf points out, Lean UX synthesizes the highly iterative structure of Agile with the creative and scientific methodologies of design thinking and Lean Startup (a set of concepts popularized by Eric Ries in his Lean Startup book), utilizing multiple frameworks to determine solutions.

Lean UX proposes a number of core principles and the ones that most directly address the key pain points mentioned above are:

  • Cross-functional teams – have UX folks integrated into the teams, not external consultant-type model
  • Minimize waste – few deliverables and handoffs

As Jeff relates in Chapter 4, the process is one that involves the whole team (as much as possible) in the user research and early design ideation. It goes further to have the team focused on the same problems at the same time. Together, this approach goes a long way towards eliminating the staggered sprint problems, and it also has other benefits around reduced waste and getting everyone on the same page more easily.

Lean UX has its own challenges

Of course, this collaboration model is not new with this book—the “movement,” if you will, has been gaining momentum for a few years now. And it has its own challenges—doubtless you’re thinking of some in your head now. A lot of them boil down to concerns around distinctions in competency—a concern of loss of specialness when UX folks already often have to help people understand the value they bring to the table. I think Jeff addresses most of the common ones in the book, so I won’t rehash it here.

I have been skeptical for a long time about the feasibility and value of involving “everyone” in design research. But I have also observed the negative effects and the waste in the process when, essentially, people can’t believe you because they did not witness the same things that you did. I’m now of the mind that if you can, involving more of the team in the research is beneficial, not just to solve this “belief” problem but also as a means to help establish a shared vision of the customer and to help generate more design ideas.

As Jeff points out, the UX designer becomes the leader and facilitator of design, rather than the sole source of it. Given that generating many alternatives is a key part of good design, this seems like a good thing—and having people who are generating be more aware of the research will only improve each alternative’s quality.

There are still solitary activities for designers to do in this model, but they are more about synthesizing and choosing design concepts (and of course coordinating and facilitating as per usual). The solitary type activities are reduced, and the increased participation from other team members means that on the design end of the process, everyone is focused on the same problems. And then on the back end, the UX role is more supportive—filling in blanks, answering questions, and doing microiterations.

Same goes for the eval side—getting everyone involved has similar benefits. And at the same time, the problems of staggered sprints and being pulled in multiple directions are ameliorated.

Summary

There is a lot more to Lean UX than I focused on here; however, this is a key area where I think Lean UX has a lot to offer teams that are trying to figure out how to integrate UX and Agile. Additionally helpful are topics like a more objective/experimental approach, having a more open and timely collaboration with customers, and establishing the vision, framing, and focusing on outcomes.

Jeff goes into some depth on Integrating Lean UX and Agile, and his final chapter on “Making Organizational Shifts” is helpful to anybody interested in pursuing a path along these lines. There are still questions I have (as well might you), but hopefully you’ll see at least some of those in a subsequent interview on B&A.

For anyone interested in improving their process and collaboration, specifically with integrating UX better into existing software development approaches, this book adds a lot to the discussion. I’ve recommended it to my colleagues, and I can recommend it to you too.

Calling in the Big Guns

Written by: Will Evans

B&A readers get 10% off when purchasing from Rosenfeldmedia.com (use code WFDBA)
Discount for Boxes and Arrows readers: Get a 10% discount by purchasing the book directly from Rosenfeld Media. Just use the code WFDBA.

The scene is all too familiar. You’re presenting wireframes of the registration process for a new web application when the discussion veers down a dark alley. The sky has turned the color of black ink, and you can smell sulfur in the air as one team member after another debates the alignment of form labels.

Before you can toss up a quick Hail Mary, marketing says that the opt-in for marketing solicitations has to be defaulted to yes, and you can feel your soul sucked out of your body through your nose as a simple one hour meeting turns into a 3 hour discussion over the pro’s and cons of inline validation while your stomach grumbles because you just missed lunch.

I have heard this war story many times from many interaction designers and information architects, with little variation except in the details. What we need is air cover in this battle to design better forms. Now, it’s here.

“Forms Suck!”

And so Luke Wroblewski begins his new book on web form design with a canon shot, providing just the air cover and ammunition interaction designers need; and every review, including this one, begins with a first impression.

Mine was: Boffo.

(bof·fo (bf) slang, adj.: Extremely successful; great.)

Wroblewski opens “Web Form Design” with a strategic exploration of why users interact with forms. News flash: It’s not because they enjoy it. Interaction designers need to confront the truth that a user’s goal is to get to some successful outcome on the other side of a form – as quickly and painlessly as possible. We want our iPhone, tax return, or account with Facebook. We don’t want to fill out forms.

bq. Forms suck. If you don’t believe me, try to find people who like filling them in. You may turn up an accountant who gets a rush when wrapping up a client’s tax return or perhaps a desk clerk who loves to tidy up office payroll. But for most of us, forms are just an annoyance. What we want to do is to vote, apply for a job, buy a book online, join a group, or get a rebate back from a recent purchase. Forms just stand in our way.

Wroblewski has researched everything from the basics of good form design, to labels and most-direct route, delivering his explanations, patterns and recommendations with a casual urgency that avoids preaching. This book is a useful guide for both the novice interaction designer and the battle tested UX guru, offering salient, field tested examples of the good, bad, and often times ugly forms that have proliferated the web like so many mushrooms after a good rain.

Wroblewski has also invited many seasoned professionals to contribute sidebars, including Caroline Jarrett’s no-nonsense perspective on designing great forms by advising us to “start thinking about people and relationships,” instead of just diving into labeling our forms and choosing where to put the Submit button. I especially appreciated her strategic guidelines for picking what questions should go into a form in the first place, which she aptly titles “Keep, Cut, Postpone, or Explain.”

Wroblewski is aware of how challenging most readers will find good form design. It comes as a relief, for instance, when he writes that we should think less about forms as a means of filling a database, and more as a means of creating a meaningful conversation between the user and the company.

He generally succeeds at adopting the warm tone of a confidant who can win you over with self-deprecating, you-too-can-make-dynamic-forms-every-day enthusiasm. The more subtle points of user-centered design or goal-driven design are not discussed explicitly; only the trained ear will detect them.

What’s In the Book?

“Web Form Design” is part of a wave of User Experience books from Rosenfeld Media – books focused on bringing practical, actionable and well-researched methods to actual practitioners in the field. This literature is going to have a powerful effect on our community of practice, maybe as powerful as the effect the Polar Bear book had on our grandparents’ era. This volume is broken out into three sections:

Section one: “Form Structure” begins with an overview of why form design matters and describes the principles behind good form design, followed by Form Organization, Path to Completion, and Labels (hint: your form design should start from goals). Working quickly through strategy to tactics, Wroblewski gives numerous examples – within the context of usability studies – so that you are not left wondering whether these patterns are recommended based just on his opinion.

Section two: “Form Elements,” is a useful, clearly written exploration of each of the components of form design: labels, fields, actions and messages (help, errors, success). Wroblewski attacks each one of these by defining particular problem spaces, and then shows good and bad solutions to the problems while highlighting how these solutions faired in controlled usability tests, including eye-tracking. He then finishes each chapter off with a succinct list of ‘Best Practices’ that I suggest are good enough to staple to the inside of your eyelids.

Section three” “Form Interaction,” includes chapters on everything from Inline Validation to Selection-dependent Inputs (a barn burner). Here we move from the world of designing labels, alignment, and content to designing the actual complex interactions between the system — that wants to be fed like the plant in Little Shop of Horrors –- and the world-weary user that just wants to get to the other side of the rainbow. As Wroblewski explains in his opening of chapter 9 “Inline Validation:”

Despite our best efforts to format questions clearly and provide meaningful affordances for our inputs, some of our questions will always have more than one possible answer…

Inline validation can provide several types of feedback: confirmation that an appropriate answer was given, suggestions for valid answers, and real-time updates designed to help people stay within necessary limits. These bits of feedback usually happen when people begin, continue, or stop entering answers within input fields.

To establish communication between the user and the form, provide clear, easy-to-read feedback so that the user doesn’t get the “select a username or die” travesty that we see in registration forms all over the web. You know the ones: you type in your name, choose a username, enter your email address, and your password (twice), hit the submit button…and…bad things happen. The username is already taken. Worse, the form is cleared and you have to enter all that information all over again. Wroblewski provides advice for validation (without set-in-stone rules), and a bulleted list of best practices.

The final, and perhaps most interesting chapter in the book, covers the topic of Gradual Engagement. This is particularly timely given the kudzu-like proliferation of Web 2.0 applications and services as well as social networking sites and micro-blogging sites. Instead of starting your engagement with a new company that all your friends are raving about with yet another registration form – as Wroblewski writes:

bq. “We can do better. In fact, I believe we can get people engaged with digital services in a way that tells them how they work and why they should care enough to use them.1 I also believe we can do this without explicitly making them fill out a sign-up form as a first step.”

He continues by highlighting the benefits of moving a user through the application or service – actually engaging with it, and seeing it’s benefits, while registration is either postponed, or handled behind the scenes. He explores web applications like JumpCut, where the user steps through the process of creating, uploading and editing their video — and only when they actually want to publish and share it, does the user encounter a form — at which point they have already learned the service, it’s benefits, and it’s value. This is certainly a more engaging experience than being confronted with a form and a captcha before ever realizing the value of the web application. He ends this compelling chapter by providing some advise and best practices :

bq. When you’re exploring if gradual engagement might be right for your Web service, it’s important to consider how a series of interactions can explain how potential customers can use your service and why they should care. Gradual engagement isn’t well served by simply distributing each of your sign-up form input fields onto separate Web pages.

Wroblewski showed three excellent examples of web applications that seem to very successfully utilize this new strategy for engaging new users while avoiding or at least postponing the ubiquitous registration process. This is certainly welcome news. The key is to rethink how new users become engaged with your company. Does the conversation start with a form? Gradually introducing new customers to your service and it’s benefits – letting them actually use it and learn it first seems like a better way to start the conversation.

I wish this chapter had more to it, as it covers an exciting exploration of web application design innovation. Wroblewski wrote a very compelling article in UXmatters back in 2006 titled, “The Complexity of Simplicity,” which was a predecessor to this chapter of the book. After an extensive search online, this was about the only source I could find other than some blog posts referencing that article. One article on ReadWriteWeb, “Good UI Design: Make It Easy, Show Me You Care” did include two more examples – FuseCal, a calendar syncing online application, and Twiddla, an online whiteboarding service.

Another spot that could have used improvement were in the last chapter. Perhaps this was either my reading of it or the way it was presented. What’s Next, certainly made me feel that he would be exploring his vision of the future of form design, and forms in general — which he certainly does in the section on the disappearing form, and proceeds into a very brief discussion of game-like elicitation methods (GEMS). These are welcome additions, I wish that he had gone a bit deeper into this chapter, especially about GEMS. It’s a fascinating discussion point, and we will see more examples in the coming year.

I also wanted more resources and references to studies that a form designer, information architect or interaction designer could use to bolster their design decisions. Many good designers out there know how to design good forms. The hard part is the politics and the negotiation process with stakeholders — and numbers always help.

I am reminded of a conversation I had over lunch about a month ago here in D.C. The UX professional was giving a short presentation on form design to an in-house crowd and was trying to subtly indicate the value that often times less is more in form design. He wanted to show to stakeholders that the concept that adding one, two, or four more form fields in a registration process has a cost, even if the design and development cost is minimal. I suggested that a simple info graphic that showed how, as the number of form fields increased, user signups decreased. His immediate reaction was that some stakeholders would immediately want to see metrics to back up the assertion.

I am unaware of any numbers about fall-off rates, but from my professional experience tells me less is better than confronting a first-time potential user with a long form to complete. Perhaps it would be sufficient to include a “Further Reading” section divided up into sections like Academic Research, Field Studies, and Conference Papers. The book may not the best place to put something like this — I wonder if the online companion to this book has such a thing. Either way, it would be a valuable addition.

Summary

What is likely to win the most converts, though, is the joy Wroblewski takes in designing. This impression becomes clear as you page through the book. He isn’t just an ardent evangelizer, following the rituals of going to conferences selling snake oil. He’s been there in the trenches, just like you; he’s done this a hundred, maybe a thousand times. He’s tested these ideas and provides a framework for you to use from day one. Half the battle in good form design is defending your decisions to stakeholders. This is your air cover, so call it in!

You can get Web Form Design from Rosenfeld Media or Amazon.com. Just keep in mind that, for the same price, Rosenfeld Media tosses in a nicely formatted digital version which you can use to quote from when you have to sell a good form design to a team that wants to bicker over form labels.

Don’t forget the discount for Boxes and Arrows readers: Get a 10% discount by purchasing the book directly from Rosenfeld Media. Just use the code WFDBA.

Web Form Design: Filling in the Blanks
By Luke Wroblewski; foreword by JaredSpool.
RosenfeldMedia: May,2008.
ISBN:1933820241
Buy from: Rosenfeld | Amazon

Minding Your Ps And Qs

Written by: Yaniv Nord

The great Motown songwriting duo Ashford & Simpson have said that in all their years penning tunes for the likes of Diana Ross and Marvin Gaye they learned one skill above all: sensitivity.

The 200-plus pages of email etiquette in Send: The Essential Guide to Email for Office and Home can be summed up similarly. Be sensitive. Consider that every choice made while crafting an email is an exercise in decision-making, tact, and manners. And the stakes are high: with the click of a mouse the whole world can know just how poorly you’ve behaved. We all remember ex-FEMA head Michael Brown emailing his staff, as hurricane Katrina slammed New Orleans, “Can I go home now?”

If you’re like me, the thought of reading an entire book about email may sound tedious, and much of Send is indeed a bit of a yawner. (See, for example, the lengthy discussion on when to sign your message “sincerely” versus “best”). Digital design professionals will also be dismayed that there’s little mention of making email messages easier to retrieve through a search utility, nothing on the increasing use of email accounts as record-keeping systems, and zilch on the arms race between Gmail, Y! Mail, Outlook, and other mail programs.

What Send does best is provide a cautionary guide to communicating better, detailing the countless ways to screw up your messages or publicly embarrass yourself. Take, for example, the software executive who humiliates his secretary over email only to find his message forwarded, with commentary, to the entire company. (He later stepped down). Or, consider the op-ed writer emailing the New York Times editorial page with a request to publish a very “contemporaneous” piece. (What he really meant was “timely”). Much of it is obvious—turn on your spell-checker—but for those of us who often cringe with regret upon reading our own already sent messages, some of their arguments are worth examining.

For example, consider the recipient list. This is an area where many of us operate on instinct. But Send argues extreme caution. Recipients, for one, should appear in order of seniority. This may strike you, the sender, as prissy, but someone who’s worked their way into a position of responsibility may think otherwise.

Another good point: Before you pile on too many names in the “To:” line, keep in mind the rule of diminishing returns: the more people you send a request to, the less likely anyone is to respond. Send also gives a funny yet telling example of the power of Cc:

DEFCON 1
To: Saddam Hussein
From: George Bush
Please let in the weapons inspectors.

DEFCON 3
To: Saddam Hussein
From: George Bush
Cc: United Nations Secretary General, NATO, European Union, Joint Chiefs of Staff
Please let in the weapons inspectors.

Send argues that if you can’t formulate a simple, coherent subject line there’s probably something wrong with your message. Their recommendations should sound familiar to readers of Jacob Nielson, who in 1998 threw down the wonk gauntlet and categorized email subject lines as “Microcontent.” In Send, the authors describe email as “ruthlessly democratic”: there’s no more level a playing field than the inbox, where all messages are relegated to 100 or so characters in which they can plead their case to be read.

The golden rules of subject lines include not using the “hot pepper” icon (if everything is urgent then nothing is urgent) or all caps. From there, the laws of user experience begin to kick in and crafting the perfect subject line becomes a design exercise: bring your most important words to the front to improve scanning. Be specific. Consider the context.

The same rules of “content strategy” that many of us dutifully apply to web page and application design can be put to use in the email message body. Indeed, many of our messages are read in a web browser. Here again, Send’s rules of thumb dovetail nicely with what we already know about web page usability:

  • Important information should be offset on its own line and , if possible, brought to the front
  • Jargon is to be avoided; likewise to using big words when small ones will do
  • Be sensitive to the way content is distributed (e.g., it’s tough to read a PDF attachment on a BlackBerry)

Email’s power is that it’s easy to send and can be distributed widely and instantaneously. As such, its natural state tends towards informality, and we tend to work with it quickly and at times thoughtlessly. Authors David Shipley, an editor at the New York Times, and Will Schwalbe, editor in chief of Hyperion Books, argue that there’s a lot to be said for treating this mode of communication with a bit more care and sensitivity. As professionals in the realm of digital communications, we’d be wise to heed their advice.

 


From the introduction: "Why Do We Email So Badly"
The 8 deadly sins of email:

  1. The email that’s unbelievably vague. ("Remember to do that thing.")
  2. The email that insults you so badly you have to get up from your desk. ("HOW CAN YOU NOT HAVE DONE THAT THING!!!")
  3. The email that puts you in jail. ("Please tell them that I asked you to sell that thing when it hit $70.")
  4. The email that’s cowardly. ("Here’s the thing: you’re being let go.")
  5. The email that won’t go away. ("Re; Re: Re: Re: Re: Re: that thing.")
  6. The email that’s so sarcastic you have to get up from your desk. ("Smooth move on that thing. Really smooth.")
  7. The email that’s too casual. ("Hiya! Any word on that admissions thing?")
  8. The email that’s inappropriate. ("Want to come to my hotel room to discuss that thing?")

Excerpted from Chapter 3: How to Write (the Perfect)

Email The fact that email is a searchable, storable medium means that you have to compose your message with special care. And the fact that you are writing—constructing sentences, choosing words, making grammatical decisions, adding punctuation—with previously unimaginable swiftness makes the situation all the more vexed, as does the delusion that email, because it’s electronic, is somehow more ephemeral than, say, a letter.

Also, because it’s often acceptable to be lax about the rules of grammar on email, there’s the misconception that it’s always acceptable to be lax about them. That’s not the case. We aren’t gong to offer a guide to style and usage here—lots of books have done that already and done it well. What we are going to do, though, is outline the implications of taking risks with your English in emails and review the stylistic traps that are peculiar to the medium.

In Japanese, the status of the person you are addressing governs the words you use. A sentence directed toward a peer, for instance, requires different word forms from one directed to someone higher or lower than you on the social ladder. (You use one word form when speaking to your boss, another to a colleague, yet another to a child.) Learning Japanese, then, requires learning multiple ways of saying the same thing. The need to remember which kind of word form to use is one of the elements that makes it hard for native English speakers to master Japanese.

What many people don’t consider, however, is that in this respect English is arguably more complicated than Japanese—precisely because English doesn’t offer the convenience of different words to signal that you know the nature of your social relationship to the person with whom you are speaking. In lieu of specific words to show deference—or familiarity—English relies heavily on the delicate manipulation of tone.

More than anything else, vocabulary conveys tone and reveals you as boss or subordinate, buyer or seller, seeker or sage. The words you choose can be formal, casual, or somewhere in between; they can be literal or figurative; they can be precise or vague; understated, correct, or exaggerated; simple or complex; common or rare; prosaic or poetic; contracted or not.

Certainly, some words are inherently safer than others, but if you never venture beyond them you become yet another unmemorable correspondent, ceding the chance to make an impression in your email. Think of your own inbox. When wading through an ocean of email, don’t you yearn for one to jump out? After a hundred people email you that they “look forward to meeting you” so that they can share their “qualifications” or “describe the benefits of their product” or present you with a “business opportunity,” you crave something by someone who took the time to choose words with personality, rather than simply cribbing phrases from the modern business lexicon. The trick is to be vivid and specific—even, perhaps, revealing—without forgetting your original relationship with the person to whom you’re writing.

On the most elemental level, the deal is this. Before you set finger to the keyboard, ask yourself one question (and don’t write until you get the answer): What is my relationship to the person I’m writing? Then, make sure your word choice is appropriate.

 

About the Book
Send: The Essential Guide to Email for Office and Home
David Shipley and Will Schwalbe
2007; Knopf ISBN-10: 0307263649

Contents

  • Introduction: Why Do We Email So Badly
  • Chapter 1: When Should We Email?
  • Chapter 2: The Anatomy of an Email
  • Chapter 3: How to Write (the Perfect) Email
  • Chapter 4: The Six Essential Types of Email
  • Chapter 5: The Emotional Email
  • Chapter 6: The Email That Can Land You in Jail
  • Chapter 7: S.E.N.D.