8. Building the Framework Toolkit

You might never have given any real thought to many of the elements described in the previous five chapters. Others, you may have worked into your vocabulary long ago and never examined again. Either way, you may have missed opportunities. If you’ve never really taken a hard look at the design of a registration form, for example, your form’s completion rate may be less than it could be. If you developed an approach to handling search systems years ago and never reexamined your opinions on the matter, you may have delivered search systems that fall short of their goals.

It’s important to keep looking at interaction elements with fresh eyes, and we hope that our discussions of the design criteria in each framework have helped nudge you in that direction. But please don’t think we’re here to criticize. To the contrary, we’re just as likely to fall into the traps of old thinking as anyone else. Simply put, it’s incredibly easy to forget about these rote interactions and never put the kind of thought into them they require. And this happens for a very good reason.

Designers face a couple of recurring pain points, and they are directly related to each other. First, many find themselves designing the same elements over and over again. Contact forms. Search screens. About Us screens. Catalog architectures. Sign-up elements. Account management screens. With every new project, this list can look virtually identical to the last one. Second, most of these elements are incredibly boring. Worse, they take up more time than any other aspect of a project.

Is it that the state of design on the web is stagnating? Hardly. Every project brings on a new set of challenges, people, and things we can get excited about. Is the process becoming routine? That’s unlikely, as many designers, especially consultants who work with a wide range of clientele, can work on hundreds of projects over their career and never see two that look even remotely alike. So how is it that these lists of elements to design look so similar? As it turns out, most projects actually have quite a bit in common.

On almost every project, designers make similar recommendations, at least in principle, about all kinds of things. Form design. Error handling. Global-navigation structure and position. Search placement and flow. On each project, designers adapt to the situation to make the details work for that project, but at a high level, trends run rampant.

Frameworks belong as a standard tool for design work precisely because it is so common for these rote processes to take over a project’s time and resources unnecessarily, and because it’s so common simply to chug through them without ever thinking about them. To this end, we hope the act of documenting frameworks will bring these issues back to life for you, and by paying attention to the rationale behind these systems, we’ll inspire you to reinvigorate your approach to them, and to start pushing the boundaries to come up with new ways to solve old problems.

To do any of this, however, you must first understand how to identify, validate, and craft frameworks—whether generic or exclusive to a suite of products from a single organization—as well as how to share them to best leverage their benefits. In this chapter, we discuss these very issues.

Crafting Frameworks

As we mentioned in Chapter 7, Robert asked his workshop attendees to identify commonalities across sites from specific industries, document these elements, determine a set of design criteria for them, and then brainstorm ideas for how to put the criteria to work, thus devising new solutions. And this, in a nutshell, is exactly how it’s done. But odds are, you don’t have the time to arbitrarily choose a bunch of systems to document, nor do you have the will to carefully diagnose which sites to use as source material when identifying the elements that compose them. You need shortcuts. Cheat codes. Solutions that are “good enough.”

Here they are.

Identify the problem

First, don’t worry about preselecting a set of frameworks to document. You don’t have to seek them out—they’ll find you. In just about every project, there is a set of frameworks just waiting to be stumbled upon; all you need to do is notice them, and then flesh them out just enough to get through that aspect of a design project more easily and efficiently next time around. Each time you return to the framework, you can add more and more detail as you notice it. In other words, frameworks probably won’t come off your fingertips as perfect, thorough, complete documents. Instead they’ll start as vague lists, and eventually grow into a valuable resource, complete with examples, screen shots, and an inspiring list of design criteria.

To begin, you simply identify a problem that appears to need solving beyond your current project. The previous five chapters contain examples of this type of problem, but the possibilities far exceed the scope of this book (or perhaps any book). You’ll find search, catalog, About Us, and other frameworks on countless sites. You’ll design these things countless times. If you deal with it more than once as a designer, it’s a good candidate for framework documentation.

While the frameworks we’ve described here will help you get started, our list barely scratches the surface (remember, we went into great depth for each of these; had we written up a total of just 20 at this depth, this book might never have seen the light of day). Here’s a short list of frameworks you might encounter on a commerce project:

• Account management: Elements for managing a user’s account—sign-in and sign-out screens and navigation; the Lost Password task flow; and screens to change or reset a password, update the user’s email address, billing information, and so on.

• User profile: Outward-facing profile information about users within a social context—username or alias, avatar, list of reviews by the user, personal factoids (such as the user’s location), and a list of products the user recommends or has added to a wish list.

• Shopping cart: Elements aimed at collecting and managing a user’s purchase list prior to checkout—list of items, their prices, and the purchase subtotal.

