Communicating Design - Part 3
Tuesday, October 20, 2009 9:33PM PDT — Permalink
So in my last post, I wrote about some of the early methods I've used for communicating UI designs to developers, and I left off on the Interactive Prototype. To this day that's still one of my favorites, because nothing conveys what the user experience is going to be like quite like actually using the product (or prototype). That said, the fidelity of interactive prototypes can range drastically, and what type you pick depends on what's important to you at a given point in the development process.
On the low-end, I've definitely become a fan of paper prototyping. While I'd done bits and pieces of paper prototyping before, I was exposed to 'serious' paper prototyping while working with a contractor (Meghan Ede) at Opsware. I had been developing an entirely new interface for the Server Automation product, and we thought it would be a good idea to get some early feedback on the usability. Since the software was Java/Swing, building a working prototype in the actual technology was quickly thrown out as a possibility, and we decided that the most important things weren't the colors, alignment, and other polish items, but what we needed was feedback on how users would move through complex task scenarios that in some cases spanned many screen. So with speed and breadth being most important, we hired Meghan to come in and help us run some paper prototyping sessions. I built most of the screens using Microsoft Visio, and printed them out and chopped them up to create our paper prototypes. I still look back on it with amazement with regard to the amount of feedback we were able to gather in such a little time.
On the other end of the spectrum is the high-fidelity prototype, and this has long been one of my favorites. The first hi-fi prototypes I did were at Terraspring, when I developed a 'next-gen' interface using the XUL toolkit. I then followed that with some work at Sun building DHTML prototypes, and that exposed one of the first big win scenarios for hi-fi prototyping. I was able to build a fairly realistic approximation of what the product we wanted to build would look and act like in a little over a month. It wasn't tied to any backend, and the data was all static, but it was convincing enough that the "powers that be" gave us the go ahead to actual build what eventually came to be known as N1 System Manager. By using a high fidelity prototype, no one had to guess what the product might look like, or imagine what a task flow would be. And as the project got underway, I found another win with using the hi-fi prototype. I was able to save the developers a lot of time in designing their layouts, because they could steal HTML and CSS code from my prototype that was already proven to work.
My high fidelity prototyping really came into its own during my stint at Opsware though. In that position, I was supporting the largest number of developers in my career. At one point, I was the only UE person for the whole company, so I needed to develop a method where I could communciate the most information to the most developers in the least amount of time with the least ambiguity. Moreover, I also need to communicate information to marketing for upcoming product roadmap demonstrations as well as to the documentation and training teams for feature walkthoughs. Thankfully, Adobe Flex came to my rescue! Flex used the best of the two toolkits I'd used before. The layout of components is in an XML format called MXML, which is fairly similar to XUL. And all the behavioural aspects are contained within ActionScript, which is fairly similar to the JavaScript work I'd done in my DHTML prototypes at Sun.
Using Flex as the backbone, I was able to create highly realistic prototypes that were used as 'living specs' for my developers, as presentation graphics for conference keynotes (no, I won't reveal what was real and what wasn't), as customer feedback testbeds to walk through new features and gather feedback, and as future-vision inspirations for the product teams to show them where things 'could' go if they invest in the right places. Plus, the best part is that the more you do it, the more reusable components you have, to make you that much more productive in subsequent prototypes. I won't lie... the learning curve is steep! But as with most things, if you can conquer it, the benefits on the other side are substantial.
So being on part 3, I'm going to wrap up this diatribe, but at the same time I want to be clear. As UE/UI/UX professional, we have a responsibility to live and work by the standards we promote. The user is king, and our efforts need to center on supporting the user as best as we can, even when the user is a group of developers inside our own company that need information about what to build. Just because we have reduced time or assets doesn't mean that the principles of design go out the window. We need to adapt where necessary and overcome so we're part of the solution.
