Design Recon
Silos Are for Grain: Part 1 of 5
More and more designers are seeing the need to gain bigger influence in their organization and be involved earlier in the decision making process. However, if you want designers to have a seat at your organization’s decision-making table, the other business units you work with need a seat at the design table.
This was a lesson I learned the hard way when I moved from smaller start-up company to the enterprise behemoth that is Adobe. I learned that much in the same way that you shouldn’t try to run an enterprise-sized tech company on hardware from your start-up, you shouldn’t be running it on a start-up-style design process.
Here on the Adobe Analytics team, we’ve developed a cross-functional process of research, iteration, and testing that’s led to some of our most successful product releases to date. Central to that process is the underlying principle that cross-functional product teams should not and cannot work in silos. In this first of a five-part series, we’ll cover the backstory of this design process in addition to the first step.
Backstory
Let’s talk about the how and the why of making changes to our cross-functional design processes.
As a fresh face and a young gun on the Adobe Analytics design team, I had grand aspirations for all sorts of meaningful contributions I could make to this complex and exciting product. It was a bit of a slap in the face when I presented my first proposed design and I had it chopped into pieces by the product team that included other designers, engineers, project management, and product management. From the underlying technology to historical user behavior, there were so many aspects I failed to take into consideration.
So with a renewed sense of purpose, and some guidance from my senior management, I decided that I would be thoroughly prepared for the next design review. I conducted user research around the personas we were targeting. I gathered information around the problem. I used the product managers to establish realistic use cases and persona narratives. I even put together some Invision walkthroughs to test dumb (non-reponsive) prototypes with users. With all of my work, I was fairly confident that this design review would fare much better.
I got destroyed. Again.
Fortunately what I had done unintentionally was to isolate the variable that was causing the other cross-functional teams to lose confidence in the design. It wasn’t the quality of the design. It wasn’t the buy-in to the presented persona. It wasn’t a lack of research. It wasn’t even bad presentation skills.
It was more than 10 years of very well-informed biases that different teams were bringing to the conversation.
This was a product that had been around for more than a decade, and so the engineers, project managers, and even program managers had totally valid opinions that hadn’t been vetted or explored during my design process. That’s when I knew that the problem we had wasn’t a execution problem. It was a process and relationship problem. I had locked myself in my design silo, often cited as an ivory tower, and as a result the design was weak and the buy-in was even weaker.
That’s when we know something had to change. That’s when the R.I.P.I.R design process was born.
For the majority of you seasoned experience designers reading this, there will be nothing ground-breaking about this design process. But what I hope you can take away from this article is this: making every member across your cross-functional organization into a deputized designer is vital. Complex enterprise software development is a place where one worn out axiom is incredibly relevant: Two heads are better than one.
Additionally, people will support and drive your designs when those designs reflect their own opinions. They will also be equipped to make the thousands of micro-decisions that you just won’t have to the time or bandwidth to address. And the only way to get that level of alignment to happen is through involving them in every step of the process.
Let’s take a look at what that looks like.
First a quick overview of what R.I.P.I.R., step-by-step, stands for:
- Recon
- Internal
- Prototype
- Iterate
- Re-test
Step One: Recon
There is a very specific reason that this first step is called Recon as opposed to research. Research, in my opinion, is often confused with user testing. This means that whenever we refer to “research” in a design context, it implies the designer is presenting subject with visual and/or audio stimuli to observe a reaction to said stimuli.
While this step, which we typically call user testing, is invaluable, when you are still forming your hypothesis and problem statements, you would already be contaminating your test subjects by presenting them with solutions or even suggestions of problems.
What is needed at this stage is the type of research that is most analogous to what film documentary film crews might be doing: Observation without involvement. Sure, that observation should be followed up with some additional questions to get further context, but the true goal is to understand the current process that exists in their day-to-day life.
As I frequently tell students in my Interaction Design class at the University of Utah, the hardest thing we have to design as digital product designers is to design the problem.
Solutions are the easy part.
And there is no way you can truly distill the problem to its most basic form if you are clouding it with potential solutions and suggestions.
But wait, there’s more…
This entire process of recon, observation, and context-gathering should never be a design specific task. You could have the most beautifully eloquent problem statement that perfectly reflects the users’ friction, but if it is at odds with the (very valid) anecdotal evidence your developer has from the last customer conference, you can kiss all of your hard work away.
That is why I enforce the strict rule that in every step in the R.I.P.I.R process, there has to be representation from each member of the what I have termed the “Product Godhead” — design, engineering, and product management. They will ask questions that you would have never asked that will inform you designs. Beyond that, by being made a “deputy designer” they will be understandably more invested in the process and proposed solution.
The final step in the Recon part of this design process is consensus. Even in having representation from every member of the Product Godhead, you can still walk out of your recon meeting with wildly different takeaways.
We’re only human. We hear what we want to hear.
That’s why it is important to hold a quorum to gain consensus around the nature of the problem you are trying to solve before you ever think about designing a solution. And by using the collective braintrust that you have at your disposal, by virtue of working at an enterprise organization, your problem will be that much better articulated.
In taking all of these precautions and proactive measures to involve the entire development team, you will have set up your team for success in the next steps. In giving your cross-functional teammates a seat at your table, I can attest that they will be way more willing to give us a seat at theirs. By focusing on collaboration this early on, you are setting yourself up to remove your developmental silos from every single step of your product development process.
Tune in next month when we cover the second step: Internal– which touches on wire-framing, lo/hi-fidelity mock-ups, and building internal momentum.
