DEVELOPING WEBSITES WITH RAPID PROTOTYPING

As a child, I didn’t have a really good idea about what I wanted to be as an adult. If asked though, I don’t think I would have responded, “I haven’t decided, but I sure hope that I can’t explain it simply to my relatives.”

Welcome to the not-so-wide-world of prototyping, that odd stage of web and app design where your product isn’t quite a sketch, isn’t quite a design, and isn’t quite in development, but rather some mish-mash of all of those things. For a hybrid designer/nerdling like myself, it’s heaven in its beautiful blend of aesthetics and best practices with a bunch of research and practical knowledge rolled in.

The industry is divided right now on the best way to build a website and user experience from scratch. Some advocate jumping directly into designs from sketches. Others vie for a system that builds everything in a browser, a series of web builds that increase in fidelity over time. Others use low fidelity wireframes as a high level blueprint before moving on. At r2i, we’ve developed a process using Axure that outputs high fidelity wireframes and prototypes on a timeline that varies with the product.

Why do we prototype though? What does it accomplish?

1. It’s time for failure! (Find problems)

Ideas come from everywhere while you’re working on solving a problem. Not only is our team constantly collecting and absorbing new ways of displaying information, clients often have ideas that they need to see rendered. In order to vet an idea, we need to have it executed in a tangible way so we can experience it, show it to others, and test the concepts.

Sketches can be too low fidelity to spot problems, especially when the challenge is in the details of a user interface. Designs can root out these problems and often do, but at the expense of interactivity, time, or distraction resulting from the style of the elements. Developing the site traditionally can be brutally time expensive, especially when you’re dealing with an enterprise level team that works in departments.

Axure and other rapid prototyping software hit a sweet spot here by providing a balance of functionality and design. In a few hours, we can knock out a version of a page that is tangible, interactive, and useful in finding problems. We can show it to the client, to the dev team, to potential users, and spot errors early on in the process. By letting the idea fail early, we save ourselves time and the goodwill of our clients.

When we first began laying out our wireframes for Savant, we were asked to create extremely high visibility for their “Get Started” call-to-action. As we prototyped, we realized that it would conflict with headlines and banner images and proposed a solution that was still highly visibile but fit their templating needs better.

2. Creatives are from Mars, Clients are from Venus (Kill the Jargon)

Marketing and web jargon is brutal. If you’ve ever watched a show like CSI with a nerd like myself, you understand how there are dozens of mutually unintelligible versions of English.

This is a simple nerd test. If you show this video to someone and they get mad, they are nerdy.

We’re design and dev geeks. We get excited about our work far too easily and sometimes run the risk of leaving our client in a fog of confusing jargon because we forget that the words “sticky” or “parallax” or “responsive” mean entirely different things (and often nothing) to the general Internet user. We could show other sites as examples, but those frequently end up hurting more than helping.

Us: “So this is what we mean by a sticky header.”Client: “This part?”Us: “That specific part, yes. Just ignore the rest of the site.”

While they may now understand what we mean by “sticky header,” we’ve opened up the risk of our idea getting lost in the veneer of the sample site. What if the client is open to the idea, but is turned off by the specific execution that you show them? What if they become fixated on other solutions that the sample site presents, and ask to wedge these solutions into their design, even if they aren’t appropriate?

In an Axure prototype, we have a few things immediately at our advantage. The site prototype lives in the browser, so it feels native and natural. We can show interactive features in a manner that reveals their structure without getting too bogged down into code and structuring. Instead of having to think about all of the ramifications on how something will be built and if it will be flexible enough, instead we can just focus on the communication with the client, making sure that they’re happy with what they’re getting and that it meets their needs and business goals.

3. Help me, help you, to help me (Internal communication)

Not to get sappy, but I love our developers. I come to them with a harebrained idea or a suggestion, and while they may grimace at what I’m asking, they always find a way to make it work. That is, if I can explain what I’m trying to do.

Static designs are fantastic at nailing the look and feel of the site, but they can really fall flat when it comes to the way that things are supposed to function. If you’ve ever been involved with this process, you know the amazement of realizing how differently the designer and the developer can understand the same design and its implementation.

