I’ve had experience with a bunch of different development methodologies in my career, starting with military acquisition–the problems of which (e.g. the $600 hammer stories) led to many changes in project management (e.g. PMBOK), lean processes, the agile manifesto etc. None of these methods, as implemented, was ideologically ‘pure’, they were more “-ish”: waterfall-ish research with spiral-ish development then agile-ish incremental releases, for example.
Currently, it seems most every software development shop is doing some sort of agile process, and therefore UX design is involved. At first glance, it seems like Agile is ideally suited for user centered design:
Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. (smartsheet)
In practice though, the standard complaints always seem to come up: we don’t know what the requirements are, UX is always changing their mind, we don’t have time to test we have to ship, yada yada yada.
So when you do take the time to understand the user problem, prototype and test and iterate to define a solution, you get the complaint: “You’re just doing Waterfall, man/dude!” To which I could respond “So?”, but as a good UXer I take time to peel back to the root concern. Usually it is that the identified solution represents a big bunch of work (i.e. requirements) that is either 1. too big to accomplish, or 2. for the Agile zealots, not compatible with the ‘no planning!’ ideology (or for lean UX – no documents). It is the fear of ‘Big Design Up Front‘ and all the horror that comes with it…
The thing is, with user experience, you need to understand what the thing is you need to build — the problem and the solution. You can’t go into Sprint 0 saying you don’t know what the problem is. That might be fine for the startup mentality, where you can pivot if nobody clicks your ‘MVP’, and you don’t have to actually make money. But for any company with over 3 employees you likely want to reduce the risk of wasting your time and annoying your customers.
I like to use the 80/20 rule in how my UX design team is spending their time – 80% on the next thing (or the R(esearch) side of R&D) and 20% on the thing currently being built (D-velopment). The ‘double diamond’ that Peter Merholz expanded describes this well in a picture:
The definition stage could even include the MVP prototype leading to understanding that you got the wrong strategy, kill it before you go to execution. But most of the time you will validate the strategy and have a good idea of what exactly needs to be built. The execution can be as ‘specified’ (requirements docs) or ‘lean’ (tell the guy sitting next to you what you need) as fits your culture and risk tolerance level, and as brief or complete as well. You can do it in a week or a year.
The concern that ‘we can’t get all that done’ is addressed by the story mapping and breakdown — which I see is the big issue, not enough time is spent getting this right, with the product owner and developers. Maybe because they are afraid of planning?
So BDUF… Big Definition Up Front isn’t a thing to be feared.