Stop Presenting and Start Prototyping! An Interview with Joe Stewart
Interactive design is a dynamic (no pun intended) and ever-changing profession. It has been said that the field of interactive design is the only area of the creative arts in which you should expect to re-learn your entire profession every two years. Those who have been designing websites and applications for any length of time know there is a lot of truth in that statement. Yet, change is required to do what we do. As new technology and opportunities develop around us, interactive designers are forced to precariously perch atop sets of ever changing standards, widening development environments, and maneuvering toolsets in order to stay in time with the changing landscape.
While at first this may seem frustrating (and sometimes it is) and futile (many, many times it can be), what interactive designers understand is that this process is a necessary evil–one that inches us closer year-by-year to understanding a, what is for the lack of a better term, still nascent connected space.
Take for instance the hot bed discussion of comps vs. prototypes. For years, firms have traditionally moved through their design process by leaning heavily on graphics applications to explore final design options for UI design. These comped, pixel perfect designs generally do an alright job of representing a design solution, giving the client a general understanding of how the final site or app will look. But there are several weaknesses inherent to this type of design. Generally, comps only represent one particular form factor, leaving mobile representation out of the picture unless additional comps are constructed; the comping process is super time intensive; and most importantly comps lack interactivity, which generally make them a piss poor representation of what is meant to be an “interactive” space. Yet, this is the process we’ve had in our toolbox for years.
Times, they are a changing.
I love user testing prototypes, and when you know real people are going to be touching your designs at the end of the week, it changes the way you think about what you’re making in a very real way.
Prototyping, or the process of creating an interactive working model of a design, has gained a lot of popularity over the last few years. Prototypes provide a design team the ability to look at how a design will work (structurally and interactively) much earlier in the process than comps do. Because the team is working with rough forms of interactivity early on, they are better equipped to problem solve throughout the life of the project, which hopefully, leads to a better overall solution. The transition, though, from comping to prototyping represents a need for change-both technologically and creatively, and that leads to long debates on the merits of both processes. There are those that swear by the traditional methods of comping, while others are quickly sold on the immediate nature of prototyping.
Joe Stewart is a founder and partner at Work&Co, an interactive design firm with offices in New York, Portland, and Rio de Janeiro. Work&Co utilizes prototypes throughout all of their projects, and are firm believers in what prototyping means to the end result. We talked with Joe about how he uses prototyping as part of his daily design process and what he believes are the benefits of working with interactive models.
Prototypes can be a great way to help teams explore, and interact with, different design solutions. What do you find are the advantages of the prototyping process?
Well, it’s a completely different process than what most designers are used to, which is making presentations. For years, what most designers have done is make their comps and then lay them out in a pretty presentation… a PDF or a Keynote or Powerpoint. But, this creates a couple of problems.
- It makes you focus on the presentation itself as the final deliverable, as opposed to the designs, which is a giant waste of time.
- It makes you lean the designs toward what looks good in a presentation versus what actually works the best… which are usually not the same thing.
- The client ends up with a stack of paper on their desk… as opposed to something they can actually touch and use and understand.
So, when I design now, I don’t make a presentation. I start making a rough prototype and fill in the screens as I go. I make 100 minor tweaks throughout the day in the prototype itself – then – I can share that prototype with the developers and strategists I am working with and also with the client. The prototypes I’m making aren’t particularly complicated. Usually I’m just stringing together clickable images in a program like Quartz Composer, but being able to see the designs at 100% scale, on the device it will actually be used on, and forcing myself to figure out the UX & graphic design decisions in the real context forces me to be much more pragmatic and honest. Gimmicks and fancy tricks usually don’t hold water once you prototype them. I can’t really fake a bad design in a prototype… it just won’t work. But, you can fake a bad design in a fancy presentation and convince people it’s a good design. I’m sure you’ve seen this before. A lot of “story telling” goes into making presentations… that all goes away when you just hand someone a prototype. It either works or it doesn’t.
Also, I can then go user test the prototypes. If you aren’t sure about a decision, or there is debate between different parties, just user test it to get your answer. This solves problems quickly and with finality. I love user testing, and when you know real people are going to be touching your designs at the end of the week, it changes the way you think about what you’re making in a very real way. Again, it forces you to be honest and make decisions based on what is going to be best for the user.
The short answer to this question is making prototypes saves time, and also makes the designs actually work much better. Plus it’s fun to make stuff you can touch, and fun is important.
You’ve employed prototyping across several large projects at Work & Co. How has adopting this strengthened the company’s process in terms of the quality of work and how your teams work together?
I think that when you are building prototypes, there is a much larger overlap between all the different teams that are working on a project, which is critical to launching good work. If your job is to think of an idea, do the ux and graphic design, then build a simple working model of your idea – you really have to think quite a bit more about what you’re making versus just being in charge of any one of those facets. The days of just being in charge of “look and feel” are long over. So, in terms of what it has done to our process at Work & Co, there are a few main changes we have established:
First, since day one we’ve only had one design group, as opposed to a user experience group and a visual design group, and a production group, and a motion group, etc., etc. Every designer is expected to be good at UX, visual design, and prototyping. Now, every person has strengths and weaknesses, but, everyone is expected to constantly improve in all 3 areas. Right now I think I’m a pretty good visual designer, a decent UX person, and a relatively weak prototyper. So, I am working on improving my faults, as are all the designers at Work & Co. The idea here is that everyone is responsible for the product as a whole. If something is wrong, there is nobody to blame.
The earlier you start prototyping, the earlier you get to see how fucked up your designs are and start fixing them.
Second, there is this amazing thing that happens when all the designers are prototyping: the relationship between the designers and the developers is much better. If we’re already building very crude models, we’re spotting design flaws early, and being forced to think about the design a bit from the point of view of a developer. So, there is a much tighter overlap between the groups. Traditionally, there is sort of this hand off between design and development of a batch of PSD’s. This leads to disaster. When that transition is gradual, and that overlap from prototype to development code, the results are much, much better.
We’re set up to ship products, not presentations, so the communication overlap between design and development groups at Work & Co is the most I have ever seen. We start at the same time, work on the same problems, and review the same work. I think the development team finds the designer-built prototypes can be helpful in understanding the nuances of the design’s intentions. It also forces the designer to create something that is somewhat feasible to develop. Designing something that can never be built is a huge waste of everyone’s time, and this process helps curb that.
There are many different approaches to prototyping–from simple paper prototypes to full interactive explorations of a design problem. Is there a “right” amount of prototyping that should be done?
I think there are three “right” amounts depending on what your goal is.
The first kind of prototype is one that simply expresses an idea, like the way a page scrolls, or how a menu works. For this, the right amount is whatever is the least amount that gets the idea across. Sometimes even doing this sort of thing in After Effects can be the simplest, or Keynote can do really simple interactions as a way to get an idea out.
The second is a prototype where you are trying to understand the overall design you are working on, and this is where we spend the most of our time. This is usually much more robust and interactive, as opposed to the previous example. So, the right amount of prototyping here is enough for you to be able to understand how your product works in a significant way. Enough for you to see errors in your work, and see opportunities for streamlining things, and spark new ideas from playing with it. This needs to be designed at the right scale, pixel density, and for the final device to be effective. So, if you’re making an app for a TV, you need to see it and play with it on a TV. There is a huge parallax between a computer screen and TV screen in terms of what is legible, what seems actionable, etc., and you have to build a prototype to understand your designs here. Same is true for anything, be it a website, mobile app, watch app, whatever.
Third is a prototype made for a user test. Ideally this is made in native code, which, for me anyway, means working with developers to build out something a bit more robust that allows users to make lots of potential choices so you can see how something is really behaving in the wild. If time is pressing, we can make user tests in something like Quartz Composer, but it’s not really designed for this kind of application. The idea for a user test prototype is to get as close to real interactions as possible. User tests are the highest form of truth designers have before a product is launched, they are god. If the user test says the answer is “A”, then guess what… the answer is “A”. We like to do lots and lots of user tests, so as you can imagine, we end up building lots of pretty robust prototypes that get bigger and better over the course of a project. If you were to put the Keynote prototype from my first example in front of a group of users for a test, the data you would get would be really limited. You’re basically doing a focus group – which I, fundamentally, think are largely useless.
So, the “right” amount of prototyping really depends on what your goals are. But, all are valuable for different circumstances.
It’s generally believed that the earlier teams start prototyping the better. What are the some of the benefits of prototyping early on in a project?
Well, the earlier you start prototyping, the earlier you get to see how fucked up your designs are and start fixing them. When you’re building working models from the get-go, the iteration cycle is much much higher. Its a crime to have the first time you’ve used a product be when it’s actually built and ready to ship. You’re going to see 1,000 things wrong with it. The goal of early prototyping is to fix those 1,000 things along the way, and also get new ideas for how to make your design better as you get to play with it and watch other people use it too. So, by the time it’s ready to go live, you’re launching version 10, not version 1.
What are some roadblocks that teams may encounter with a prototyping approach?
Well, it’s really hard to do. So, I think the biggest roadblock is it’s hard to scale. Not that many people can do the conceptual ux & design and then also build a prototype that works. It’s a lot of different skills and ways of thinking about solving a problem. There just aren’t that many people who (now, in 2015) do this. So, if you want to build a department of 500 people who can do this, good luck. The good news is, the younger generation of designers are already into this way of working, so the shortage of designers who work this way will get smaller over time.
At Work & Co, we actually like this. We like having a smaller agency (only about 85 people as I write this) as we tend to find the output of the work is higher and the people are happier at smaller agencies.
Do you have recommendations on tools and processes to make it faster and easier to build prototypes?
I think you just have to jump into the deep end of the pool. There is no easy way to do it, just go for it. There really isn’t a perfect prototyping tool for designers – most of them are either too limited, or too confusing, but – just trying to learn each of them a little bit is the general approach and seeing what sticks, over time. Most of my co-workers with better development skills than I have think I should just learn something like framer.js, but this is pretty tough for a designer, so right now I’m bouncing between Quartz and Form on the desktop side, and Marvel, Proto.io, Invision, and a couple others on the web side. As I said, I also use After Effects or Keynote from time to time if I’m trying to look at something quick and cheap. None of them are perfect, but I hope in a few years there will be a clear winner, or a more perfect tool for this kind of work.
One thing we’ve often wondered and just don’t see addressed when reading articles on the topic of studio process is this: Does prototyping make sense in every situation? Is it only feasible to prototype medium or large projects or is there a workflow for very small budgets ($3-4k and under)?
I think if you replace making presentations with making prototypes you actually save money. Tons of time is wasted making decks…take that time and make a prototype instead. You will catch errors earlier, develop a stronger product, increase development overlap, and be able to see & improve things you wouldn’t otherwise see. The idea that a project can be too small to prototype seems broken to me.
For teams still working through a more traditional comping process, how do you suggest they begin to integrate prototyping into their workflow?
The easiest way to get started is by learning one of the web based prototyping tools, and start putting your designs in them as you work. They should take you about 5 minutes to learn. They’re super simple, and a great way to start.
Building the prototype should be part of the daily design process, not something that is done after your designs are “final.”
So, you make a screen, throw it into the prototyping tool, link it to the next screen, play with it, make changes, repeat forever. Make 100 little changes to your prototype every day. It’s fun. As you get comfortable with this, you can try more robust tools, but just start doing it. It might seem slow at first, but in the long run, especially as you get faster, it saves light years of time.
Instead of sharing work with your team through a deck, have them play with the prototype. The feedback will be smarter and better informed. You’ll get more relevant ideas, and you’ll get to the right answer quicker.
Clients will be happy to get a working prototype as opposed to another Powerpoint, and chances are your work will actually be better received because your ideas will be clearer.
So, stop making presentations and start making prototypes. Your work will be better, your client will be happier, it will be easier to work with the developers, you will save time, and you will have fun.
– – –
Joe Stewart will share insights on “Prototypes, Not Presentations” at WebVisions Chicago.