In early October I was asked to give an eight-to-ten-minute presentation summing up the year for UX. A tall order, but I embraced blazing through the content to alight briefly on things I though the general company audience should know about UX and how we were trying to help.
With most of our work going toward rewrites that have not yet launched there’s little to say about outcomes, so I followed a rapid tour of our outputs with a couple of quick demos and an invitation to view my upcoming Cayuse Connect Conference talk about UX philosophy and practice.
A service blueprint is typically a design deliverable, showing a user’s journey, the touch points they interact with in whatever channels (web site, application, retail store, call center, etc.), and the behind-the-scenes activities that need coordinating to make that journey a smooth one.
A service blueprint can also be a research deliverable, describing the existing journey and where that coordination breaks down, what the touch points are and whether they are succeeding or failing, etc. usually you’d just do a user journey for this, but sometimes the additional investigation in to the channels and coordination is helpful.
But what if you have not just one user but multiple players interacting with one another? What if you need to understand how all of these players interact so you can decide who to serve, for whom what you already have would be useful, and where the holes in your product are?
Enter the “super service blueprint”. It’s not really a service blueprint as the focus is on the various interacting players you are investigating. But understanding their collective processes and interactions will give you a clear look at the process you’d like your product to be a part of. A clear map of these allows you to locate little chunks of user value that your product already provides and identify opportunities in the collective process to intervene on behalf of one or more users.
You can also see which of the players you are serving the most and the least, just by looking at which users have the build of the interface capabilities and which users have more of their goals and informational needs met across the timeline.
The super service blueprint pictured here is the product of an investigation my team did into the Cayuse Vivarium operations products and the handful of different user types who either use them , might use them, or were part of the processes that we intended to help along via our products. This super service blueprint led to a re-thinking of the product strategy, since the investigation revealed that there’s a key user involved in nearly every phase of the overall process, and we could serve that person especially well by reorganizing and improving several software capabilities we already had somewhat in hand.
This super service blueprint involved nine group interviews with different large-institution vivarium operations teams throughout the United States, the production of seven intermediate service blueprints, and a lot of cleanup to make sure it was as communicative as possible. It remains a critical resource to the product management team today.
One shouldn’t have to sell the concept of three-in-a-box planning, where product management, design, and engineering get together to make product decisions, but sometimes conditions make it necessary. In this case, product managers and engineers embattled by an overwhelming pile of customer commitments had been in hurry-up mode so long that they felt the only way to survive was to be heads-down and ask as few questions as possible. Just accept a brief and punch out a feature, quick and broken. It’s no way to live.
At Concentric Sky we delivered some form of design system or pattern library to every client depending on their needs and the maturity of the digital property we were working on. For Western Governors University we were working on a new internal tool to manage rich skill descriptors (RSDs), but worked on a complete pattern library up front to speed our own development of the first version of the tool and enable rapid improvements in subsequent projects.
Central to this effort was the Acceptance Criteria for Patterns document pictured here. The document included a block diagram of a typical page, followed by descriptions of the form and expected behavior of each pattern, and which smaller patterns each larger pattern incorporates. Each pattern also links the corresponding part of the design system.
The document serves as a reference to front- and back-end developers and QA, and greatly sped the production of shared code and the subsequent testing of the views and workflows produced. It’s estimated that front-end views for the first version of the tool took less than half the time to develop and test one the patterns were in place, and QA commentary was able to focus on larger behavioral questions rather than detailed control behavior and layout.
I was the primary author of this document, though several people helped, and the feedback from engineering and QA was invaluable in improving it.
This document has served as a model for subsequent pattern libraries.
The Velop Whole-Home Wi-Fi System is a collection of identical routers that work together to behave as a single virtual device, blanketing your home in fast and strong Wi-Fi coverage without the usual degradation in speed provided by traditional range extenders. They connect to each other wirelessly over dedicated channels, or can be connected via wire, distributing Wi-Fi radios and Ethernet ports around your home where you need them.
One Velop node is a very nice Wi-Fi router, and two or three will provide excellent range and speed for larger homes. To make setting up this multi-unit system as straightforward as possible we devised an app-based routine that detects available nodes and offers them to the user, walks them through the minimal wiring tasks necessary, detects their Internet settings, assists with the placement of nodes, and shows their network growing as they succeed in setting up each node in turn.
The industrial design is a strong counterpoint to traditional “dead bug” networking products, incorporating 360° design, thoughtful cable management, and a simple yet informative single LED indicator. This makes for a product that people don’t feel they need to hide behind furniture or in a closet. The tall narrow shape has a small footprint, yet elevates internal antennas for the best possible wireless performance.
My role: Software and firmware product owner, and leader of the UX, UI, Industrial Design, and Mechanical Engineering teams. Determined core experiential attributes of product, and served as Scrum product owner on multiple blended teams simultaneously. Developed software roadmap and co-developed hardware roadmap.
Lessons learned: Mixed product ownership is tricky, made less so when the co-owners have distinct areas of focus yet conspire to make a very nice product together. In volleyball one is often told to “improve the ball,” to make the job of those around you at least slightly easier with each touch. If co-owners do this they can make a fine thing, indeed.
Wemo is a family of intelligent products for the home that allow you to control and see the status of switches, lights, and other devices, via your phone, from anywhere. We started with a plug-in switch module and a motion sensor, then quickly expanded to a power-measuring switch (Wemo Insight), a light switch, various LED lighting products, a heater, humidifier, and slow-cooker, and recently a dimmer. A smaller version of the original switch module, dubbed Wemo Mini, launched at the beginning of 2017.
My role: Made formative experience sketches for the product line that continue to govern the way the system operates, for better or worse. Formed the UX team with select members of my design staff and lead them into designing in a semi-Agile process in order to better integrate with the rapidly-forming software and cloud teams. Groomed one of their number to be the eventual UX manager for Wemo as a reorganization approached so I could turn my attention to rescuing the design and interactive components of the Linksys division.
Lessons learned: You must be clear what the core of your product is, lest you dilute your message in your eagerness to expand the product line. Inappropriate product partners make for messy divorces and disappointed children/employees. People notice if you fail to refresh visually, even as functionality continues to expand.
An in-home study requiring participants to replace their existing router with one of three Belkin routers showed us that we had a lot of work to do. People surprised us at every turn, losing instructions, getting turned around in instructions, not understanding which cable was which, plugging things into the wrong places, etc. One nice lady even plugged the power supply cable into the headphone jack on her computer, because it sort of looked like it belonged there and she had missed the step where she was to give power to the new router.
Removing opportunities for mistakes became the order of the day. An order-tolerant setup process, pre-connected cables, and instructions directly on the parts in question scored very well when tested in the lab and among the public when sold. Setup-related support calls were reduced significantly and an entire class of wiring-related calls went nearly to zero.
In addition, we removed several opportunities for mistakes or confusion by shipping the router pre-secured, with a network name and password printed on a card. This could be changed by users at any time or during setup, and included blanks on the back to write their new settings if desired. Later routers included a slot on the foot for the card to be stored. This card significantly reduced the volume of “what’s my network password” support calls.
My role: lead designer and usability tester, led diagnostic in-home studies, cajoled Customer Care to analyze and report call data in ways that could spur action among Design and Product Management
Lessons learned: there’s always room to reduce opportunities for mistakes. User attention is fragile and singular; you can direct it where you need to, but not too many times. The emotional support role of a setup process dare not be neglected; when done well it inspires confidence in your product. When done poorly the person may not believe your product is working well even when it is.
I served on the Belkin Values committee with the CEO, VP of Design, VP of Human Resources, and another designer, with the guidance of the Emotive Brand agency from San Francisco. We aimed to overturn Belkin’s prior very pedestrian brand and values statements in favor of discovered values, in-place already, that we felt represented strengths worth emphasizing. It was a grueling process but these values are in use every day and form a meaningful portion of employee evaluations.
My favorite is “pursue the ideal,” which acknowledges that the ideal is out of reach, and does not ask for optimization of your small area of the business but instead for you to stretch with others to identify and get ever closer to a shared ideal.
Each value is succinct and memorable, and supported by the others.
A skunkworks project to make a wearable remote for an insulin pump and glucose sensor, based on an existing LCD driver with limited segment count, led naturally to wondering: what if it were really a watch, that looked and worked like a watch?
In 2006 this was a fairly radical thought, especially the digital crown and repurposing existing analog watch behaviors for everyday control.
The initial impulse behind this project was to use a controller capable of driving a limited number of segments (I think it was around 170 segments) to make a watch-like object.
Along the way I experimented with digital watch-style multi-button control methods as well, but since a working prototype was never made the results were never usability-tested. I did make a non-functional physical prototype much in the manner of an old-school piano practice board.
My role: concepts, interactive specifications, hallway testing with interested employees who were also patients
Lessons learned: there’s no substitute for a prototype of any fidelity, and designing for fixed segments is a much different and more limiting beast than pixel-based displays.
As a demonstration and educational tool, and to preview to executives anticipated sensor data analysis capabilities, we made a Windows application that simulated three typical insulin-dependent diabetic patients. One could elect to be the physician, reviewing three days of the patient’s recent history and making adjustments to insulin pump settings to improve their care, or choose to be the patient, selecting meals and insulin dosages over a two day period and seeing how your blood glucose responded to your choices.
My role: concept, interaction and visual design, patient selection and operationalization, and numerous demonstrations to executives, visiting endocrinologists, and community groups
Lessons learned: A skilled, flexible developer and a designer who listens can make an experiment into something special, if they are both grounded in the subject matter.
