Wireframes: the good, bad, and useless

As a UI designer, I’m constantly creating all sorts of documentation whether it be rough sketches on a whiteboard or a technical specification. In my article 1000 Words or Less, I touch on the applicability of wireframes in the design process:

Wireframes are purposely non-interactive. This is an advantage in the early stages of design. They not only keep the team focused but also decrease the time to get something in front of them.

While wireframes have their place, they aren’t as useful for documenting or maintaining the final design once coding has begun and should not be relied on to communicate the evolution of the design. Darrel Austin at uxformobile agrees and states in his article about the misuse of wireframes that:

They are an invaluable tool. What I am against is them being used as a document of record outside of the UX team. A wireframe simply can’t communicate the full complexities of the solution to every individual team.

I think this is accurate. He also goes further to suggest that an agile development methodology should serve to evolve the design into code faster and more efficiently than wireframes (and really most other forms of documentation) can. Wireframes as well as most other documentation inevitably become quickly outdated. The time spent making updates to the documentation can be spent sitting with a developer and updating the code.

The one place where I don’t quite agree with Darrel is that I don’t have a problem creating electronic versions of my wireframes. Where he would prefer to keep them on paper and whiteboards, I find that wireframes if used properly are as useful (more so in fact) if they can be shared via email, projected on a screen, or otherwise archived along with other project documentation that gets created along the way. Besides this, I agree with his final words of wisdom:

Focus on the product. Not the wireframes. After all, our users will never be using the wireframes.

Plan of Attack

Since I’m an interaction designer, I don’t normally produce documentation not directly related to design. In most of my projects there is at least a project manager, and a business analyst who handle most of the heavy lifting when it comes to documentation at the start of a project. This is not always the case however and the duties of producing up-front documentation falls to those that don’t normally do it. In other words, me.

I don’t always have the luxury of working with a fully staffed project team. This is not just the case at my company where nearly all my work is geared toward internal clients (our own employees) but happens often at consulting agencies where team members are called upon to wear all sorts of hats or places where staff size is small and money is tight (who hasn’t felt this?). When this is the case, I or others on my team (of three!) need to step up and get things started.

One of the first things that we’ll produce is a Project Work Scope. In many cases a project work scope only gets written when the project charter has been given a green light by some person above you who parks their Mercedes in their reserved spot in the parking garage. The project charter is a very high-level document that gives enough information about the intent of the project and the problem that it’s trying to solve. Boring.

Even though the project charter and project work scope aren’t necessarily page-turners, the project work scope is a crucial piece of documentation that serves several purposes:

  • succinctly states the background and the problem that needs to be solved
  • describes the specific ways in which this problem is going to be solved
  • gives rough estimates of how long each thing will take
  • lists the people that will be involved
  • specifies dependencies – what is required in order to be successful
  • specifies constraints – what things might stand in our way

There are other things that are also appropriate for inclusion in a project work scope but may depend on what your project is trying to accomplish. For instance, I don’t have to worry about budgets since I don’t bill any clients, but time-frame is still important. Include only those things that you know will truly impact your project and leave out the things that won’t. Some other things that you might want to include only if it makes sense for your situation:

  • capital expenses (e.g. hardware, software licensing)
  • organizational impact: will this require resources from other projects or outside of your immediate dept?
  • work alignment: how does this project align with other initiatives already happening in your organization?
  • stakeholders: who is either driving this initiative or who will be directly affected by it?
  • project approval: get sign off before starting the work.
  • items out of scope: this is the yin to the in-scope’s yang. Also good to get down on paper.

The bottom line is keep the document as short and to the point as possible. Once everyone who is involved reads and agrees to the work, you’ll hopefully never have to look at it again. If you do though, it won’t require much effort to look it over.

When would you look at it again? When the project is getting off track or is suffering from scope creep. Put those ideas into a feature list to be prioritized later. Let everyone know that you’ll get to the ideas, just not now. The project work scope is a good way to remind everyone why you’re engaged in the project in the first place.

Here is an example of a recent project work scope that I put together for a small-scale engagement with another project team (also the motivation for this post): Project Work Scope Example

For more information than you ever wanted on this topic the following might be useful (in order of anal retentiveness):

1000 Words or Less

As an interaction designer I’m sort of obligated to actually let people see my work. The document format I choose ultimately depends on what I’m showing, the audience, and how far along I am in the design process: start, middle, or end? Providing the right level of documentation at the right time is a powerful tool for creating the best design.

For early-on-designs, I often choose to walk my teams through some wireframe mock-ups accompanied by a very basic narrative. I use Visio for these and found a nice template that mimics hand-drawn sketches (zip file). These are effective because as a tool for discussion the team can concentrate on how the business requirements are being met and less about how things look or behave. Wireframes are purposely non-interactive. This is an advantage in the early stages of design. They not only keep the team focused but also decrease the time to get something in front of them.

