Prototyping Tools for Product Designers
Originally posted at Neo.
There is a fantastic array of online prototyping tools available today. Tools like Marvel, Invision, Pop and Atomic let us work faster and kill communication overhead. In this post, I’d like to share my favorites and give some guidance on which tools are best for which stage of product design.
Matching the right tool to your product’s current phase is crucial to efficiently move through product design. Most importantly, your prototypes should be laser focused on the design risks at hand, and not distract you with UI minutiae.
De-risking Design
Each product starts out with a heap of design risks. Big risks need to be handled first; invest as little time as possible in your initial prototypes. Otherwise you are spending too much time finessing something you might throw away. The trick is to discover ASAP whether or not you need to scrap your design approach.
Use Prototypes of the appropriate fidelity and complexity to de-risk design. Product design should look like this:
As you move further in the design process, you can increase the complexity and fidelity of your prototyping, because there is less risk in doing so.
Prototyping for Lean
Lean products are quick to market and incorporate user feedback immediately. Business risk is high, timelines are short and teams are small.
1) Value proposition, messaging & vibe
It’s of course a huge risk if no one finds your product valuable in the first place. Make sure you are hitting the mark with your value prop, messaging and overall vibe before you drill into the details of UX. Often times we begin designing out product from the middle out, and neglect this first point of customer contact.
The appropriate fidelity here is high — if it’s not believable, it wont pass the sniff test — but there should be zero complexity. One screen will do.
Get your graphic design in place and put it in front of prospects to see how they’ll react. You may be guerrilla testing in the mall with a prototype on a mobile device, employing usertesting.com to reach further flung users, or setting up a personal session somewhere. There are many ways to do this, once you know where your prospective customers are, and what platforms they’ll be using to experience your product.
Both Invision and Marvel let you link up screens for desktop, mobile and tablet. Both have mobile transitions. And most importantly, both are drop dead easy and fast to use. This is critical. If your prototyping tool is simple, then you can have a simple, hi fidelity prototype that you can guerrilla test in front of real users in minutes not hours. And then roll your learnings directly into your prototype. This kind of fast iteration on ‘feel’ is invaluable at this stage.
2) UX Flow for Primary Use Case
Identify your primary use case and design for that. Again, it’s important to stay out of the weeds. Your focus is to iterate and nail the fundamental use case. This is very low-fi work. I prefer to work it out with pencil and paper.
Pop prototype is the best for fast iterations of user flows. Take pictures of your sketches and wire them up right on your phone. Although it’s just mobile and tablet, if you are taking a mobile first approach, start with Pop. Its minimal nature keeps you focused on the big issues and not on the fringes of the experience.
3) Additional flows and details
Once you have your value prop and vibe set, and primary use cases nailed, you can use a combination of Pop and Marvel to flesh out the rest of your product. Use Marvel to communicate how the design language you began with applies to the rest of the experience. Use limited flows, not every last use case.
Continue with Pop to prove out the rest of the flows. Pop can contain the breadth of the product experience, while Marvel shows special sections that are helpful for understanding how the design is applied.
These prototypes are the team’s reference point for building out the product. They are also the history. I throw away my prototypes, but usually capture them as movies or animated gifs, so they are preserved as useful design artifacts.
Prototyping for Agile
On small, lean teams, there are a few people building one thing, and getting real user feedback along the way.
Agile projects tend to be more involved with larger teams. Agile teams should be continuously deploying and therefore always getting customer feedback. That said, it’s a good idea to get that feedback at the design stage when possible.
There’s higher communication overhead between the designers, product owners and engineers on an Agile project team. In this setting, prototyping is equally valuable for getting design ideas across and for design documentation. Business risk may still be high, but timelines are longer and teams are larger.
1) Animated gifs are an Agile designer’s best friend.
Transparency is also your friend. I think it’s best to design out loud where all can see. Here’s why…
Formal design reviews with stakeholders rarely yield great design. The chances of great design are better if you have design out in the open in an informal way. And gather continuous input along the way.
Also, getting feasibility input from developers along the way can be challenging. Dedicated meetings only cover some of the bases and they have a huge calendar footprint.
Instead post animated gifs of interactions, flows, behaviors to where the entire team will see them (Slack or Hipchat, Basecamp, your project wiki, etc). You can use Licecap to capture your screen and save an animated gif for sharing. So just record a walk through of your prototype with Licecap. Share it and keep moving.
2) Interaction Model and Information Architecture
I like to get the basic building blocks sorted out — the information architecture and system objects — on paper or in Balsamiq. Then bring screenshots or photos into Invision to test out some important use cases. At this stage of Agile product design, I prefer Invision. I find it a little faster to get around in than Marvel, and these products are larger.
Feedback and iterations take a little longer. But working low-fi on interaction basics keeps it as fast as possible. It’s important to get your prototypes in front of real users so the team does not go off into the clouds. Keep it grounded in reality.
User testing with obviously rough prototypes keeps the cognitive load low for your test subjects. In my observations, if something looks designed, but wrong, that is more distracting than something that is explicitly undesigned. You can have placeholder copy in a wireframe. But if it’s in a design, people will get stuck.
3) Pulling in the focus and extending patterns
Now IA (Information Architecture) has solidified and primary patterns are in place. You’re de-risking your product design, and now you’re in a place to get deeper and more complex with your prototyping.
At this point, visual design can be applied to UX patterns. For sharing with team and test subjects, Marvel is my favorite right now. Marvel gives you an array of transitions for each action. Yet it’s still very simple tool. Invision is too simple for this work.
Marvel transitions pannel:
4) The magical moments
God and the devil is in the details. That extra bit of motion or elasticity can give your UX that extra magic. Yet 2 point stories can turn into 8 point stories when engineers don’t understand the nuances of the UI behavior.
My tool of choice for rendering sweet UX moments is Atomic. Atomic works for desktop, mobile and tablet. You can apply and dial in animations of screens, UI components, do vector transitions and more. It’s easy to lose yourself playing in Atomic, so watch out. That’s why I don’t recommend it for full product prototyping.
Like before, as you create these sweet little moments in Atomic, screen capture them with Licecap and post animated gifs where the entire team will see them (Slack or Hipchat, etc). By the time your team is estimating the next sprint, these behaviors will be well understood, and the engineers were involved in the design.
My goal with this post was to help teams more effectively use prototyping tools to keep iterations focused and rapid, incorporating feedback quickly. I’ve found sharing UX at all its stages — with the right level of fidelity and complexity — leads to greater shared understanding in larger teams, and helps demystify the process.
If you have any feedback or tips in this area, I’d love to hear it. Please share them with me at @andisf.