Just yesterday, a Project Manager, an Engineer, and I were having a conversation about the implementation of a certain feature. For about 10 minutes, we each worked to make sure that we understood the others while standing up for our respective interests, the client, the scope, and the users respectively. Realizing we were getting lost in the sauce (as my mother would say), I offered to knock out what I was thinking in Axure and send it to the two of them. A short time later, everyone agreed that the solution was functional because we had something concrete to discuss.

Our prototypes are more than just a way to test, or to talk to the client, they are also insurance against our internal processes. A thorough prototyping process helps us engage every member of our team, making sure that we are fulfilling business needs, company needs, and user needs simultaneously. They give us a common language to communicate with and a blueprint for future work.

4. The Multipass Approach (Waterfall process benefits)

We’re a pretty collaborative bunch, but we still have a point when our projects move from one department to another. One of the biggest benefits in this multipass approach comes in the handoff—the conversations that we have during that handoff are fantastic at weeding out problems and shaky thinking.

When you have to explain the logic behind your decisions to an outside source, you’re forced to reevaluate your thinking. Not only is your teammate looking for issues or potential problems, but also the process of explaining something from scratch gets you out from under the weeks or months of decisions that are part of your final product. It is a fantastic way of finding non-essential pieces in the work and of getting a fresh take on the usability of the final product. Building your justifications without the crutch of past decisions will help flesh out tiny details and the overarching purpose of your product.

5. No work is lost work (The redundancy argument)

Since I have some developer tendencies (call them character flaws if you’d like,) I can be unreasonably excited about efficiency. For a time, the fact that our prototypes couldn’t be used for the final versions of the site would drive me crazy because it seemed redundant to have someone else recreate the work that I had done in Axure.

One of the main questions that a Usability Designer asks ad nauseam is “Why?” I began asking why I thought my work was wasted. What about creating a prototype is inefficient?

While it might be nice from a time standpoint to build things directly in browser, that doesn’t necessarily mean that it would be more efficient. I never start on the computer, I always start with a whiteboard or a piece of paper, sketching my ideas in rapid succession, trying multiple versions and layouts, documenting my requirements and trying to get my head around the project. Prototyping is just the next step up that curve, bringing higher fidelity for confidence, communication, and consistency.

If I moved to a process where I prototyped in browser using native languages, suddenly my focus needs to shift. Instead of thinking about the optimal interface, I’m trying to figure out how to render something before it disappears from my head. Instead of figuring out the solution to a layout, I have to think ahead and see if the way that I would code it will work for future cases and for the dev team.

Obviously this isn’t a hard and fast rule, many companies have created a process that works for them based around principles of no wasted code. I would argue that while they may not have wasted any disk space with files, they run the risk of wasting their most valuable resource—time. There is a design maxim that design and interfaces should be invisible, the lowest possible focus so that content, tasks, and purposes can come to the fore. I would argue that rapid prototyping fills that goal in many ways, allowing us to show our ideas for interfaces and high-level interactions without requiring us to be concerned about the veneer or it being built to meet our code standards.

Hammering a screw (Using the right tools)

The most important part of our Axure process is defining the level of fidelity we need for our project. Some projects and interfaces need exact documentation, detailed logic, and highly specific interface design. Other projects are simpler and can use more generic pieces where the wireframes can be used to outline the process rather than define all of the technical requirements.

Axure works beautifully for us in our current process, but it is not a tool for everyone or for every circumstance. Its idiosyncrasies and quirks require a lot of learning, especially as you start requiring more complex interactions from it in large systems. We prototype with Axure because it works well with our team, and its flexibility and power compliment the style of work that we do on an enterprise scale.

I can’t explain my job in one sentence yet, especially since the work of a designer for the web is requiring more and more of the interaction design, interface design, and UX design skills that have traditionally been siloed with individuals. However, I can say that the work of a prototyper is quiet but powerful, shaping the direction, experience, and success of the Internet and app ecosystem. I think my Uncle gets that, even if his only reply to my job spiel is “That’s… neat.”

About the Author: Lucas Roe

Lucas Roe is a web dork and UX designer from Baltimore. He is on a relentless pursuit of craftsmanship in everything from websites to cocktails, with an unhealthy fixation where nerd and hipster cultures clash together. At R2integrated he works in User Experience Design and Wireframing while researching user trends and being a fount of pointless information. He spends his spare time voiding warranties on his devices and reading the whole internet.