• Checkout: Elements enabling a user to complete a purchase—total cost, shipping options, payment form, confirmation, and receipt.

• Order management: Elements for managing and tracking orders—shipping status, shipment tracking number, option to cancel an order, instructions for returning a product, and customer service contact methods.

You’ll probably also need the search framework, About Us, an orientation framework dedicated to helping a user get familiar with a site (header, navigation, tag line, and so on), and, of course, the most essential commerce framework of all: the catalog framework.

As you work through a commerce site design, you can begin to document any or all of these frameworks as you think about the user contexts they support.

Tour for sources

Now, to validate your frameworks, it’s best to study the work of those who came before you. Part of traditional design education involves doing just that. Composers study the work of other musicians, looking closely at how an artist put together and arranged a composition. Architects study existing structures to see exactly how they solved difficult problems.

Studying the works of those who came before us is a long and glorious tradition. However, because the act of designing for the web is still new, especially when compared with music composition and architecture, we don’t have a formalized method for studying these works. Instead, we have to take tours.

Touring a site is different from just experiencing it. When you use an e-commerce site, you concentrate on your goal: selecting and ordering the right product. With a well-designed site, you’ll be engrossed in the goal. You won’t pay attention to the site’s construction.

When you’re touring a site, it’s a different story. You can pay close attention to the details, from the subtleties of each widget to the overall flow of the application. The object becomes to pay little attention to the content on the site and instead focus on how it’s presented and manipulated.

Finding the influences

Google has a policy called 20-Percent Time. Twenty percent of the time, Google designers can work on something other than their assigned project. The idea is part fun, part education. When you play with something outside your usual field of effort, you learn things you wouldn’t learn otherwise.

Consider what would happen if we spent half that time—just ten percent of our workweek—touring other sites. In a forty-hour week, we’d spend four hours exploring the designs of other sites. If we spent four hours doing this every week for a year, we’d get more than five weeks of research done. We can learn a lot in five weeks.

What sites should we study?

We can start with our competitors, to see how they solve the same problems we’re facing. We can also look at sites that have to be good to survive—where a bad design will kill the business. Companies that operate exclusively online, such as Netflix, eBay, Amazon, and Dell, earn most (if not all) of their revenue through the web. Looking at those sites can help us see how designs can evolve to meet the needs of both the users and the business.

It’s not good, however, to look only at the most popular sites. You should spend part of your touring time looking at sites you’ve never heard of before. Jared and his team at UIE recommend to clients that they look at sites with very different purposes than their own organization. Banking sites, dating sites, universities, bookstores, and online utilities, such as blogging tools or artist-bidding sites, are all candidates for touring. From each of these examples, we cab see how designers have adapted basic architectures to the site’s unique problems, and we can capture ideas for innovations in our own space.

What we look for

When touring, one thing to try to identify is what we call problem/-solution pairs. You can think of a finished design as a designer’s attempt to solve a problem; by looking at the solution, you can often guess what problem was being solved. (This, in fact, is the key to determining a list of design criteria.)

The goal of touring is to compile a catalog of potential solutions to the problem you seek to solve. Down the road, when you run into a similar problem, you can refer to your catalog. You can also revisit the original sites to see if their designs have evolved further from your original inspection. Seeing how others tackle the same problems you have can give you insights for your site.

Libraries offer a great example of this. As described in Chapter 3, library sites built atop the Polaris system (because of design issues baked directly into the Polaris software) often deviate from even the most common-sense standards, resulting in poor support or no support at all for things that should be a given. Worse, other library vendors who build add-on products for the Polaris system have to adapt to it, often creating designs that only compound the problem. Library software vendors, and Polaris chiefly, would greatly benefit from looking outside the library industry to explore the standards long established by companies running successful sites that support similar activities. To put this in context, consider several of the ways a Polaris-based library site breaks from tradition:

• By inserting all item information into search-results pages, the system may require fewer clicks, but user scan’t bookmark the content pages.

• By disregarding considerations for what types of content should appear in search results (which we discussed in Chapter 4), searches often result in a disorienting array of mixed results, few of which reflect a user’s intent.

• With the default use of terminology such as Patron in site navigation, users are forced to think in ways not in line with their own mental models.

• Providing access to machine-readable cataloging (MARC)–format records (comprised of coded item information only librarians are likely to understand) within search results, and representing the MARC record with a book icon, which could appear useful to users, Polaris may solve a problem for librarians, who occasionally need this information, but simultaneously places right at their fingertips something users should never have to see.

