What’s so bad about early solutions?
I’m sure we’ve all witnessed the act of self censorship where a team member caveats their statement by saying; ‘forgive me for early solutioning but….’. I’m beginning to wonder whether it’s as bad as we’ve come to assume?
In a ‘traditional’ user first projects, we discourage solutions that are designed without evidence. We do this to enable us to justify a design solution with an identified user need.
How often though, is the project team able to rapidly design and build (to a testable state) a product or service, early in the project? Though this sounds like the antithesis of User first methodology, enabling the user researchers to test with (admittedly flawed) prototypes as early in the project as possible results, (currently anecdotally) to enable iterative refinement to begin at a significantly earlier stage.
As anyone who has attended a Gov.uk service assessment will know, there is a strong push to present lots of iterated prototypes, often a broad as possible, demonstrating the projects relationship with a larger service, which takes time and effort to design and build.
I believe that early prototyping can be done without engaging (or requiring) any technical input beyond the ability to use the prototyping toolkit, and deployment to heroku (for example). This doesn’t require a dev-ops delivery pipeline, or complicated data source, just a cloud based demo using ‘life like’ data.
User researchers operating as testers can quickly move for qualitative narrative interviews, to task based user testing in weeks. I feel the feedback gathered from showing someone the ‘wrong’ thing and rapidly iterating will enable us to be less wrong before the formal dev work has even begun.
Of course we need to be less precious about prototypes, and truly use them as disposable discovery tools. Whether a team is mature enough, or can silence their egos enough to do this is another question.
