Darwinian Product Design
and the natural selection of creative ideas
I’ve been practicing interaction design professionally for 18 years– over 25 years if you count the animation and game design I did in my adolescence — anyone remember Fantavision?
At the start of my career, if I had an idea I would design and build it. However, throughout the many years of working with companies, brands and marketing agencies on large projects with multidisciplinary teams, my design process eventually ‘evolved’ to the point where I would communicate ideas as highly detailed design deliverables and functional specifications.
I took great pride in documenting every detail, so that when the development team asked me about something, I could point out that it was already provided in the documentation. Despite the fact that this would routinely happen, I thought the problem was with people not taking the time to read the documentation thoroughly, rather than a problem with the process itself.
Around 2007, I began to feel a sort of professional/personal dissonance between the accepted wisdom and processes of interactive product design and user experience I would profess, and my observation of the issues I would see arise time and time again through the development process. I started to realise that, even if the developers read and understood the design documentation (which never happened), and if they built it faithfully without needing to make changes due to technology constraints (which never happened) — at the end of the project, when the product went through the final rounds of testing and validation with the target audience — there would still be problems with the original design. Obvious problems, that despite how many rounds of concept testing, paper prototyping, or clickable mockups we’d put in front of people, the fully functional system had interaction design flaws.
So then the developers got their revenge, as I would have to place my design issues into a bug tracker, which would usually get marked as a low priority because they weren’t part of the signed off design documentation.
I accepted this back-and-forth dance for a very long time, as par for the course, until I realised a fundamental problem with design specifications, namely– interaction design isn’t interaction design until it’s interactive.
For the next few years, I immediately began to work on unlearning all of the process and tools I’d been using, and by 2008, I put my thinking on the design process into a presentation called Information Architecture is Broken. This was effectively my mission statement when I joined Agency.com as Head of Information Architecture.
However, I found that, as a design industry, we’d been far too effective at communicating our (broken) process. So much so, that when I told clients that we wanted to skip wireframes and go from user stories directly into prototypes — they rejected the idea. Clients had been through the agency design process previously, and they insisted that we proceed with the ‘normal’ activities of concept documents, wireframes, user scenarios, and flows, etc. etc.
Gradually the market has changed. Today, you hear everyone talking about ‘designing in code’ and I’ve done a lot of prototyping as an independent consultant, but it’s only recently that I’ve been able to put into practice a process with a creative team, in my current role as the Creative Director of Mindshapes.
I call it Darwinian Product Design.
The premise is simple. If someone has an idea: Show it, Develop it, Review it– and Don’t Reject it. And this goes for anyone on the team. Designers, developers, project managers, anyone.
Show it
If you have an idea, draw it, sketch it, cut & paste it– make it look real somehow. Communicate visually. No one gets to use the excuse — “but I’m not a designer!”
Develop it
If you can visualise it, then push the idea further. Make it clickable (we use Flinto for that). Once it’s clickable, build out the interaction into a lightly functional prototype (we use Hype for that).
Review it
Have a weekly review of the new ideas– and here’s the hard part– everyone can make suggestions, but no one can reject anything. Don’t kill off any concepts. The team may choose to present only the top 2-3 concepts to a client, but if a team member is enthusiastic about their idea, let them continue to develop it.
Seeing this in practice, I’ve found that the good ideas naturally float to the top, and the weaker ideas will fall by the wayside as the team loses interest in them.
It’s the natural selection of design concepts, and as Creative Director, I try to foster an environment for a continuous cambrian explosion of ideas at each of our review sessions. Later, as the team becomes busier, we invest our time in the ideas we think are most viable, without the negativity of anyone having their idea shot down– and that means they’ll be open to express their creative ideas again in the future.
You never know– the one idea that someone is passionate about enough to fully prototype, even though the team couldn’t see where it was going, could be your next game-changing product.
