Interview with Brian Phelps
This interview was recorded on December 3, 2006.
Brian Phelps, an employee of Pfizer in Ann Arbor, presented to the MIUPA on “A Survey of User Interface Prototyping Tools” in August of 2006. Four months later, Timothy Keirnan caught up with Brian to review what Brian told the chapter about GUI prototyping in that meeting.
Interviewer: Timothy Keirnan
Tim: Let’s start with why do you do this prototyping in the first place? What is your goal in doing this UI prototyping with these tools, and can you tell us a process that guides you in doing this?
Brian: The main reason I would do any kind of prototyping is to get a better feel for the interactions that the users are looking to create or capture. We want to get this before we start writing any code, because that’s when we start to burn into cash on a project. Cutting down on coding rework is another main goal for prototyping. The idea is not only to get a good picture of what it is our customers want, but then understand them. Prototyping allows for this, and the software these days has gotten a lot better. Especially for prototyping higher-fidelity applications. If you have a complicated interface design, high-fidelity prototyping may obtain better data than what a paper prototype can give you.
Tim: That’s interesting, because paper prototyping is something I’ve always been very keen on, but you’re saying for the kind of products you’re working with, they can get kind of complex very early “up front”, so doing a high-fidelity prototype of those helps you iterate.
Brian: Right, it really all depends on what you’re doing, what area you’re in. In the area I’m in, I generally need to go to a higher-fidelity prototype faster. I think there can also be a perception bias against paper. I’m not saying don’t do paper prototyping, but in my environment I’d have to do it very fast. I think paper prototyping is great, it serves a certain need early on, but it doesn’t take long before the design can get too complicated. This necessitates getting out of paper and creating a higher level of fidelity to get the interaction that much closer to the end product.
If you only did paper prototyping and then went to writing code, you’d have a lot more risk than if you created a simple high-fidelity prototype. Doing both would be optimum.
Brian: So I guess I’m doing some “de-risking” in using the higher-fidelity prototyping tools these days.
Tim: It’s funny you should say that. I just talked to somebody at the office last week, and they said “Oh, what you’re doing is risk mitigation” and I said “Well yeah, because we know there’s a hundred percent risk that our first attempt at anything is not perfect.”
Brian: Yes, and the bottom line is doing some iterations after that first attempt. And whatever you can do to make that process go faster with your users is what you go with.
We do have a software life cycle at our company that we follow. It doesn’t say anything particular about prototyping in it. There’s a point to do design & planning. The key is doing iterations at a couple points in your project. And if you can only do one iteration, make sure that you feel relatively confident. Each project, at least at my employer, is so different from another that there is no one over-arching right process to follow. It’s more a matter of “Given what your schedule is, go backwards and see how many iterations you can get in there.”
Tim: How did you create your first prototypes?
Brian: The first prototype I did was in graphics programs, Macromedia Fireworks or Adobe Photoshop. I used those because I had no boundaries. I could put things exactly where I wanted them to be, and then make screenshots from those to put into PowerPoint, or print them and show users for doing paper prototype testing.
Tim: What led you to look for another solution in prototyping?
Brian: The main reason we looked earlier this year for a better prototyping solution was how inefficient Visio, Fireworks, and MS Word were at documenting the UI and interactions on an outsourcing project. It was also extremely time-consuming. In this outsourcing project we needed to provide a lot of clarity and definition for what we wanted the system to do. We were able get the job done, but it was just too time-consuming. We really even felt, after we were done documenting, that we still hadn’t provided enough detail and this was confirmed when we brought the outsourcing vendor in for some meetings—we needed to go further.
Also, I could only do so much usability testing with my Visio screenshots. For example, you couldn’t look inside the contents of a drop-down box. The analogy I have used is looking at a two-dimensional object versus a three-dimensional object. Visio only provides a two-dimensional look. We looked into a number of tools and ended up selecting one to create a higher-fidelity prototype for clarifying requirements, for doing usability tests with our scientists, and creating iterations with our business partners. We needed to do things like add fields, take out fields, change layouts.
The Visio environment was not as accurate as the real world application. We would lay out a screen: one column on the left and one column on the right. But in the real world there was never going to be enough room to have that. And we had to change the layout from being two columns to being just one long page. The higher-fidelity prototyping tool helped show us this problem early on.
Tim: I should probably make clear for the reader here that, at your employer, you folks are designing software for your scientists, but you don’t have programmers in-house who build it. You have people who are external to your employer build the software.
Brian: We have both right now, actually. We have developers in-house and we’re starting to do some outsourcing. I don’t know what future plans may be, but we have both at the moment.
Tim: Oh, OK. My next question is what are some prototyping tools available today and how do they differ from each other?
Brian: There are a surprising number of prototyping tools out there, even for high fidelity. I was shocked as I did this evaluation because there are a solid eight or nine of them, which is pretty incredible. Beyond those there are plenty of low-fidelity prototyping tools that are fantastic. In Visio, you can have pages linked to one another for some interaction. If all you’re looking to do is really basic, and you already have Visio because you have MS Office, that’s a great way to go. Also PowerPoint has ways to create interaction between pages and such, because you can link slides to one another.
There’s something called Denim which is a tool, created from academia, that has a bit more fidelity than paper. If you’re doing early-on stuff and just want to get going, pen and paper are really good choices too. Then the higher fidelity tools: iRise, Axure, Serena Composer, Caretta Studio. Visual Basic has been around for years. It’s not bad, but you have to code to create the interaction. Again, that goes into an area where how much code do you want to write to create your prototype? Of course, there’s always HTML: a great, very inexpensive or free high-fidelity prototyping tool. And there’s a lot of ways to create high-fidelity using HTML; there are many free editors out there.
Tim: Are the applications you’re working on at your employer desktop applications, web applications, or websites?
Brian: In our area we’re primarily looking at Web applications and desktop-like applications. We don’t create things like installers per se, but we have client server applications. These have a lot of connections to databases. I’d say pretty much a fifty-fifty split between web applications and client-server applications that we have. Recently we have gone more towards desktop-like applications, because of things like the performance hit of a browser refresh. With web applications, you’re always hitting the server, so the user experience tends to be a little better with the desktop apps because they perform faster for basic navigation.
A lot of these prototyping tools do tend to produce HTML so you do have to be wary of the bias that comes with that. What we do is remove the browser controls to make a prototype feel more like a desktop application. iRise, Axure, and Serena Composer have abilities to create more desktop-like widgets. There are lots of ways around this problem. You don’t want to give too much effort, because a prototype is a throwaway in the end. You should plan ahead for how much project budget you want to put in to your prototype.
Tim: This is good stuff, Brian. My last question is what one piece of advice would you give people who are about to incorporate user interface prototyping in their work?
Brian: The main thing is get as many iterations in as possible. Don’t be afraid that you’re going to get it wrong. Don’t spend months creating your prototype and not show it to anybody. Spend two days and get a decent shell and go show somebody, iterate on the design, come back, and do it again. In the past we’ve spent a lot of time developing a prototype, showed it to people and completely missed the ball. But at least we DID do that prototype before coding. So, get your iterations in there, fail early and fast, and you’ll be better off.
Tim: So fail early, fail often?
Brian: (Laughs) That’s right. It’s hard, the other thing is don’t be afraid of criticism. It is your baby, you have created it, and there is danger in that. So don’t be afraid of criticism; it is going to happen anyway. You can also pair up with somebody. That also works really well, because when working together you can just ask input from the other person “I don’t understand what you’re doing, we need to change it.” As opposed to “It’s MY stuff, why don’t they understand MY work?” That’s the software developer/engineer’s bad rap, right? So as designers we want to get away from that as much as they do. Be ready for people [users] to criticize your designs and be ready to change to meet their needs, because it is all about the end users and customers.
Tim: And don’t you think, as with anything user-centered design related, it’s all about making the development process more productive for the company?
Brian: Absolutely. Any way we can do that using a more refined way of determining what the users need, will make development go that much faster. There are projects where we’ve spent millions and we then had to do version 2, version 3, because we were pressed for deadlines rather than for making sure we got what the users were looking for. So it happens all the time, and I think prototyping has a huge positive impact on that situation. You can get that interaction and feedback much earlier, because if you get it to them after you’ve coded, it’s too late. Even worse, you cannot get out of the path you’ve gone down. With the prototype, it’s a throwaway.
Tim: Thanks for your presentation to the Michigan UPA chapter and thanks for this follow-up interview, Brian.
Brian: Thanks, Tim.