If UX/User Research slows down development...you're doing it wrong.
It’s always assumed that product development follows an iterative methodology — lean, agile, etc. Not something we ever question at this point in history.
But what about User/UX Research?
I repeatedly come across instances where UX work is operating in a “100% upfront” way. Visual UI design may be happening in concert with development sprints, but user research is still time boxed, upfront, inside a “sprint 0” or similar step.
Maybe, if we're lucky, there's a slot for user testing toward the end, when most of the form & function decisions are already set in stone.
Development is learning, iterating, improving.
UX is standing still.
If I’ve said this once, I’ve said it a thousand times. Which makes it worth saying again:
UX is not PART of a process, not a STEP in a process.
It IS the process.
UX and User Research has to start the moment a project becomes a possibility, and it has to continue throughout every single cycle of design and development (and beyond).
This is continuous testing and improvement in small increments, which carries some very big benefits:
- A few small, incremental improvements to the UI and underlying code are a lot easier to include in a sprint than a laundry list of wide, sweeping changes.
- If you start wide when the rest of the team is starting wide, your ability to collaborate seamlessly on the narrow details — as work progresses — improves dramatically. In other words, nothing you’re doing will slow anyone else down ;-)
- Having a working prototype or build to test with increases the accuracy and relevance of the user feedback you get or behavior you observe.
There's more than one way to get there.
You'll need different techniques for different product types, different user groups and any number of obstacles to doing research at all — from time to budget to teams and managers or clients who don't believe its necessary.
Knowing how to mix and match these tools and methods, knowing when to pivot and change course, knowing how much research is enough and knowing which users matter most at any given point — isn't something any of us are explicitly taught to do.
For me, that knowledge came by way of the school of hard knocks; I have the scars to prove it ;-) But that doesn't mean you have to take the same road — particularly because I'm giving you a roadmap for each and every situation you'll ever encounter, in my Real-World UX Techniques Bootcamp.
This is an 8-week program, and it doesn't take any longer than that to master the tools and approaches I'm advocating here. Small bursts of focused research effort, each informed by the previous, along with what shows up in the build and how challenging it was to implement, win the day.
And more importantly, they ensure that research is understood, accepted and IMPLEMENTED in what's built.
The ability to deliver these small wins, small gains — repeatedly, throughout the development lifecycle — is how you become efficient, effective, respected and (wait for it...here's the big one) properly compensated as a UX professional.
I am living proof.
#givegoodux
UXC / UXM
2 年Nuno, Leon, Felipe
Design for User Experience | helping companies transform
3 年The distinction I make sounds like semantics, but I don't believe in fitting UX into Agile, agile is solely focused on development. I talk about fitting agile into UX. I try not to do a sprint zero that sandwiches between the PO delivering user stories and devs picking up the work. I try to get in early with the need that the business side has identified, researching to ensure we have the right problem and working on that on tandem with the PO doing what they need to do to get requirements ready for development.
Improving sustainability and resilience in Product Development / Coaching and teaching Product People how to thrive / Stoic Practitioner / Doughnut & circular economist / Post-growth Protagonist / ????
7 年see, Feddo Biekart