Eventually I have to make some actual real-looking UIs. More than just a nice picture for a developer to use as a model, polished designs serve other purposes as well: testing and validation.

As I’m moving through the design process, I ask myself when I want to test some of this stuff. Although I think I’m great, I’m not so great that I always get the design right the first time. I want feedback. Feedback from actual Users tells me if I’m on track or if it’s time to spend more time at the drawing board. My goal is to get the design to a point where not only does business agree that I’m meeting their needs (business validation) but that Users can actually get things done (User validation).

So, at this stage I’ll want to spend time creating UIs that look finished. For testing I’ll want to spend time making them feel finished too. With mouse-over, and on-click events I can make a UI feel as if it’s actually doing something—submitting data, navigating to another page, or removing an item. These are simple interactions that will produce good feedback. These I consider high-fidelity designs.

For business, these same mock-ups are put into a Design Walkthrough. Much like at the start of the design process, these high-fidelity designs are put into sequence with detailed descriptions and narratives that explain in more detail exactly how the UI is meeting both the business and User need.

Once a design is accepted I’ll provide either a UI Specification or a Design Brief. I’ll provide the developers and QA a UI specification that includes the finalized UIs including a description of each and details about what each piece of the UI does and how. For simpler designs, such as breadcrumb navigation (a UI standard) I’ll create something less technical.

Based on the same concept as a creative brief, the Design Brief is an overview of an interaction, component, or some other type of UI design widget. I’ve tailored this document for my own use and for the case of breadcrumb navigation, the goal is to publish the design in our UI standards library. Things that I ensure are included in a Design Brief are the problem being addressed, the design requirements, and the proposed solution. For our use, I include other sections as well, such as when and when not to use, target users, and a user story. These help to give context and rationale to the solution.

I like Design Briefs better than UI specs because of the sheer size of a spec and the time it takes to create and maintain. Design Briefs are put together quickly and are easier to update making them a perfect alternative to UI Specs and the perfect design document for working in an Agile development environment.

In the end, the kind of documentation you provide needs to make sense with where you are in the development process. It’s a delicate dance of sorts. I tend to use documentation to get only enough feedback to inform the next update to my designs. I have found that early on, keeping the team focused on how the interactions are meeting the business and user needs rather than how the color is distracting, or font is too small will keep meetings on point and give the right level of feedback needed to keep the design moving forward.

Move toward higher fidelity designs when you are prepared to put things in front of Users or you are comfortable with beginning to discuss how things are going to work technically. Because once business and developers see realistic looking UIs, the questions will be fast and furious and there will be no going back.

Becoming a Librarian

It’s not that I was dreading writing an article about creating a UI standards library, it’s that I wasn’t sure where to start. It’s a big topic that spans years of effort on my part and the part of my colleagues. While I was beginning to outline some of the critical points I wanted to cover, I came across an article on Boxes and Arrows website that is an excerpt from Nathan Curtis’s 2009 book Module Web Design. In it he lists and defines the questions that an organization should ask before endeavoring to create a UX-related library. It is essentially a summarized version of the same one-question-at-a-time process that was used to help my organization build our existing standards library so I thought it made sense to follow his lead.

He starts by asking “Why Do You Want to Create a Library?” What seems like a very obvious question with what might seem like a very obvious answer it should actually be given a healthy dose of consideration. Creating a library is not a trivial undertaking, so ensuring that the goal of the library is clearly defined is imperative. The answer to this question will be the catalyst for creating the foundation of the library itself. But I do think that in most cases, even in small organizations, it’s a very good idea to have a library that provides in the very least a centralized location that every interested person can have visibility to.

So, the first question was a no-brainer. For our very large enterprise we were doing ourselves a disservice by not having an authoritative repository of UI standards. I think that it’s a great idea in and of itself but it was necessary in helping to address a fundamental goal in our IS department of providing our users a seamless experience. Without centrally published standards and well defined unilateral approach I don’t see how our organization—with dozens of independent applications spanning several business disciplines—would ever meet this goal. Because of this we  had already successfully answered the other questions Curtis poses regarding business stakeholder and design team buy-in. Our enterprise is enormous so in our minds there was no question that a library was necessary to the success of meeting our goals.

Once we had solidified our goal and determined that creating the library was a worthwhile endeavor we began the arduous task of building the information architecture, layout, and overall presentation the library would need to successfully communicate the vast amount information that would finally be published.

Curtis mentions at least two fundamental types of libraries, one for components and one for patterns. Although he seems to treat them as mutually exclusive entities, which is something that I don’t quite agree with, the overarching question gets at the heart of the most fundamental question: “are you building the right kind of library?” Indeed. And while this question is valid as is, for our needs I think that a more appropriate question is “are we building an effective library?” To me the distinction between pattern and components is insignificant. The guts are more important.

