Marvel’s iPhone app for creating prototypes from sketches is a great option for anyone wanting to design and communicate an app concept without having to do a lot of Photoshop work. Clickable mock-ups can be very effective to communicate interactive design. If you do have more polished mock-ups than just pen-on-paper and you want to make them interactive, you can use either the main Marvel solution or Flinto.
Read the original article on TechCrunch.
A lot of products fail. And not just because of funding challenges or stiff competition.
Over and over, someone will have an idea for a product, spend a lot of time and money building out their vision and doing a big launch only to discover after a few weeks or months that no one actual buys or uses their product.
Essentially, they fail because the product is built based on the creator’s vision instead of solving for customer needs first.
Instead, it’s absolutely possible to be more aware during product development, arrive at a product design that people will actually want to use, and to save tens of thousands of dollars in the process.
I’ve studied and employed the Stanford Design Thinking approach to product design, and in my experience it cuts out the extraneous resource-wasting parts, and gets straight to the core of defining a product that will delight customers.
The Stanford approach consists of a cycle of five stages:
1. Empathize – interview with two people from your team, observe person in their normal routine or context, making note of what they say and do.
2. Define – in a group, unpack observations from interviews, interpret what they were thinking and feeling to determine main emotional drivers, and write/select a problem statement.
3. Ideate – in a group, brainstorm ideas for solutions, following a specific brainstorming and focusing process.
4. Prototype – in a group or individually create a low resolution prototype to use in the interview as a conversation piece.
5. Test – interview (can be combined with #1), observing the person’s reaction to the prototype by what they say and do.
Stanford Design Thinking approach
To me, the biggest difference between this approach and others is observation at a very personal level, which is the “Empathy” stage. Many of the stages in this method are used in other design methods, but in this case they are combined and balanced in just the right way. This cyclic process also shares a lot with agile product development, mainly short iterations with feedback in each iteration, but the purpose and outcome here is not necessarily to end up with a functional prototype. The desired outcome is the description of a product that answers to the emotions of a small sampling of individuals who you have interviewed – maybe 3 to 8 people per cycle. Therefore, observing an individual in their regular day-to-day context to determine their emotional drivers is where this all begins. From my perspective, this is the biggest component lacking from the majority of product design today, and explains why there are so many products and features of products that just make you ask “what were they thinking?”
Keep in mind when studying this approach that we’re not talking about spending weeks building a prototype, then going out into the world and asking people “do you like this?” and “would you buy it?” This will cloud your customer observation, yield untrue answers, and mislead your product design. This applies especially during early phases of designing a new product, or designing a new feature of an existing product. Instead, you will be creating extremely “low resolution” or low-res prototypes. For a web site, this might mean a sharpie drawing on a piece of 8.5×11 paper. For a physical product, this might mean cardboard cutouts assembled with tape and rubber bands. It’s actually intentional to not have a polished mock-up or prototype initially, partly because it will get you more honest feedback when you place it in front of someone – they’re not afraid to be blunt. Instead if you put a highly polished prototype in front of someone, they will likely be thinking “well, it looks like they put a lot of time and money into this, so they must know what they’re doing, and I don’t want to hurt their feelings either.”
The other key thing you’ll have to accept is that your product is going to have to evolve during this design process – possibly pretty radically. You won’t – and shouldn’t – end up with what you originally envisioned. Every iteration you run through, you should have at least a slightly different product definition. If you’ve been through several iterations and there’s been no change, you should question whether it’s time to move on to creating a more functional prototype because you’ve done such a good job of product design up to this point and you feel the definition has stabilized, or whether you should go back and review the guidelines of the Stanford approach to see what’s causing stagnation. Either way, I’d expect to go through at least 5 to 10 (or better yet – 15 to 20) iterations before starting to feel comfortable enough to invest dollars in creating a functional prototype.
The great thing is there’s a ton of material freely available online on the d.school web site that guides you through this in detail. I’d specifically recommend checking out the downloadable PDF called “The Bootcamp Bootleg” here. There are also videos and resources to run your own course for others on your team. Of course, you don’t have to follow their guidelines exactly – you should adapt to your organization – but it’s worth following the five steps, and learning their approach for each step to choose which pieces work well for you.
It’s extremely exciting to realize that with each iteration, your design is actually becoming a more and more useful product, and that you’re saving a large amount of time and money by waiting to implement until you have really vetted the design. I’m always hopeful that more and more companies will follow this approach. It’s the natural evolution of things.
Vinasource 