Prototyping is a process that bridges the gap between production and static design. In this episode, I talk a bit about what that means, and about what is required for all good prototypes. If you aren't prototyping now, you need to catch up. If you enjoyed this episode, please consider buying me some tea: https://www.developertea.com/buy-me-tea Edit: I accidentally called the Facebook prototyping tool, Origami, "Paper". Of course, this was a mistake. Sorry about that folks. If you enjoyed this episode, please consider buying me some tea: http://www.developertea.com/buy-me-tea
Prototyping is a process that bridges the gap between production and static design. In this episode, I talk a bit about what that means, and about what is required for all good prototypes. If you aren't prototyping now, you need to catch up.
Edit: I accidentally called the Facebook prototyping tool, Origami, "Paper". Of course, this was a mistake. Sorry about that folks.
Hello and welcome to Developer Tea, Episode 3. My name is Jonathan Cottrell. I'm your host. Today we're talking about prototypes. Prototyping is a big deal. In fact, if you're a web designer and you kind of follow the news of the web design community, then you've probably seen some tools popping up in the past year around the idea of prototyping. Prototyping is not a new idea, but it's coming more and more into the light of web development because the browser has changed in the past 10 years massively. We're now dealing with a multi-device world where you can touch and move things around and where you can look at the same website on screens that are literally, 10 times different from each other as far as pixel dimensions go. So prototyping is incredibly important because it provides a resolution of design that static mock-ups don't provide. If you don't know what prototyping is, the basic way to describe it is it sits kind of in between a static mock-up, like you might see like a Photoshop PSD file if you're a web developer, and the actual production. So there may be some front-end development in the prototype, or it may be something that you build in a third-party tool that has literally nothing to do with web technology just to communicate that step in between. So what it functions as is a way of showing how something actually responds to a particular interaction. It usually focuses on a few key interactions, but doesn't actually usually manipulate real data. It doesn't have back-end services. It's not on a production server. It's probably not created with a back-end language like you might find like PHP or Ruby. It's probably strictly HTML and JavaScript or something like that if it's in the web world. You can also prototype for applications. You can prototype, you know, like if you're building an iPhone app, for instance, you can do some prototyping inside of Xcode, or you can do it in... in a tool like Paper, which Facebook actually released this past year. The value of prototyping is that it provides a way of communicating a particular interaction. So an interaction is like designed behavior and a designed conversation, if you might want to call it that. The application or the digital artifact that your user is interacting with, when the user... when the user does something, how does that thing respond? Because really we have this long history of these static applications that kind of work in the same way that a print piece might work, where you're just reading information or you're looking at pictures or something like that. Now, because the web has continued to move more and more into... into applications and because there's so much movement towards a larger development community towards applications, prototyping is picking up speed because we have a lot of people who are needing to communicate these interactions and they can't do it simply by using something like Sketch or Photoshop or Illustrator. So every good prototype has a few things in common. The first thing is a high resolution for the interaction itself. What this means is if the interaction... responds with an animation, the thing that should be really well polished in a prototype is the animation itself. The code surrounding the animation doesn't really matter. It doesn't need to be optimized. It doesn't need to actually go out and fetch data from a server or something like that. It should be the actual animation, the visual feeling of that particular interaction. That's what the prototype is. That's what the application is for. The next important thing for every good prototype to include is a list of contextual notes that explain the interaction and where it sits in the application. Now, a lot of prototypes act as subparts of applications rather than trying to build the entire application as a prototype. So you'll see a particular interaction that's prototyped that will sit in an application at a particular point. And it's important for a developer to know where that interaction that is being shown in the prototype, know where that will actually finally be in the real application. So they need to know the context of that particular interaction, kind of what the inputs are and what the outputs are, and what its functional purpose is, as well as literally where it is in the application as far as the information, and how it's going to be used in the application. So if it's on the introduction page or if it's on an interior page or something like that, or an interior view if you're working on an iPhone app, put that in some interaction notes that are accompanying whatever that prototype is. The next thing that every good prototype needs to have is it needs to be tested and targeted towards whatever the application will be running. And that's going to be the run-on. In other words, if you're developing like an iPhone app or an iPad app, you should be creating your prototype to run on the iPhone or the iPad, not on your laptop or on a desktop computer. A lot of people forget this, especially for the web. A lot of people will build their prototype at a larger size because they have a cinema display sitting on their desk, and they forget that most people are accessing the web on a 15-inch screen. They forget that most people are accessing the web on a 15-inch MacBook or something like that. And so they'll build these large, large prototypes, and then when it comes time to actually create something for the target device, the prototype is so big that you have to basically start from scratch. And the same thing can happen with an iPhone. You create a prototype for an iPhone on your computer, and as it turns out, the thing just doesn't translate properly. It feels wrong on the iPhone. So again, most important, three things for a prototype to have. Those are the high resolution of the specific interaction, the very good contextual notes that accompany that particular prototype, and you absolutely should be pointing your prototypes at the specific devices that your application will run on once it's in production. This has been episode three of Developer Tea. If you have any questions, thoughts, or suggestions, you can reach me on Twitter at at developer tea, or email at developertea at gmail dot com. Until next time, enjoy your tea.