UX Design Planning

UX Design Planning

Summary

When designing from a UX perspective, I find it helpful to plan all my work in a spreadsheet. This forms a useful reference throughout design and help ensure that requirements are not missing.

The WorkPlan for Design Planning 

When planning a design, UX designers need to take into account a large number of factors. Obviously, we have user requirements and these are often foremost in our minds because it's what we're good at. However, we also need to take into account business and technical requirements: the former because any design has to meet the needs of a business; the latter because it has to be built.

But this can be a lot of work. Mentally juggling all these requirements (which can be contradictory or at least require problem solving) is hard for complex projects. It's easy to forget a single line in a 90-page business requirements document that turns out to be crucial.

So I use a spreadsheet to plan. This workplan is not exciting by any means and certainly not pretty, but it is effective. It's not used to communicate to stakeholders except possibly developers who, on the whole, quite like how explicitly it communicates.

For smaller jobs, I often stick to the simple user journey but limitations of space can make a graphic version quite hard to follow. Using a spreadsheet allows a quick display of information and (when there are time constraints) it's very quick to update it.

The final advantage is that it puts off the process of putting pen to paper until later in the process. Sketching is so much fun that it's tempting to do it early (as I mentioned before, I often do it early as a reality check / interface stressor). I have found myself to be more productive if I can make sure I have all the information requirements (user, business, technical) in place and validated - and a single piece of work containing the lot.

High Level

Like a lot of UX, we begin at the highest level (note: I often try to work at multiple levels simultaneously but that's another article) by noting down the high level structure. This equates roughly to a sitemap.

Each separate area of function / content is laid out in a separate worksheet. Large projects can quickly get very unwieldy but it's easier than referring to work docs, wikis etc.

It's possible to develop the sitemap after this, before this or in tandem with this part. The important thing is to stick with whatever the designer feels is best and the first established element should guide the rest.

Function Level

Within each high level area of function / content, I then note the functionality required of this area. This is again at a higher level than we'll be working to later.

The important content here is a breakdown of the unit of function. Included are the overall aims (user goals), pages that link in and links out, and the fundamental information exchanges. It's possible to begin the information exchanges at a high level and work down (i.e., begin with "Enter user's address" and end up with "User's house number / name", "user's street", "user's postcode / zipcode" and so on.

Specific requirements can be noted here: things like date fields that cannot display after the current date for retrieving historic records.

This plan is a work in progress and will change as the rest of the site or application is developed.

This stage equates somewhat to user journeys: it describes the user journey in detail.

Content Level

With the function in place, we can begin to plan content. Things like necessary legal conditions (if there are terms and conditions, links to these can be included in the links out section if necessary), instructions, and pagination for workflows can be included here.

So now we have a breakdown of a page with all the necessary functionality and information. This defines the information constraints within a page and gives designers a very quick overview of all the requirements that the page has to meet.

The usual process is to get these validated somewhere (this might be with stakeholders, other members of the UX team or whatever the organisation deems best) and then wireframe design fun can begin.