When it can help, what tools we use and how to enable better design
Over the past 18 months I’ve been part of a team focused on building and establishing prototyping within the process and toolset of Digital Product Design agency W12 Studios. Over that time the discipline has grown and matured from the fringes of engineering into the bleeding edge of a new way of working, that emphasises test and data driven design, playing out design decisions on real devices and attempting to bridge the gap between designers and developers.
Whenever I’ve been asked to speak about my experiences with prototyping, motion design and interactions, questions that often come up generally revolve around what tools I use, where I apply them and how does it fit into the design process. What I hope this article can help teach you is not necessarily the detail of ‘use X when Y’, but rather a mindset and approach for prototyping that works regardless of the platform, project or method.
Our experiences point towards an approach that places prototyping as an integral part of our process: it isn’t a single deliverable near the end of a project and it isn’t a golden bullet that will fix poor decisions, but it can potentially help with creating designs that are built for success beyond the end of a project or drop.
Exploring new possibilities
One of the first areas where prototyping can benefit a project is in the initial brainstorming and concept phase: you know what your key design challenges are, but not necessarily what the design solutions are. Post-it notes become attached to every available surface, and some of the sketches look like they might be the basis of an interesting interaction or a novel user flow.
Prototyping at this stage becomes a sketch-pad for trying to make interactions that can become the basis of the app: The tinder like/pass mechanic, Mailbox’ swipe to archive, Apple TV’s poster cards, these are all interactions that could reasonably live aside from any architecture or taxonomy decisions with regards to how they function and how engaging they are to use. As much an important moment for kicking off a project, it can also be used to highlight key moments in a pitch or thought piece.
This stage is also an ideal time to test out these interactions with people who aren’t intimately involved & beholden to the project. The ideas that seem simplest and most elegant to you may elicit confusion if approached cold: this is the best time to realise and work with it, rather than once its been kicked down the road for a few weeks and being cranked out for user testing.
These explorations and interactive sketches become the core DNA of the design work that follows, giving a strong reference for ‘have we made it too complex’ or ‘does this fit with our vision for where we want to go’ when validating later design decisions.
Once the product model (how everything fits together structurally) of the app has been decided, the meat of the production work begins: building out key screens, putting the rules and key elements defined earlier into pages and defining how the app will look and function.
In recent months there have been a raft of tools that can help make this process better connected to the reality of a built product: Craft by InVision is the most recent release that lets you use actual data to help feed a design using a really quite wonderfully simple interface. That said, there are still many use cases that a design has to account for that UI design tools are not that great for.
Defining responsive design rules & accounting for the extents of any given dynamic content — long and short, popular or not, english or japanese, left-to-right or right-to-left — is not the strong suit of Sketch, or Photoshop, or most other page/artboard based design tools, and once a basic page mockup has been built it’s easy to quickly experiment in CSS with these rules. The ability to quickly build out a set of sizes for a responsive grid, or a type hierarchy, and being able to deliver it directly to a client in a way that’s clear to developers and engineers can save a thousand meetings.
On the other side of this coin, there are the higher level questions that prototyping can help solve: Does this user flow make sense? Do people know where to click? This is the area that most discussion around Prototyping centres right now: building interface click-throughs and building up the fidelity from there. Marvel & InVision are leaders in this area, but it’s just as easy to build in Keynote or any of the myriad of recently released tools to achieve the same task.
The end-point all this work leads towards is testing: whether it’s you trying it out, your client deciding whether they like what you’ve done or putting it in users’ hands in guerrilla testing or in a proper lab. If you can build a prototype that lets you answer a clear set of questions that can help the design, it probably fits here: Will people understand this icon means share? Do people get how to navigate back from this info page to the main feed? Will this work in arabic? What happens when this perfectly designed movie card has to account for a long title like The Curious Case of Benjamin Button?
Presenting a vision
Design travels further than the people you’ve worked with, and lasts longer than the last 4/6/46 weeks of your project. The product owners and marketers you’ve been working with may be on board with the development and process that’s taken you to where you are, but when it comes to that design being taken to other areas of the business — sales, engineering, c-suite — it can be difficult to get the message across in slide decks and animation. A picture can tell 1000 words, but that often isn’t enough to convince someone of where you’re pointed or what the worth of those decisions are.
Building high fidelity prototypes is a very fast way to bypass a lot of those obstacles and bridge the gap between your design vision and people trying to understand the work further down the road. Whether it’s a fully realised set of screens, a canned hero journey or even a limited version of the whole app experience, building a subset of the final product can go a very long way to explaining how your design functions and what’s compelling about it.
The devil is in the details for these prototypes: Subtle animations, using actual remote hardware with a device such as Flirc, using a set of appropriate, beautiful content and other finer points are what sell the experience of a complete product and vision. Not a place for spelling mistakes. In our case, quickly building these kinds of prototypes depends on using a high performance reusable framework: We’re currently settled on React and React Native, but in the past we’ve build static HTML/JS apps, mobile web apps and iOS native.
These prototypes aren’t just useful from our perspective as a studio: Our clients have time and again came back with the feedback that the prototypes of the designs we’ve built have helped with getting buy-in from investors, technology and device manufacturers and internal stakeholders.
Whether being able to present the core interaction of an Apple TV app, the delight of working seamlessly across devices or the strength of a channel model for smart TV, some of our most successful pitches and projects as a studio have had this kind of prototype at its core.
Building a system
The products that clients eventually build are sometimes very different beasts from what was originally designed. Whether it’s functionality that is technically infeasible, pages and interactions that weren’t explored fully or simply a difference of opinion internally, it’s very difficult to keep a continuity in the vision originally established, even if working closely with an internal engineering team to get it working to plan. The key to design successfully translating to final build is flexibility, and one of the best ways to achieve that flexibility is by defining a design system.
Breaking down a design into key components, style guide and interaction/motion studies is not only useful for delivery to the client, but it’s useful for you to test your own designs against that system: A set of three screens may look great next to each other but when they use a family of 20 type sizes and 50 very very similar shades of grey it can get confusing, nigh indecipherable to understand what the original intent was for a design.
Designing with the system you’re building in mind is a great example of designing with context: The sensibilities of the device, platform or even development framework being used are essential to the final result of the product, and to design without at least a basic understanding of what is or isn’t possible is asking for failure further down the road.
We’ve found the best way to package up these style guides is using an interactive framework such as Wordpress, Grav or any other straightforward blogging/website app. With some modifications, these platforms allow us to quickly pull together wireframes, sketches, flat visuals, motion studies, interactive prototypes and screen captures into one place.
The advantage to the client is clear: A single reference point for the design work that’s been done that can be made available internally across an organisation. In some cases it’s even been developed and bought into to the point of being able to present weekly updates directly from the guide rather than wasting time producing weekly slide decks. Engineering teams have taken CSS directly from interactive examples for use in production code. Guidelines can be seen without prior understanding of the principles or intent behind their production, internally or externally, and still have value.
Put it all together
This article is hopefully the first in part of a wider collection around the world of prototyping, interaction design and animation that we want to create. We hope it’s helped to communicate the value of prototyping that we’ve seen and helped develop over the last couple years within our studio’s department. If you have any suggestions or questions, please say hi! or use the usual social channels.