My Sites
Short recommended reading list/things I mentioned
Mozilla talk on prototyping: http://vimeo.com/16527312
Sam Ladner’s discussion on Interaction Design as a profession
http://copernicusconsulting.net/essence-interaction-design-research/
Digital Ground by Malcom McCullough (This book made me want to be an Interaction Designer)
Shaping Things by Bruce Sterling
The Rapid Prototyping of Interaction Design
Quick introduction. I’m Andrew Lovett-Barron, and am currently working as an interaction designer at TAXI. I’m a self taught programmer and actually graduated from U of T last year as a Political Science specialist. I also studied classics and linguistics, so I come from a bit of a varied background.
I got in to interaction design from a serious interest in synthesizers. I’m terrible on the keyboard, but impulsed purchased a synthesizer in an attempt to impress a girl. It didn’t work terribly well, but I became utterly fascinated with it. Less the music than the interface. Sites like CreateDigitalMusic by Peter Kirn then served to introduce me to the breadth of possibilities in this area. I had coded for fun in high school and took it up again, learning Processing and Max/MSP/Jitter to facilitate music learning and my growing interest in live visuals and interaction.
Since then I’ve had a few interactive projections and installations, and performed with a video mixer of my own design a number of times. Myself and two others, Stephen McLeod of the VSVSVS art collective and Alex Snukel at Interaccess media arts gallery founded Handmade Music Toronto, modeled after the NY version. We’ve had three shows, about a half dozen open studio workshops, and about twenty DIY musicians from both Toronto and elsewhere participate. The next is (hopefully) in December or January, so please come out!
So What I want to talk about is Rapid Prototyping and five principals I’ve learned when applying `Rapid prototyping to the practice of Interaction Design.
Rapid prototyping means a couple of things. In this case, it means the quick and dirty creation of an idea and design. The way I like to do it, personally, is to have the basic concept, whip out a VERY fast prototype, get it totally wrong, and then start applying separate design practices in tandem with the prototyping to converge on both the problem and solution.
1. Diverse tools lead to a broader pallette of solutions
-Different tools have different roles in the process of creation. By gaining an understanding of different tools, you can know when to effectively apply what. More importantly, you’ll develop an understanding of how to apply the “less optimal” tool to better effect.
-Programming language I know are : PHP, Max/MSP, Processing and Java, Python, javascript through jquery, and arduino. I can hack together basic electronics and am currently hell bent on expanding that knowledge, have a decent competency when it comes to woodworking and textile centered crafts, and am well versed in a few key imaging, vector, and CAD programs.
-Learning philosophies behind individual languages and tools gives you an idea as to what lets you solve a problem best. Since I started learning Python, in general my code’s gotten a lot cleaner. Since learning Processing, I’ve become a lot more inclined to just “jump in” and try something out. Since I started learning about electronics and circuitry, my ability to work through logic problems has improved a fair bit as I’ve come to visualize them more effectively.
-I use processing and max the most, often for “one off” or prototype projects because I can belt out a prototype in one to four hours, and then iterate from there.
2. Other’s work is meant as a foundation
-Irregardless of what language or method you use for prototyping, there will be a huge wealth of prior knowledge and creation. This can be intimidating, but it’s a huge boon to your own work.
-If you can pull of a concept with minimal coding and just a few libraries, do it.
-Take your approach to citation in academia and expand it into the real world. Postit notes, tape with notes, and foolscap will become your best friends for marking up a physical environment.
-Learn how to write readable, commented code. Use comments in code like you would citations and margin notes.
-Credit and provide URLs in your code to the original works, and add back to the community if you can. This is both for your benefit and others: you’ll learn from others feedback and have backup for both sources and code,and the community will benefit from seeing the novel use of a tool.
- http://ghostview.ca halloween project got a few hundred page views with fairly high retention, and I coded it up in a night or two with just PHP interfaces for google maps and foursquare.
-Write code that you mean to throw away, but that others can read. I’ve found that this balance is important for being able to iterate vs. just do coninual one-offs. Also don’t hardcode numeric variables that aren’t actually constants. Serious.
3. Prototypes have zero longevity by themselves.
-You will not be right at the first iteration, nor the second, possibly closer on the third.
-Always let other people play with your prototype, and get involved. Don’t be surprised if your prototype completely derails a project or causes a drastic change in direction. But continue exploring.
-If you are working in a group, prototype with the idea that you are affecting how people will see their own ideas, and be receptive to exploring multiple optinons.
-NEVER (and I say this with experience) let someone in a managerial role use your prototype as something “production ready” with a client. It will end in tears and disaster, and the managers will not understand why.
4. Prototyping is a process of idea development.
- A prototype ranges from sketches on paper to full code mockups
-Prototyping does NOT mean that you create a working model. What it does mean is that you create something that allows the exploration of a scenario, situation, persona, interaction, or form.
-Interning this summer at Normative Design on the Red Rover project, prototyping as used to explore mechanics and environments. Prototype wasn’t about the technical “product”, but specifically as a tool to understand behavior. The reality was that the “prototype” in question was not a device or program, but an environment for augmenting human way-finding methods and identifying compatible mental models in that space.
-Though I personally think everyone should have a base level knowledge of code, you should _never_ let the idea of using code limit you. Don’t spend days coding up something just for a prototype when you can write the prototype on paper, and then act it out stop-motion style in a movie, or have your partner inside a box miming the actions of a programmed interface.
-The main point is that the prototype must move the process of ideation and design forward, and the form of the prototype matters less than the developmental progress it encourages.
5. Prototyping is for iterating both the problem AND the solution (most important)
-We start out on a design or a project for multiple reasons: passion for a field, desire to solve something, fame and fortune, and I think best of all, the shear pleasure one receives from creating something.
-Identifying the actual problem in creating something comes from a deeper understanding of the situations and scenarios involved. prototypes assist in the exploration of these scenarios in conjunction with other design and research practices, such as focus groups, participant observation, interviews, etc.
-Identifying the solution is an evolution of these stages, and again involves a rapid iteration of ones prototypes.
-A good sounding board for where you are in a prototyping process is the fidelity of your prototypes and a sort of “hierarchy of functionality.” First, the refinement of your prototype will change with time, going from very rough to more refined, even graphically so. The first prototype might be a carboard box on the low-fi end, and a 99% working 3d printed plastic mold with arduino controlled internals on the higher fidelity side.
-You’ll find that aspects of your prototype will become more or less fluid as the prototyping process continues. Some will be finalized early, and then change completely later down the chain. Visualizing it as a multi-root hierarchy is a good way to go about it.
-I started out making a video mixer, thinking that I wanted to make all these cools forms and shapes. Turned out what I wanted was to figure out how to play these things like an instrument. I was interested in creating something that could be have a spark creativity, basically. So right now I don’t really use any of the video code I wrote, but I’ve written a complex control layer for a program called VDMX based on the control model from my earlier prototypes.
-Prototypes are fluid, organic tools and materials for molding a structured form from an amorphous concept. Prototyping is a tool for exploring and developing a problem into something that can be solved.
-Never use prototyping by itself. We prototype to create a form, but the form requires a lattice and foundation derived from other processes. Brainstorming, formal sketching activities, various types of qualitative and quantitative research (amongst others) at the project’s inception, and user testing, card sorting, and similar as the prototype and design matures, all serve to create these support structures which permit the final form to be realized.
-Without these other design and research tools, the prototyping process becomes just a process of tinkering, which though valuable for personal growth, lacks the goal-oriented nature of prototyping as a design practice.
So long story short, go out, make things, tinker your hearts away, learn as much as you can. Just remember that the distinction between prototyping and tinkering is one of purpose and goal, and good prototypes have a strong foundation in good qualitative and design research.