Designing with Others


I’ve always believed that a good designer shouldn’t “work in a vacuum” – this design statement is often thought of as a pleasantry, but rarely becomes a mantra or philosophy of action for most designers. Reflecting upon this statement certainly yields insights that influence the way we design, and some designers may find that such reasoning challenges their predispositions of what “design” should be; if you shouldn’t design alone in isolation, then what should you do?

If designing isn’t an act of working alone, then it must be an act that involves multiple persons (stakeholders). This is the conclusion where designers get to before panic sets in and they become short of breath. We know we should involve others, we just don’t know how to do it! How often do we hear that “designers are hard to work with”? How often do designers say that others “don’t get it”? As designers, we know that we can’t work in isolation, but the evidence of our inability to work with non-designers has become commonplace. I propose three principles that give direction, that offer a “to-do” framework for anyone inclined to embrace and believe that designing shouldn’t take place in a vacuum.

Design Language: designing needs to include a language of design. A design language is more than just words – it’s the syntax and processes which lead to understanding. When someone comes to a designer with sketch on a napkin or an idea from a management meeting, it would afford the participants to have a knowledge of the design processes which lies before them. Tools, methods, processes – all are languages of design. It is important for interaction designers to understand that these tools can be used to create a language of design that is shared collectively by an organization, and not just to be used by design-keepers. Organizations that have a thoughtful design language, better mediate risks and expectations. When processes and design tools are transparent, participants can understand the rational behind design ideas (including their own), and can be accountable for design solutions.

Design Rationale: designing involves critical thinking – and critical decisions. The power to act within a design space is directly related to an understanding of the constraints of that space and risk of navigating through it. If the design language is a system of transportation with routes and signals, then design rationale is the vehicle that moves participants towards the desired (and unknown) destination. All people have philosophies, understanding and constraints that form the basis of their individual rationale. Designers often have well-developed rationale for the organization, but if they are used to being a design-keeper, then will likely struggle with expressing the reasons for their actions. Having an environment where multiple stakeholders can safely express and negotiate design rational helps all participants learn about their ideas – becoming critics (thinking critically) of ideas.

Design Accountability: designers and design participants (I like the sound of that!) will quickly find out that just because there are transparent design tools and processes that are used in an environment where ideas can safely be externalized and criticized, there will still be a healthy amount of “unknown”. This is where all design participants need to celebrate “design agency” and the accountability that comes from making design decisions in an imperfect appointment of creation. Creation comes with risk. It means placing an unknown variable in a sometimes unknown situation. Organizations that embrace design accountability mediate risks by creating a culture of understanding: documenting failure, testing ideas, and reflecting upon outcomes. Most people don’t want to acknowledge the accountability afforded in “creation”.

The specific implications of these three design principles lies outside of a simple blog post. I really do believe that designers need more than just a trite statement of “how not to design” (not in a box) in order to affect the needed change within high-bandwidth organizations. Design rigor and design thinking is more than a bag of gypsy tricks or clever ideas. I really believe it has the ability to change businesses and the world we live in. Designing shouldn’t happen alone. Not unless the only person who will encounter it, speak of it, or clean up after it is the individual creating it. For all other situations, I thoughtfully leave you with the above principles.

Comments are now closed for this article

  • Chad Camara

    What you call “Designing with Others” I just call “Designing”. My design training and self-study has taught me that when it comes to User Experience Design, there is no other way to do it – so I have never really considered that design could be done by just me. I think that this is especially important in my situation, where I am the sole designer responsible for the UXD of entire products – including everything from user research to concepts to visual design to the final design deliverables passed on to the development team.

    Working on major products for a very large software company, I have noticed some interesting things related to the notion of “designing with others”. Frequently I encounter scenarios where the development teams and product managers I interact with EXPECT me to design the whole thing by myself – because that is the way they have interacted with UX designers in the past.

    With regards to your three principles – I feel that the only way to make the products better is to “design with others”, and I seek out opportunities to use and improve upon all three principles. The following are a few of my thoughts on what this has looked like for me in the past few months.

    The first few times I arranged brainstorming meetings or asked for design feedback from the product managers, product consultants, and developers I was met with perplexed looks. I know what they were thinking…”Why aren’t you talking about this with the design team?” and “You are the designer, why are you asking me what we should do?”

    But I have trudged through the initial hesitance, and now I have frequent meetings with “non-designers”. Some are scheduled formal meetings, but I also spend a lot of time running around the office doing impromptu little 5 minute brainstorms with different stakeholders, partially to get my questions answered as they pop up – but also to make my process transparent. I find this to be more effective than a weekly or bi-weekly “design dump”. It also gives me more opportunities to inject design language into the process with stakeholders, as well as ensure that all the roles that touch the product have a common understanding of where it is going. It is all about the frequency of exposure to the design process.

    While in the beginning I was met with perplexed looks, in the past few weeks while working on a major new release I have often been thanked by the development team and product manager for making their input a huge priority in my design process. This has ensured that the entire team of people working on the product feel a sense of ownership for it.

    All of the preceding stuff relates to language and rationale, but accountability is a bit trickier. I seek to acknowledge and make clear (quite often) that we cant get it “completely right” – and seek to build consensus about what we consider to be “unknown.” At times like this I cease trying to design the “perfect vision” and instead attempt to provide design deliverables that can be built upon once it is released and the “unknown” becomes the “known”. Generally this is something you want to happen as much as possible in a prototyping phase, but that isn’t something that my particular situation has a lot of bandwidth for at the moment.

    I was just saying today to a fellow designer that I can’t wait for the next release of my product so I can document and reflect upon everything we did right and what we did wrong. I plan to discuss our process with my team to help all of us understand what can be anticipated and what can’t – what we should expect to fit in our realm of design accountability and what can’t. (For instance, I hope to use this release as an opportunity to point out the problems that could have been avoided if we had prototyped things first – making them things that fit in our realm of design accountability).

    But as you said, the implications (and before that the DEFINITIONS) of these three are too complex and context-dependent to put in a single blog post. I look forward to further discussions about this with you.

  • admin

    I think “buy-in” is sometimes seen as agreement on a design idea, and not as a methodology of inclusion. While reading your feedback, I realized that with a thoughtful process of inclusion, you’ve set yourself up for more a more meaningful opportunity of “accountability”. You’re more likely to have that reflective space after the release.

    It really is difficult to have a conversation about “how we did” when you weren’t inclusive earlier on. I’d be interested in knowing how the accountability phase of your release turns out. Keep me posted.