A library catalog is functionally no different than a commerce site—they support virtually identical activities. By studying Target.com, Barnesandnoble.com, Amazon, and other successful online retailers, the Polaris team could easily resolve many, if not all, of the problems it exposes to its enormous base of library users:

• Creating stand-alone content pages that users can bookmark solves several usability, scalability, and accessibility issues.

• Revamping its search system will yield better results.

• Using terminology more familiar to userscould help them get oriented to the site and find the items, information, and functionality they need.

• Creating a librarian-only view with enhanced functionality would serve to hide content that is useless and confusing to users while still providing it to librarians as needed.

These solutions, and many more, could significantly drive up circulation for a library. Circulation numbers are a library’s version of revenue; these numbers directly affect how much funding a library is offered the following fiscal year.

Observing within your own industry

For solutions specific to your project, also consider touring other sites in the same industry or niche. What you find there might amaze you.

The workshop team Robert asked to curate a framework for higher-education websites surprised everyone by noticing that the vast majority of the sites studied were virtually identical in terms of information architecture and scope.

All the sites the group studied featured links to sections about the school itself (campus life, history, and so on), academics, admission and financial aid, alumni, and the library. They even used identical terms for this navigation. This incredibly standard navigation scheme showed up on every site, from the worst to the best.

The similarities didn’t end there.

Every one of these sites continued what Jared affectionately refers to as the “girls under trees” phenomenon—the uncanny presence of at least one photo on practically every higher-education site of at least one female, frequently more, sitting under a tree.

Creating the appearance of both ample opportunity and appropriate circumstance, it makes us wonder if research might indicate that girls under trees are perhaps a major selling point for boys who would like to meet them.

If you work in the insurance industry, study other insurance companies’ sites. Stock photography? Study stock photography sites.

If you work in the library profession, however, it might be best to stick to sites outside your industry.

Write it up

The next step in developing your framework is simply to document it, and we’ve shown throughout this book how a framework document should be structured. Of course, even this seemingly painless aspect has its complications.

While some managers believe that once a great design is hatched, a simple written document is all the development team needs to make it a reality, it unfortunately takes much more work to communicate anything but the simplest of solutions. Design deliverables are a critical bridge between designers and developers. Both the documents and the process that produces and delivers them deserve careful attention.

UIE once looked at how teams ensured they communicated design ideas successfully to their development teams. The research showed that teams can lose many important details as a result of poor design deliverables and a poor delivery process. The problem is compounded as the tools for interactions become more complex. As client-server interactions become more sophisticated and interaction capabilities, such as drag-and-drop, become richer, a simple write-up can’t do the project justice. The most successful teams play close attention to the critical goals behind their deliverables.

In an ideal universe, the designers and developers would all go into a special room, put on special helmets, and within seconds have every detail of a design instantly communicated to everyone on the team. In our universe, however, problems occur because the developers can’t read the designers’ minds. It’s not that the designers are deliberately keeping important details from the developers, but rather, that when you’re neck deep in thoughts about a problem, it’s hard to know if you communicated all the details in your head.

Here are some of the details that frequently get lost in the crossover:

• The priority of the different design elements: Not every element in a design is equally important to a user’s objectives. In the design process, the team works out the relative priorities. However, if all that developers have to work with is a screen shot or a rough design sketch, the priorities are lost.

• Subtle interactions: Static images make it hard to show dynamic activity. It becomes more difficult when screen changes are triggered by users’ actions that don’t have corresponding visible controls, like a mouse-hover behavior.

• The rigor of the design rationale: In the design process, some portions can be heavily discussed and considered by the team, who will try out multiple iterations and hammer out the result. Once turned over to developers, changing these portions can upset a carefully tuned balance. However, other portions will remain unchanged from the beginning. The developers need to know there may still be more flexibility in these portions.

There are tricks to creating a deliverable process that gets these details across. For example, according to Keith Robinson, a former principal and creative director for the Seattle design firm Blue Flavor, the company creates a design-priority document that describes, in priority order, each design element and how it works. As implementation issues surface, the document acts as a guide to making decisions.

To help communicate the more complex interactions in the design, consider delivering an interactive prototype along with the written description. Many teams we talked to use prototyping tools, ranging from paper to Adobe Flash, to show the developers how a design works. These prototypes don’t have to be fancy—they only need to show how the interface will operate when implemented. In fact, it’s surprising how effective crude paper prototypes can be and how pleased developers are to have them.

One team UIE talked with used a visual language to communicate the designed features’ varying degrees of thoroughness. The elements they’d rigorously thought through were in regular text without any indentation, whereas elements that hadn’t yet received much consideration were italicized and indented. This simple yet effective visual language told the developers what they needed to know.

