User Experience Part 3: Getting Down the Bones

In my last UX blog post I discussed defining the strategy of a project by inquiring about user objectives and company objectives. I’m sure you all went out and immediately started scheduling stakeholder meetings, agreed on a strategy, and then looked around at each other with that “now what?” look.  Is that what happened? If so, worry not! The next step is straightforward and obvious – write it down.

Putting the strategy and the flow on paper ensures that you don’t forget it. It also serves as the first section of every product manager’s most beloved (and simultaneously most detested) aspect of his or her job–the scope of work. Call it what you will–the scope, the SOW, the spec (this is what I call it), technical specifications, the scoping document, etc.  The bottom line is you need one in order to actually get the product you want to get.

After you have a strategy, define functional specifications, which specify requirements for the project, how the product will function, and criteria for user acceptance. Functional specifications are typically written out and are accompanied by content requirements.

Page content usually has to do with information. You define content requirements by compiling a list of all of the places that messages will need to be communicated to the user through page titles, headlines, error messages, calls to action, etc. Have you ever seen a cryptic error message on a website that is too technical for you to understand? Brainstorming a list of all the required content will prevent issues like that. It assures that you have thought through every possible scenario your users can arrive at.

As soon as you have functional specifications and content requirements you can start scoping out the structure of the product. Wireframes are very helpful in this phase of project planning. Wireframes detail the layout of pages in a bare-bones image. They provide a guideline for the skeleton of the page and are essential reference materials for designers and developers who will actually work on bringing the product to life.

Finally, when the team has agreed upon the functional specifications, content requirements, and layout of the wireframe you can create Mockups in Photoshop

or in actual HTML/CSS code that illustrate the visual design and ensure that standard site elements are being used on the page. Creating a mockup also demonstrates information and functional design elements for the team to examine.

Putting strategy, functional specifications, content requirements, wireframes, and mockups together in a document will give you a spec that your project team can work off of in a sane manner. It is not a simple process, but it makes development move faster because most of their questions will have been answered in a clear way and there is reference material to go back to if key stakeholders are absent.