Product Management + User Experience Had a Baby
...and it's called "Behavioral Systems Service Experience Design Innovation"... or something.
There has been a lot of talk recently about questioning the scope of experience design within business: In Adam Conner's article for Mad Pow, he states: "I believe Experience Design should be defined as a specific approach to design that treats the product as secondary and determined purely based on the ability to contribute to the creation of a desired experience." I tend to agree with this statement about the expansion of UX from the screen or product to the holistic experience and I also think it gets at the heart of the conversation on Design Thinking and other related innovation discussions.
In Sarah Malin's response to Bruce Nussbaum's Article "Design Thinking: a failed experiment" she writes, "Focusing on isolated elements of design thinking neglects a “systems” understanding of the whole skill set – ignoring the increasing need for systems thinking that can take in global reality in its entirety and embrace complexity." I think its astute to speak of "systems thinking" as this gets both at the heart of what business stakeholders, product managers, and designers all are trained to do: to make decisions based on holistic and complex data and systems. I'd rather take the discussion of what to call our field out of this article and focus on defining what I see the environment to be.
"I am a problems guy, you're the solutions gal."
That's a phrase I heard from a colleague of mine in terms of the relationship between his role as product manager and my role as designer. We are more alike in what we are attempting to do than many people think. In fact, our fields are beginning to overlap in real ways that are creating tension as well as sparking the above mentioned conversations. Market research which can pinpoint potential areas for business growth is not unlike ethnographic studies that User Experience professionals do to pinpoint sucesses, failures, and identify areas for innovation. In large companies product managers may conceive the initial product idea, but in the end we (user experience practitioners) are the ones at the front lines of the interface between that product or service and the consumer. How can we make informed decisions about that interface without being part of the team that conceives, strategizes, and maps out the plan for not only what that product is but when and how the consumer will interact with it? It's like asking someone to make really pretty wrapping paper.
I want to be both a problem identifier and a solutions gal.
I want to help identify the experience gaps! Without having background into why decisions were made and previous history on the strategy and technology we can't help fill in the necessary holes in the experience, nor can we make informed decisions on the design. The problem here is a perceived lack of trust. By saying we want to be involved in the lifecycle of the product and service development phase, Product Managers and Business Stakeholders may not see the need any may even feel offended. They are trained specifically in market research, finance, complex decision making, yet we are trained in people and the creative thinking that will add value to those phases of that project and better inform both the design phase and the final outcome. We don't only want to present to business, we want to work together. And not just at then end phase, but from the formulation for the strategy phase. Why? Because design and business both want the same thing: a great product that our customers will love.
Asking lot's of questions leads to questioning.
I tend to ask a lot of questions, questions directed towards product managers, engineers, and other user experience colleagues. It is from these questions that I get the best ideas for designs, not from requirements documents or internal reviews. It is also from these questions that I believe I communicate most effectively, because by having a clearer picture of the larger system I can make more creative solutions from knowing the parameters before me. Then by then mapping the design back to the answers I get, the larger team sees the value of the questions when at first they may not have. This may seem commonsense, but I have been asked "Why do you need to know that? How is that related to design?" and told that I should not, "try to boil the ocean" by thinking to broadly.