Handcuffed to Aliens: Developing Stronger Cross-functional Partnerships with Design
Ten years ago, a publisher offered me a contract to write a business book with the working title, Handcuffed to Aliens: The People, Process, and Politics of Managing User-Centered Design.
The title came from a misremembered “Star Trek: The Next Generation” episode. Captain Picard wakes up on a strange planet to discover he’s handcuffed to an alien. The alien is just as surprised as he is. They have no common language or shared culture or other means of communication. Under the circumstances, they assume they’re enemies and start fighting. Gradually, they realize they have a common enemy who wants them both dead. They must learn to cooperate in order to survive until they can be rescued.
My husband, who is also a designer, told me about this episode one evening while lamenting how hard it is to get teams working harmoniously. I immediately seized on the idea for my book. It’s a wonderful metaphor for what’s most difficult about managing design projects.
Later, to our great dismay, we discovered that Captain Picard does get stranded with an alien, and they do have to learn to work together to survive, but alas, no handcuffs.
Anyway, I never wrote that book. (Life intervened in wonderful and terrible ways, and I wrote this book instead.) The metaphor stuck, though. I thought of it recently when I read in Harvard Business Review that 75% of cross-functional teams are dysfunctional. We have all become so much better at our jobs in the last decade, and yet it seems we still lack a shared understanding of how to work together.
At IBM Design, we are on a journey to drive pervasive excellence in every product, service, and experience we put out in the market. To do that, we must first acknowledge that our success or failure is intimately, sometimes painfully, intertwined with the success or failure of our project partners — product and program managers, engineers, marketers, client services, data scientists, sales, software architects, and more. And the barriers to cooperation are formidable. Often our stakeholders and partners think about and approach problems very differently. We use different words to describe the same thing (e.g., ‘conceptual design’ vs. ‘Phase 0’). Sometimes we use the same word to describe different things (e.g., ‘design’ = the way things look vs. ‘design’ = the way things work). It can indeed feel like we come from entirely different planets.
We need a shared language.
To work better together — in essence, to become One IBM — we must take a page from Captain Picard, and find a way to communicate. As designers, we’re not starting from scratch: We have a “Business of Design Field Guide” created by a team in IBM Software, and our quarterly earnings debriefs for designers led by Design Program Director, Seth Johnson. We need to build on these strong, early efforts so that our designers can become more fluent in the language of business. Doing so will not only help us communicate with our business partners, it will help us infuse our design work with business value, to put our skills to their highest and best use.
We can also help our business stakeholders become fluent in the language of design.
The lightbulb went on for me recently when I was sitting in a design review with one of our software product teams. An intrepid sales representative — I’ll call him Jason — kept asking questions like “What do you mean by affordance?” and “What is a breadcrumb?” He explained apologetically that he didn’t mean to be disruptive, but he was struggling to translate what he heard into outcomes that mattered to his customers.
I applaud Jason’s efforts to learn our alien language. Now let’s make this easier for him and our other stakeholders by translating design terms into plain English, and always framing what we do in terms of customer value.
We must think and act end-to-end.
Working successfully across disciplines requires putting our world views aside and seeing life through the eyes of a customer. Designers have a great tool to make this easier for everyone: journey maps. Journey maps help us view the entire experience a customer has with IBM, identify where things go wrong, and reveal opportunities to make them go right. Best of all, we can leverage our Enterprise Design Thinking program to teach our partners to use these methods as well.
We can also provide more rigor around understanding competitors, so that we’re considering the other tools and software our customers use, and benchmarking our work against that, rather than simply comparing ourselves to ourselves.
And we can do more to leverage our Universal Experiences framework, a fantastic tool developed by IBM design leaders Sarah Brooks and Joni Saylor and their team, to help IBM create more seamless interactions by considering customer needs at every stage of their relationship with us, from learning about our products and services, to trying, buying, and using them, to getting support and help when they need it most.
We must share the responsibility of creating great experiences.
Our software teams have been developing a quality-control process called Design & User Experience (DUX) Reviews. Before a piece of software ships, we bring all stakeholders together to evaluate final designs in working code, based on a set of user-centered heuristics. At the end of the review, we give that software a grade. It doesn’t prevent a team from shipping software with a “C” or lower grade if the pressure to get to market is greater than the pressure for a quality experience. But it helps everyone get on the same page about whether a quality standard is being met.
Let’s build on this process. If we’re going to act as One IBM, we need to align incentives so that everyone feels responsible for shipping nothing but A+ products and experiences.
We must go “left of the Loop”.
Another way we can be better partners to our product and services leaders is by getting involved earlier in the product ideation process. Too often, work gets scoped and prioritized before we’ve validated that our customers need or want it.
Design can de-risk the process by mocking up early stage concepts, and getting customer feedback before a project ever hits the roadmap. While this may feel like it adds time to any one, particular project plan, it can remove years of technical debt for IBM as a whole, by ensuring we don’t build stuff no one wants.
We must invest in our Carbon Design System.
Our design system enables both designers and developers to reuse best-in-class design patterns across our products and experiences. It makes us more efficient in our work, and drives cohesion across all touchpoints, so that no matter where customers engage with us — whether it’s through IBM.com, a software product, an email, or an in-person event — they feel like they are engaging with One IBM and not the separate teams that design and build those experiences. Because we bake accessibility standards into our design system, anyone using Carbon components is automatically creating great experiences for people with different abilities. And what’s more, teams that adopt Carbon can expect up to 80% efficiencies in design and development, faster speed to market, and less maintenance — adding up to significant cost savings and time well spent.
In short, we must continue to grow and mature our design system because this is a fundamental way that we will work together as one team to scale excellence across our organization.
***
For those who are feeling like Picard, handcuffed to their business partners, how might we develop a shared understanding of how to work together? What methods or practices have worked for you to get all stakeholders working together in service of the customer? As always, I welcome feedback from inside and outside of IBM.
If you’re interested in following our journey to define the next stage of IBM Design, you can catch up here:
· Pervasive Excellence Across IBM: Three Ways Design Can Make It Happen
· Listening to Customers: Ain’t Nothing Like the Real Thing
***
The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
