« All Episodes

3: Prototypes

Published 1/6/2015

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.

Transcript (Generated by OpenAI Whisper)
Hello and welcome to Develop a Tea Episode 3. My name is Jonathan Cutrell, I'm your host and 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 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. Prototyping is incredibly important because it provides a resolution of design that static mockups 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 mockup like you might would see like a Photoshop PSD file if you're a web developer and the actual production application. Whether 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. What it functions as is a way of showing how something actually responds to a particular interaction. Usually it 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 would 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 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. 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 does something, how does that thing respond? Because really we have this long history of the static applications that kind of work in the same way that a print piece might would 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 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 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. A lot of prototypes act as subparts of applications rather than trying to build the entire application as a prototype. You'll see a particular interaction that's prototyped that will sit in an application at a particular point. 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. They need to know the context of that particular interaction, 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 hierarchy. 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 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 MacBook or something like that. 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. 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. 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 for me, you can reach me on Twitter at app Developer Teaor email at Developer Tea at gmail.com. Until next time, enjoy your tea.