How I Collaborate
(AKA: the page for Process People)
But first, that Agile/lean question:
Yes. I prefer agile and lean methodologies, as I have found that they work better for design. I've done it all, though, and usually seek out ways to work what I need into a client's existing process.
More brains are always better...
When we're exploring what can and should be made, we're in the open end of the double diamond (see the whole double diamond below). At this stage more brains are better, and it's the best moment to gather all the data. MOAR DATA!
To really get the most out of my skills and work, you want me to be part of this whole diamond. Many times I lead this part, sometimes I participate, but if I don't know why we're building something, what I make has virtually no chance of being successful.
I like to use workshops to get all of our hypotheses, assumptions, business goals and constraints on the table. That way, when I go off to do my individual work, I'm not focused on things my client will never do. I'll give voice to issues as they come up, but knowing these constraints in advance helps contain the research to what really needs to be known.
My individual contribution here is primary research and the insights, themes, and opportunities identified from that work, which I talk more about in Deliverables.
Where things usually turn grey
The convergence of "what should we do" is usually where we need to add the word cooperation to the team charter, because it's where the Battle for Idea Supremacy tends to emerge. It's when people start talking about roles & responsibilities; it's when I tend to hear, "you're a designer. You make it look nice."
<deep breath> A huge part of my job as a designer, and something I am well-practiced at, is taking my personal aesthetic, assumptions and biases out of whatever it is I'm making so that I am able to objectively assume the user's point of view.
So what I ask for from teams I work with is simply this: Trust me.
Trust that I am the person on the team with specific skills needed to ensure that the user has a clear and unmistakable voice in this conversation. That's my unique contribution to this part of the collaborative process.
(Did you notice that I did not say wireframes, prototypes or any other concrete deliverables? I don't believe I'm the only one who can or should be able do that work, and how I add my contribution is really part of every deliverable that gets made. I make what's needed and help other make what they need to get the job done.)
Celebrate and improve
I love making the right thing for the people who will need to use it. I love making things people need to make their own lives better. And if they want it, that's the cherry on top of the sundae.
My role in this is to help a team build things at a realistic pace with the needed level of effort. Too often we go super hi-fi too fast, involving visual designers, front-end developers, scrambling to put together APIs. What we really need first can usually be accomplished with a set of people we can test with (different people in each test) and a super basic set of screens that get the concept of a thing across.
As we test into what we eventually make, I help come up with different ways to help users achieve their goals. I'm really, really good at that. Come up with one design, then design its opposite. Then its opposite again. Refine. Test. Refine. Move up a notch in fidelity. Assess feasibility along the way.
Then, when you have to report your level of confidence to your CEO, CFO, COO and CMO about why this thing you've made will be a success -- and you already know how to measure that success -- we've made something good together.