Application Teams Can Deliver A Better User Experience (Part 4: Prototypes)

A Prototype is simply a close representation of something, usually at a smaller scale or lower level of complexity. For application teams, prototyping typically refers to the creation of wire-frames, sketches or mock-ups of an application. Lucky for designers, there are a plethora of tools available to facilitate rapid creation of software concepts (Webflow, Origami,, or a recent personal favorite: Atomic), but often the most effective prototyping activities take place on a whiteboard or with pencil and paper. Although many organizations think of prototyping as a UI design activity, prototyping sessions should include discussion of application architecture, organizational considerations and user needs.

Don’t be afraid to fail

Contrary to popular opinion, we don’t build prototypes to fully enumerate sponsor expectations or to finalize application design before we start coding. The main goal of prototyping is to:

  • generate valuable communication between sponsors, stakeholders, developers and designers
  • convey assumptions and expectations early and often
  • document, visually, those expectations throughout the entire application life cycle.

As such, prototyping epitomizes the lean mindset of “fail fast, fail often” common among organizations committed to delivering exceptional user experiences. Effective prototyping sessions target high-risk areas first in an attempt to uncover potential deal-breakers early. Often, it’s important to question how good an application proposal actually is. I’ve heard it said that “most people make decisions based on gut feeling; they are either lucky or wrong.” (Forgive me, I don’t know the quote’s origin — if anyone knows feel free to comment). Hint: Be prepared to get a lot of nasty looks if you plan on telling a product sponsor that his idea isn’t very good. But remember, we aren’t doing this just to be negative or mean. (Okay, most of us aren’t). The goal is to identify early on what the best ideas are so the organization can decide how to apply its limited resources. Even when projects get the green light despite contributor’s concerns, just having a “safe” forum where everyone can voice his/her concerns helps sponsors prioritize, scope and fund projects.

Prototyping is so critical because it represents the earliest possible iteration of a product’s value proposal, set of features, interface design and development requirements. Of course, you are free to fly by the seat of your pants…just be prepared to deal with flawed designs, unforeseen technical complications and results that fall short of both sponsor and user expectations — AFTER timelines run over, budgets dry up and your team is exhausted. It sounds harsh, but these outcomes are common. The alternative is to use prototyping as an opportunity to gain important feedback in the early stages of creation, limiting late changes to minor cosmetic concerns.

Prototyping is a team effort

Prototyping aims to expose risk and possible pitfalls before they occur in code. As such, the activity should involve a wide variety of contributors and sponsors in order to gain insight from all points of view. Prototyping is not the exclusive domain of design elites. Any designer who says otherwise is either insecure or ignorant — both are very dangerous. Sponsors, developers, testers, designers, and architects should all be involved (to some degree) in prototyping meetings in order to bring multiple perspectives to the table.

Developers are most likely to be aware of technical constraints and can help guide sponsors to feasible solutions. Testers can craft testing plans early and suggest processes that make testing easier throughout a project. Architects provide perspective on infrastructure assumptions that may or may not be correct. Designers usually guide these discussions as facilitators and propose solutions that take into consideration all points of view while simultaneously simplifying as many aspects of a prototype as possible.

Do it early, do it often

Prototyping is incredibly valuable early on because visualization forces us to question our assumptions, which sometimes reveals undiscovered obstacles and opportunities. When prototyping occurs before requirements are written, everyone is exposed to discussion of business value and user needs, as well as how projects get funded. In house delivery teams are increasingly functioning as consulting solution providers to the rest of the organization. These teams become more empathetic toward organizational concerns when they are included in business value and funding conversations from the start, and such conversations benefit greatly from the technical insights of these individuals when sponsors involve delivery teams before funding the project.

Ideally, prototyping before funding will create focus surrounding the specific problem being solved and limit the number of assumptions (“gut feelings”) about what is being built. For example, rather than tasking your delivery team with building “the next version of your customer-dashboard” (with built-in assumptions about scope and features), a prototyping session should deal with “making managing payment methods easier for your customers.” This approach could lead to improvements to existing applications, the building of smaller, use-case-specific micro-applications, or something completely novel.

