We've written a lot lately about the process of prototyping and fast iteration on ideas. Jenna introduced prototyping with motion tools and Josh described how they used short, two-day cycles to experiment with and test new features for Dungeon Highway. Unsurprisingly there's still more to say on the topic.
We Prototype All the Time
We believe you should create quickly and ship often for success. For most of our projects we strive to deliver a working part of an MVP function as early as possible. Within a few weeks or even days, our partners can begin to interact with the experience we are helping them create. To use a terrible automotive analogy, we start to deliver key components, such as the chassis, axle, and wheels for a car as early as possible.
We try to have something that is functional – even if functionality is dependent a temporary crutch, like fake user data. A major benefit to 'shipping early and often' is that it gives us the opportunity to experiment and test ideas within the context of 'the real thing' as the project progresses. By doing this we consider options we may have previously written off or ignored. It also enables us to pivot earlier in the project if the direction isn't right. Small rounds of experiments and prototyping with our core product are part of our product development process, although these efforts may get labeled as other things (in the world of TDD, some of this is called a 'spike').
As fantastic as it is to deliver early and use the production work as a base for experimentation, seeing things in a raw format for can also be pretty distracting. Going back to cars: It's hard to imagine what the gear shift experience should feel like when all you can see is the bare metal frame.
But the details of that interaction, from the literal tactile nature of the stick and handle, to the ease of its movement, and the pressure required for the clutch pedal, are necessary design decisions for experience of driving the car. Independently prototyping a feature, motion, or element lets us flesh out these details in a cleaner context and helps us (and our partners) make decisions regarding the product experience.
Jenna discussed prototyping with code briefly towards the end of her post, but I want to go into a bit more detail about the benefits of code-based prototyping. For web projects, I strongly believe prototyping directly in the browser is usually the best choice. However, because my web dev skills are not the strongest here at Substantial, I asked Ryan M. and Marcy to contribute their opinions on this as well.
When Prototyping: To Code or Not to Code?
While we all advocate for prototyping, we discussed whether it makes sense to start with code at all times.
Design can influence our opinions on functionality so strongly at even a more superficial level that there's a thing called the aesthetic-usability effect. Because design is experienced by users emotionally, clickable prototypes are not the best method to communicate the intent of the experience design. If you are looking for feedback on the whole experience, you'll need an alpha version of an MVP or (polished) functional prototype, or a highly imaginative group of test users.
That said, both Ryan and Marcy pointed out that clickable prototypes do have value to offer.
Clickable prototypes can offer a 'good-enough' walk through the flow of a feature, and allow for testing that static comps, wireframes or sketches do not. Clickable prototypes can also begin to demonstrate intent before investing the time to develop further. However, Marcy pointed out that unless everyone can agree to a very basic flow, clickable prototypes can quickly grow to resemble actual projects.
Designing in the Browser = Creating a Prototype?
A year or two ago, "designing in the browser" became a mini buzz phrase in the web design world. There are a lot of benefits to trying out elements or designs immediately in the browser without worrying about production-quality code.
Ryan said that to him "using the browser to design is synonymous to using Photoshop or pen and paper – it can be just another tool that happens to have the advantage of being the medium you're designing for in the end..." Even without the intent of creating a prototype, by starting in the browser you get a better idea of which parts of the design are succeeding and failing. And ultimately, the goals are the same: demonstration of an idea or concept.
If you're designing for a web-based project, the benefits are similar as well:
- Your exploration will be based in its final destination (the browser), making this the closest simulation to the end experience you can get
- You can see immediately whether something does or doesn't work without any of the ‘When it's on the web...' speculation
- Designing in the browser is still the most efficient way to design responsively. Sketch as needed, mock up specific UI elements as needed... but try and avoid the 3 screen standard of “mobile,” “tablet,” and “desktop” comps. Those benchmarks aren't reliable anymore.
- You can pivot on an interaction idea more easily, and see it in full context of the experience
- You'll actual be able to meld form and function sooner, and a great design keeps both in mind.
- Code-based prototypes can handle both single-concept (singular button interaction) and multi-concept (more complex) scenarios. You're only restricted by your own capabilities.
But Wait! There's More!
Just kidding, for now this is it. Even for designers with limited front-end skill, it's not hard to get started with demonstrating simple concepts in the browser thanks to tools like Codepen and JSFiddle. Get to it.
Image from Flickr user Jared.