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):