As I have said many times before, I don’t subscribe to the notion that design within an organization should be something that the one “creative person” or group of “creative people” should solely be responsible for. Ever since my final semester of graduate school and into my professional career in User Experience design, I have been driven by a desire to remove the “mystery” of design and make the process more transparent. In response to one my colleague’s blog posts regarding the need for Design Language, Rationale, and Accountability that spans across organizations, I have written the following thoughts. The thing that is so key to successful design within large organizations is for everyone to acknowledge their role in the design of the product, and to be clear about what is known and unknown.
What my friend calls “Designing with Others” I just call “Designing”. My design training and self-study has taught me that when it comes to the design of technology within large organizations, 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 – perhaps because that is the way they have interacted with UX designers in the past. Here are some of the things that I do every day to ensure that I don’t just sit in my cube and design stuff.
I have lots of brainstorming meetings with the product manager and development team – much more often than with other designers. 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…“You are the designer, why are you asking me what we should do?” or better yet, ”Why aren’t you talking about this with the design team?” The answer to the second one might be specific to my work environment – each product typically only has one designer on it. Since my fellow designers are much less familiar with my product than I am, the feedback they are capable of giving often only falls into superficial territory – preferences about fonts and layout – but nothing mission critical to the product. That’s why I need the product managers, consultants, and developers to help shape the product – not more designers.
After trudging 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 the weekly or bi-weekly “design dumps” that only allow the other stakeholders to see the work after it has pretty much been completed. 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. For me 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. While I sometimes sense that they don’t like how many questions I ask or how often I pop in and say “Hey, you got five or ten minutes to work through something with me?”, I know that the benefits of having everyone contributing and understanding outweighs the small interruptions throughout the day. It is less than ideal, but worth it in the long run.
And as I seek to inject the organizational process with the language of design, I make sure to learn the language of business and development and refer to it when appropriate. Let’s be real about it: I am 1 designer on a team with 10 programmers, 1 lead engineer, and 1 product manager inside of an organization with hundreds of programmers, dozens of sales staff, and 11 designers. My success lies in my ability to navigate the language of business and development, and find ways to make design resonate with them in their own terms. I have heard this called “rational resonance.”
All of the preceding stuff relates to including stakeholders to make transparent the language and rationale, but the notion of design accountability (in the sense that an act of creation is oftentimes a leap of faith) 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 in organizations that don’t have “perfect” design processes, there isn’t always time for lots of prototyping.
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, or if we had accurate user data – making them things that fit in our realm of design accountability).
But as my friend said in his post, the implications (and before that the DEFINITIONS) of Design Language, Rationale, and Accountability are too complex and context-dependent to put in a single blog post. Nevertheless I will continue doing what I can to create an environment where good design is recognized and can be implemented.
