Design Process
SUPPORTING TEAM COLLABORATION
Experience design applies as much to organizations as it does to software. Everybody in an organization has great ideas, and experience designers know how to create frameworks and structures that bring them out.
For Rhiza's 2014 Company Retreat, managers and directors were asked to create a presentation for the group. I organized a design charrette where Marketing, Sales, Development, Product, QA and Administration intermixed to work together on a five-year future vision for our platform. We set up four temporary whiteboards around four different product dimensions, from "Beautiful Visualizations" to "Interoperability". Each small team worked for five minutes to sketch out a system, service, or interface around their product dimension. When we called time, each team briefed its idea to the whole group for about a minute, then everybody moved one whiteboard to the right, where they elaborated on or edited the previous team's work in a different product dimension. Lather, rinse, re-brief.
Exercises like this get everybody buzzing and energized, and they reinforce something I've seen time and again in my professional practice: people like to have skin in the game. Management presentations to a team are all well and good, and sometimes necessary, but nothing turns a group of coworkers into a team like creating an environment where everybody can play.
Team-wide design charette at Rhiza's corporate retreat at PNC Stadium, spring 2014.
I recruited two Rhiza team-members to help facilitate the design exercise at the company retreat. Here, we’re testing prompts and rehearsing the full exercise so the facilitators understand how the process can play out in practice. Rhiza labs, with Judd Poeske and Michelle Gittleman, spring 2014.
WRANGLING CHAOS INTO ACTIONABLE CONTENT
It can be difficult to get access to any user community, especially expert users whose time is in high demand. Every collaborative user design session is a kind of improvisational performance that should be backed up, before and after, with hours of planning, research, rehearsal, and artifact-curation. A UPMC Enterprises’ design engagement with clinicians and medical directors takes months to arrange and prepare for, and access to those user-communities is never a given. Every user event should invite further engagement through actionable artifacts that preserve and extend the knowledge created in the room.
DESIGN IN THE WILD
All happy design-consultancies are alike: their websites all have the same soft-focus photographs of well-dressed people in beautiful ivory-tower design citadels, gesturing at perfectly-aligned Post-Its on enormous, pristine whiteboards. My design reality doesn't often look like that. It's messy. We're meeting our users on their turf. We've traveled far and eaten weird. We're tired, uncomfortable, anxious, out of our element, and soon we'll have to perform a kind of improv in front of a group of potentially hostile strangers. In my experience, the pretty design stuff is bullshit. Real design is a mess. The place where you meet your users is often out of your control. You're wrangling competing streams of chaos into a story that's only as coherent as you are. Your only recourse is to trust your process, your preparation, your training and your team.
A radiology workstation in the wild. We use images like this as evidence for developing responsive interfaces that can be used effortlessly in non-standard setups (portrait-mode monitors, multiple-monitor setups). UPMC Enterprises and GE, Kingman AZ, winter 2016.
A radiologists at his workstation at the Kingman Regional Medical Center in Arizona. At UPMC Enterprises, designers accompanied Product Owners on discovery and rollout trips. I presented findings from these visits to our colleagues back home, to assist in our own rollout efforts and give developers a sense of the visceral frustration users sometimes feel for our products. UPMC Enterprises and GE, Kingman AZ winter 2016.
Rhiza’s users were marketing analysts and ad-sales professionals at companies like Comcast, Nielsen, and CoxReps. During user research visits, we took photographs and made copies of Excel tools our users developed on their own to handle their data needs. Tools like this are often passed around among users in the wild and eventually become entrenched as a sort of informal legacy product. They’re an excellent resource for product, design, and development teams trying to understand users’ mental models for data analytics and their specific needs. Rhiza, winter 2015.
A sticky breakfast table at a cafe in Baumholder, Germany in March 2012, where my colleagues and I worked out the final plan for a two-day usability exercise on a part of our platform that had been years in the making. We'd all arrived that morning on different flights, then driven hours through a rainstorm from the airport in Frankfurt, and we were beyond fried. We'd planned the individual exercises in detail before leaving home, but hadn't yet put all the pieces together into an orchestrated whole. This ugly, wonderful table was the only surface we could find in our tiny hotel that was big enough to build out our plan and work on it together. These were very much sub-optimal conditions for planning and creativity, and exactly the conditions where years of training and practice take over. Summon coffee. Uncap pens, crack open Post-Its, consult your fussy jottings-filled notebook. Take a deep breath and invoke the memory of the many design engagements you've already planned and run and seen through to their ends in finished, delivered software, including those that sometimes delighted your users. With Becky Torbochkin, Ruben Carbonell, Chuck Slacker and Kristof Batizy, General Dynamics | Viz, Baumholder, Germany, spring 2012.
Users in Baumholder, Germany, heads-down and immersed in one of the usability exercises we'd planned for them. With Becky Torbochkin (who took this photograph), Ruben Carbonell, Chuck Slacker and Kristof Batizy, General Dynamics | Viz spring 2012.
BRINGING IT BACK HOME
Designers have a charmed life: we go to user exercises and UX conferences and sketch and draw and imagine while developers toil in the saltmines and sub-basements of implementation. I never take it for granted. I grew up with people who were not engineers, and every minute I've been allowed to spend in the company of engineers has deepened my respect and admiration for the work they do. Part of my job is to share everything I learn with engineers so they can think about how to build the things users want. Part of my design-team's practice is to brief the engineers and other stakeholders on every user engagement and UX conference we attend.
Like many big software shops that employ design teams -- particularly those with users in specialized or hard-to-reach environments -- the developers on my team at GD rarely interacted directly with the people who used the software they built. Designers went out to meet users as emissaries and ambassadors of the software, walking the tricky line between empathizing with users and understanding our technical and procedural limits. As a matter of both temperament and team-practice, my design team brought information back from user-land to dev-land after every outside engagement. The image above comes from a slide presentation I put together for our dev team describing one of the most common and deadly problems our users encountered -- losing satellite connectivity to tracking devices that showed the position of trucks in a supply convoy. General Dynamics | Viz 2013.
A presentation I prepared on artificial intelligence and neural networks, part of a UPMC Enterprises internal Lunch and Learn series, organized by my colleague Ally Shah, intended to develop a baseline of shared knowledge on general AI topics throughout the organization. With Ally Shah, Rehan Butt, Greg Barry and Anthony Shea, spring 2019.
A summary presentation I prepared and delivered to product managers, engineers and designers at GD Viz on the IA Summit Conference, spring 2o13.
I attended an Event Apart conference on the Disney World campus in 2018. When I asked my fellow designers whether they wanted a full conference recap or a comparison of the user experience at Disney World, Universal Studios and Kennywood, they unanimously wanted to look at pictures of UX-in-the-wild as practiced in theme park design. Winter 2018.
DESCRIBING & IMPROVING INTERNAL PROCESSES
I’m a UX generalist, but I’ll always have a soft spot for enterprise product design, the unloved ugly duckling of the UX community. It’s tough to find experienced designers who want to do this work, which almost always involves inheriting a backlog crammed with the aspirations of long-gone generations of previous designers and product teams. The house of enterprise design is always a mess, which means design skills can be deployed beyond the product itself, from team onboarding to release planning. Big distributed teams don’t always have the benefit of high-bandwidth in-person communications; design can help make up for that loss with more considered communication artifacts — and better team communication ultimately benefits users. There’s always plenty for a pragmatist to do.
An onboarding artifact showing which people work on which products and how the products are connected. Designers have a role to play in helping their colleagues understand not just the people they’re building for, but also the people they’re building with. UPMCE Enterprises and GE, winter 2018.
A Game of Thrones-themed onboarding brief describing the dryest topic in the world — the evolution of our internal design docs process. UPMCE Enterprises, spring 2019.
Even smaller organizations benefit from process-definition artifacts. From 2014 to 2016, I was director of design at Rhiza Labs, a small startup in Pittsburgh that developed marketing and big-data analytics software. The tightly-knit, co-located development team was a fast-moving powerhouse of rapid iteration and agile development. Usually that level of hustle and agility was great, but every now and then someone on the team would make a change with no usability testing, internal or otherwise. I put together this internal presentation to the team describing the rationale behind a more managed process for even minor user-facing changes, and arguing for adequate time and resources for responsible internal usability testing. Rhiza, summer 2014.