Other teams made sure they included a description of the testing process they used and the rationale behind the finalized designs. Communicating the design rationale, along with the finalized design description, can help the development team maintain the integrity of the high-priority elements throughout the implementation process.

Reducing development costs

In UIE’s research, many teams had been plagued by ideas that looked great in theory but didn’t work so well in practice. Sending the design back to the drawing board and the subsequent redo work increased development costs and slowed deployment. Finding ways to reduce or eliminate these costs is good for the organization.

Many teams turn to low-cost, fast-implementation prototyping tools to help reduce costs. Again, these don’t need to be sophisticated tools—only something that quickly communicates the design’s intent.

Having a working prototype is useful, but it’s better when you have accurate use cases to work with. The teams with well-researched personas and scenarios, for example, found it easy to create their use cases, helping them validate their prototypes. By running the prototypes against the use cases, they could see where the design held up and where it fell flat.

When updating an existing design, a couple of teams UIE talked to used before-and-after images to help communicate the differences. Seeing the old design next to the new design, along with a clear description of the changes, helped the development team plot out their work.

Making edge conditions explicit

Alternative task flows should also be considered when documenting frameworks; teams need to clearly communicate the flow branches and edge conditions that could arise. Edge conditions are hard to visualize, however, making them an easy thing to miss when communicating designs to a development team.

Solid research is key to identifying the edge conditions that can pop up when using the design. Several teams established solid communications with the organization’s support center, collecting up a list of the types of problems the support specialists were handling.

Other teams held “What could go wrong?” brainstorming sessions, to imagine what happens when key information, such as account numbers or hard-to-remember personal information, was left out or incorrectly entered.

Of course, many teams used usability studies to identify the types of issues that can arise. However, a few others used some novel approaches, including rewarding team members for helping to identify edge conditions. One team went as far as holding edge-detection parties, where team members competed to see how many different, unique edge conditions they could produce in a short time period.

One novel approach was the use of a “values list” to help ground the designers and developers on the underlying values instilled in the design. These values might include something like “We don’t want our users to feel stupid” or “If we can avoid an error message, we will.” Having values helps team members know when a little extra effort or resources might be the right way to fix a possible problem, instead of taking the easiest implementation.

One team produced a “Contingency Q&A” document, which helped them account for paths beyond the happy path. It posed questions such as “What happens when users leave the Headline field blank?” or “What happens when they try to type more than 60 characters into the Headline field?” Their answers went beyond the specifics and discussed the underlying rationale. (This would match up well with the values list.)

Getting creative

According to UIE’s research, the teams that produced the most effective designs all had well-considered techniques for their deliverables process. They understood they weren’t living in the ideal universe, and thus they dedicated resources to ensuring they communicated the design and its rationale to every member of the team. The results paid off with shorter development times and a higher-quality implementation.

Of course, the area of framework documentation most in need of creative thinking is the Design Criteria section, in which you attempt to reverse-engineer the motivations behind a standard solution, because this is the list that encourages innovation. When working through this list, consider the following comment from Scott Berkun (author of The Myths of Innovation):

Asking these questions should not only make it easier to figure out how something became standard in the first place, but also might prompt new thinking. This can lead to solutions that set you apart from your competitors and earn you some extra appreciation from your users.

Distribute the workload

Countless design teams have realized that a well-built design-pattern library makes the user-interface development process substantially easier; wrapping a framework library around it will help even further. A quality library means team members have the information they need at their fingertips. Choosing usable elements that work smoothly for users becomes the developer’s path of least resistance.

UIE’s research suggests one difficulty in building out the design-pattern library is the initial cataloging effort. It certainly takes a push from the library creators. But once it’s completed, the value seems to be immediate; teams can start to discuss what works and what doesn’t in current designs, laying out a vision for future development.

Like templates and guidelines, pattern and framework libraries require effort to build. However, unlike their counterparts, team members and contributors alike can distribute the work amongst themselves.

Because patterns and frameworks are more like standard engineering-design specification documents than a rule book, it’s easier to get help to produce them. An organization that has already produced hundreds of web pages needs only to document the designs they’ve already implemented, thereby creating the initial collections. Over time, you can update the patterns and frameworks to reflect new thinking in the design direction and notify all the contributors of changes as they occur.

In the next chapter, we’ll put you in the driver’s seat and step through a hypothetical project to help you see how to integrate frameworks into your design process, when to start thinking about them, and how to make them practical. We’ll even give you an example of applying design criteria to devise a nonstandard solution.