Have you noticed that ‘being innovative’ and ‘producing concepts’ are all the rage at the moment? It’s very fashionable, let me tell you; and quite frankly, it’s about bloody time.
I’m not going to go into how to facilitate innovation, or why and how Apple seem to do such a good job at it all, I will however join the chorus and bluster on a bit about the common sense reasons why we need to do truckloads more concept prototyping.
The concept provides the experiential and aesthetic vision for a product, and I’m not talking just any old vision, I’m talking about a verified vision. You did remember to test it didn’t you? Yes of course you did. The vision isn’t just a well documented set of requirements, or a set of wireframes, it’s an interactive prototype that shows exactly what the final product is going to be. Why’s that? Because seeing is believing; and believing gives us confidence and direction.
The concept is what gives us focus to ensure every action we take along the way through detailed design and development support the core idea we want to bring to life. It also gives us the evidence at the end of the process to show that we did the right thing… When someone asks “But why?” you can just point to your archive of concepts and say “That’s why”.
Personally, I love doing concept work. That time when you take the core of an idea, explore it, bring it to life, verify that it works, and either nurture it or mercifully pull the plug and let it fizzle into oblivion. The work isn’t easy, in fact if you’re doing it right, starting broad and verifying each concept with real people it’s a hard slog. It takes time, it’s full of risk, but it is most certainly worth it. How else do you differentiate? How do you make something better, unique, and desirable for your customers? Importantly, how do you do it all before you actually throw down the cash and build it? There’s no other way really.
Prototypes mean less wireframes in documents, less verbiage in requirements specifications, less meetings to clarify it all and more time to go get a beer on a Friday afternoon. Arguably, wireframes (and every other bit of documentation) have their place in the process, but it’s not until the ‘thing’ starts to come to life that customers, people on the project and stakeholders truly understand what it’s all about. I’m sure there are people you love and care about that are wireframe experts, but is that bundle of paper they sweat over and push across the table to you really an articulation of the experience, or just an articulation of how hard they’ve worked for a couple of months? And when you read that weighty tome, do you immediately get how the transitions will flow, how the visual design is impacting the information design, how the panel slides out from… er, which page was that on? Well, maybe you do and that’s great; but then, how do you present that set of wireframes to your customers for testing? Perhaps with a prototype?
Where am I going with this? Nowhere everyone hasn’t been before, except to say maybe we could be keeping the process simpler, and take advantage of all of those prototyping tools out there now that make building something almost as easy as talking about it. How about not even making it a process and just having the framework to create verified, readily shared and understood concepts…
- Get insights. You need to have an ongoing program of research to deliver insights for new products, and to refine the ones you already have; just don’t go overboard with it.
- Prototype. Use the insights to drive design and explore alternatives, lots of alternatives. Think ‘many, many’ like Apple, but do it your way.
- Verify what you’ve got. Test everything, explore it with customers, make sure they can use it, want it, and don’t already have it.
- Decide. Make a decision on what you’re going to do with the concepts, and move on.
Continue reading at:
