The Benefits of Prototyping.
One of the most important aspects of my job as an IXD is prototyping designs, interactions and new features. I’m lucky enough to work with some of the smartest, talented and forward thinking individuals, who design, build and test features from a user’s perspective and are huge supporters of prototyping. Each piece of my team is involved in just about every step of the design and development process [even our business analyst!] and I wouldn’t have it any other way.
The best part of this team is the way we work together to develop new ideas; how people from different backgrounds with different skills and personalities magically come together to make something truly incredible. When we formed this team in January of this year, we were tasked with building our department’s first HTML5 application [pretty insane considering we have traditionally been a .net shop for years and the only developers with experience in web apps are the ones who dabble in it because of side projects]. We were given a little under two months to discover and settle on which frameworks we wanted to use to overhaul one of our most beloved and oldest software applications. It was one of the most intense experiences of my career and our team gelled together immediately with a startup-like attitude. Together, we designed and built a small piece of the application and flew up to New York City together to present it to the users. This particular prototype was an excellent example of what this team would be capable of, it proved that a web app could do the same thing as a .net app, but most of all it showed the rest of our department how important it is to prototype ideas and set a new working pattern in motion.
Prototypes help you discover knowledge you weren’t looking for.
Our team is mostly based in Atlanta and all of our users for this application are based in New York City. We put in a zillion+ hours into this prototype and pushed our limits both as a team and as individuals. We learned just as much about the technologies we were testing as we did about ourselves. About four days before we flew up for some of the most important meetings we would have this year, we decided to completely rip out the core functionality and rebuild it from the ground up. In the words of my beloved rap superstars, that shit cray. We ended up building that prototype while we were 30,000 feet above ground on our way across the country. We spent the next two days in non-stop meetings presenting to our core users and their bosses [talk about an exhilarating few meetings- one of the users even pulled me aside and privately told me ‘I f-cking love it!’].
This prototype was successful in three huge ways: one, we confirmed our technology decision, two, our users gave tons of feedback on how they wanted the new system to work [partially because they were excited about it] and, three, we learned that our team comes together in a way that none of the other teams we previously worked with did.
The type of prototype you create needs to help you meet your goal.
I was beyond excited for my next trip to visit the users after such a successful meeting with them; I was bursting with new ideas I wanted to share. I worked with the developers and came up with an incredibly dynamic automation tool that had the potential to make their jobs easier and ultimately assist them in being more efficient in their day-to-day work. Unfortunately, I went about sharing the idea with them incorrectly.
My first mistake was taking a highly technical idea sketched out on paper to a group of very visual people. The second mistake was not having a developer present at the time to help me walk them through the feature [it was deeply rooted in mathematics and, let’s be honest, I went to art school, I don’t handle numbers all that well]. Users had questions I wasn’t sure how to answer. As a result, the users rejected the prototype and I came back to Atlanta feeling deflated, sad and filled with anxiety [I still had to inform the team of my findings].
When I got back to the office and shared the insights with the team, I realized that each prototype I work on has a unique goal. Looking back, I can’t believe I took a basic vanilla paper prototype to my users and requested they imagine some of the most complex interactions I’ve ever worked on; paper prototyping was completely inappropriate for this feature [you’re probably thinking ‘duh, Jack, you dumbass’]. Even now as I sit here writing this, I feel a bit embarrassed by the prototype method I chose for that one. Lesson learned [I won’t make that mistake again].
Every day I’m prototypin’.
When I’m working on a particularly difficult interaction or design, I tend to prototype it once, twice, sometimes even three times before the users see it and provide feedback. My daily prototypes almost always begin as sketches and then go through moderate prettification in Photoshop before they end up in HTML or Axure. It sometimes takes me a few days to complete a single feature, but I’ve taken the time to think about it from different angles and [with the help of my insanely talented BA] dragged it through [almost] every possible use case.
One of the biggest gripes I hear from my friends in the industry is that they don’t have time to prototype, it’s not cost effective or their boss doesn’t believe in it. I’m sorry y’allsies, but I call bullshit on all of those excuses. Make the time – not all prototypes need to be production ready. Putting complex features into your systems without getting user feedback can be dangerous. I always use the example of my paper prototype disaster when people tell me they don’t have the time and their boss doesn’t think it’s necessary. Think of the amount of time my team would have put into designing, building, and testing that gigantic feature only to rip it out and rebuild it later [by the way, we’ve spent a lot more time on that beast and have decided to take a different direction with it because of that feedback, but the feature is still going in and the users are happy about it]. Do you think the designers at Toyota flip the switch on the assembly line without testing the new Camry? I’d bet some serious cash that they don’t, so why would you blindly crank out features for all of the people using/buying your product?
The bottom line.
Here’s the thing, in order to be successful at prototyping you need to do these three things:
- Determine the goal of the project
- Decide the best method to articulate your ideas to the users in order to achieve the goal
- Get in the habit of creating prototypes daily; you’ll only get faster and smarter about it
I feel like I need to end this post on something more profound than the three points above…
Hmm… Oh! How about:
PROTOTYPE OR DIE.