One concept I've been kicking around for a while is a broader definition of
"design". A mentor and colleague of mine—Phil Haine over at Obvious
Design—has been working a similar idea that he calls the design pyramid. The
basic premise is that there are multiple stages of creating a new product
that includes information gathering, problem definition, and refinement, and
that these steps are required before you even get to design. Each of those
stages benefits heavily from having "design thinking" (for lack of a better
term) applied. All too often, designers are not brought in until the "design
phase" when they are handed the results of these early stages and are
expected to take them as gospel and produce a brilliant design from that.
But the foundation of the pyramid is not solid. The problem definition
includes language that forces particular solutions, or the premise of the
user need is suspect or even missing altogether. And too often, not nearly
enough time and due diligence is put into the foundational work up-front, so
that during the design and even implementation and testing, the
foundation—requirements, user needs, and even vision itself—changes.
I'm not sure if I'm being overly pessimistic here, or just realistic. But
either way, I'm thinking of pitching my role to the team as a *problem
solver*. In the early stages, I'm the *problem definer* who can gather
information and pull it together into understanding of users and their unmet
needs and desires. From there, I can help generate product requirements with
each one directly linked to an observed user need, and each one also phrased
in such a way as to leave the actual solution/implementation details up to
the designers and developers. And finally, I can test the requirements, make
sure they form a cohesive vision, and spend time up-front to iterate on
them, plug any holes, fix any inconsistencies, sell the vision to the team
and execs and generally make sure that they will stand as is with little to
no modifications throughout the entire project.
With that done, I become the *solution designer*. I take the vision and
requirements, brainstorm a myriad of ways to solve the problem, mock up,
prototype, review, test, revise… you know, all the good stuff we do today.
But with the advantage that I'm not using my design time to help the team
feel around in the dark trying to find the right design by producing and
eliminating all of the wrong ones.
What do you all think of this? Do you think the problem definer should be a
different person than the solution designer? Is there a way to frame this to
help get acceptance of the idea on project teams? Do you already feel your
organization is doing this well? Looking forward to your diverse and