The Guts
To begin answering the question “are we building an effective library” we had to keep in mind our original goal: providing our enterprise a seamless user experience. We knew that eventually the library would include both components and patterns but I didn’t think that we needed to worry too much about the difference between them. What mattered was capturing the right level of detail. So, we asked ourselves, what is it that our teams need from this thing? As it turns out what they really wanted most were working examples. If we couldn’t provide a working example then a picture would do. The old adage of a picture is worth a thousand words was never truer. So, we focused on the solutions first.

Luckily we weren’t starting entirely from scratch. Over the preceding months I had been working with our designers to create a master feature list of components, patterns and other UI behaviors they thought were critical for creating enterprise-scale applications. If you don’t have a list already worked up, this is the most logical place to start. It may take time, but it’s the best way to articulate the need and value of each item which in turn will help you determine what to work on first. Eventually, we had a list of about 60 items. The items were mostly components as opposed to strictly patterns or behaviors, so it seemed reasonable—at least for the first version—that the library be tailored to describing the proper use and implementation of components.

Working with a small team I began creating the structure and content of the library. To get a good idea of category names I created and conducted a card sorting exercise sending it out to a group consisting of business analysts, business experts, developers, and other UI designers. The feedback that I received allowed me to create the initial categories.

  • Form Controls & User Input
  • Data Management & Display
  • Page Layout & Organization
  • Messaging & Feedback
  • Navigation
  • Visuals

We then set out to determine the level of information that would be appropriate for the same diverse audience that had taken the survey. In the very least we determined that we needed to include an overview and a working example (or sample image) of each standard.

The library needed to cover the following:

  • Name of the standard
  • Description of the standard
  • Problem the standard is meant to solve
  • List of appropriate and inappropriate use
  • Best practices
  • Example of what it looks like

If you’re a smarty-pants:

  • As many working examples of the standard that seem necessary
  • The ability for developers to see the mark-up that created the solution

If you are able to provide a working example and display the mark-up you will provide a huge service to your teams. This is the most looked at information in our library and it normally takes the least amount of time to create! In fact, if you are short on time starting with providing a working example with code and implementation details is enough. The other content (description, problem, when to use) is important but since our teams include a UI designer who was involved in the creation of the master feature list, the team can have the designer fill in the blanks until the remaining content gets created and published.

The Glory
Curtis asks two important questions regarding buy-in, “is your organization ready for a library?” and “is management ready to support a library?” These are about selling the idea that having a library is better for everyone than not having one. Working up your pitch, as Curtis mentions, is important. I don’t fancy myself much of a salesman but I am passionate about UX design. I normally tell the skeptics in my office that this is our way of meeting the goal of creating a seamless user experience. This usually shuts them up. Although we experienced some resistance from several business stakeholders who saw us as more of a hindrance than a help, the support that we received from upper management was critical to our success.

We were given the time required to create a fully realized, albeit first version of a UI standards library. This was the best sales tool we could ask for. You can talk all you want about how great a Porsche is, but no one wants to hear about a Porsche. They want to see it, feel it, and most of all drive it. This is no different with a UI library. It needs to bring immediate value and this is most easily achieved with something that works and can be taken for a spin. A Porsche with no engine is only interesting to a point. I’m harping on this point for a reason. In my experience, just having a library that talks about standards is not compelling enough to gain favor from your intended audience.

And just like the Porsche, not only should the library offer working examples and something immediately usable, but it should look good. The library itself ought to be a place that people will want to see because it looks and functions great as well as offers a great service. I used our existing application branding assets and relied on our front-end technology package to provide the right amount of look and feel. It’s important to maintain the same style or at least the spirit of the style that the library is proposing. In other words, practice what you preach and eat your own dog food. There are some aspects of the library that don’t fully conform to its own content but we maintain the general spirit of the standards.

Enough babbling for now. Let’s take a look at some examples.

Show and tell
Curtis has a terrific diagram that shows what goes into creating a design library. I suggest taking a look at this and reading the article that I reference in this post.

In the meantime, here are some images of the library that I helped create. I think they provide the best means of describing what I have spent so much time on these past few years. I would be remiss if I didn’t provide some examples!

left-hand navigation menu
Left-side navigation menu

left-hand navigation menu open
Each category expands to display each standard entry. A star indicates that the standard has changed or is new since the last version. A tool-tip gives more details about the specific changes.

example standard layout
Each standard shares the same set of sections broken up into a tab set. The last two tabs Performance Data and Audit Checklist support our own unique development process and are not required for a typical library. (click to view full page example)