Oldies but goodies

Although many tools exist to build wire-frames (I unabashedly declared my affections for Atomic earlier in this post), many software companies still swear by the whiteboard. Not because of cost (many great prototyping tools are completely free), but because the purpose of prototyping is to facilitate discussion. Contributors presented with a Photoshop mock-up are less likely to engage critically, ask fundamental questions or offer broad feedback. By contrast, those participating in a white-boarding brain-smack are exponentially more likely to question underlying assumptions of concept and design and really engage in the prototyping process. Successful prototyping sessions will actively encourage this type of involvement, and, critically, always treat prototypes as fluid. Feedback should never be rejected because “we have already decided that this is the proper design.”

Whiteboard prototypes avoid the overhead and undue focus on a specific prototyping tool. They also avoid the risk of allowing the prototype to become the production applications. I have been in situations where rapid turnaround is preferable to thoughtful design, but this almost always results in a poor UX. In my experience, white-boarding typically leads to more functional prototypes that may lack all the bells and whistles, but that allow participants to test ideas with minimal effort and time.

Pay attention to the details

Without talking about the dirty details, assumptions cannot be uncovered. During a recent project, I was tasked with building a mobile application where the project’s stakeholders thought that certain common mobile application features, such as smooth-swiping and persistent sign-on were native to all mobile applications. Of course, this isn’t true, but by digging into the nitty-gritty during our first prototyping session, we exposed these assumptions and were able to visually document these requirements, thus avoiding disappointment late in the project.

Whiteboard prototypes (or insert your prototyping tools of choice here) should get notated extensively with assumptions as they are uncovered. Don’t be afraid to muddy up the works — all subjects are fair game: users, target customer base, infrastructure, technical feasibility — nothing should be sacred. Snap a photo of your diagrams at each iteration and distribute it to all participants. Future discussions should continue to treat these diagrams as subjects for fluid discussion.

While detail is extremely important — the type of detail you capture is also important. This is not necessarily the time to decide on styles, button placement, color schemes and other aesthetic treatments. It is much more important to capture effective behaviors, layouts and workflows for specific application tasks. Much of the “style chat” should be left to designers anyway — after all, that’s why you hired them, right? The point is to not burn cycles on look-and-feel minutia! This can only hurt you and ultimately slows the entire process down. I know first hand that once people see styled, colored mock-ups, they can sometimes irrationally fixate on unimportant details rather than the big picture.

Why is any of this important?

Failing to implement prototyping sessions in the manner described above (or some similar flavor), or worse, ignoring prototyping all together, typically leads to applications that follow the same patterns as legacy applications. In the worst cases, data models and other existing architectures wind up dictating design even more than the people tasked with creating it, which results in design that is more accidental than intentional. These applications are easily identified because they amount to little more than “interfaces to data.” They are almost never held in high regard by the organization or, more importantly, it’s customers.

Let me offer a real-world example. During a consultation I had a few years back with a client, they lamented about a project they undertook to introduce a variety of social features to their internal suite of web applications. Among these features were the ability to rate content, leave comments and deep link to content to facilitate sharing. Specifications were created and handed out to developers. After a few weeks, the development team enthusiastically presented the new functionality .. which didn’t match sponsor expectations. The development team chose to make these features available only to signed-in users. But the project sponsors wanted the new features to be usable by anyone. They were far less interested in the new features, then they were in the data they would generate. Unfortunately, the site had an unusually complicated registration process which limited the number of people willing to push through so they could access the new feature set. Of course, this drastically reduced the volume of data generated for analysis. “If we had just spent 30 minutes in front of a white board mocking this thing up, someone would have asked, hey, where does the username for a comment go.”

Prototyping should be an ongoing practice, not just through product development, but whenever a question about an application feature surfaces, or plans for future enhancements or refactoring come in to play. Nothing benefits an application’s user experience as much as effective prototyping. Mid-to-hi-res prototypes are often the subject of a product’s first user study, and offer early insight into how real users will interact with your product — helping you to define product “fit” as early as possible.

This post is the fourth in a five part series. Next: Application Teams Can Deliver A Better User Experience (Part 5: Analytics)