Planning for User Centred Design

Planning, planning planning planning.

Why? What for? don’t we just start?

Regretably no, there is a degree of forward planning that needs to exist in our work a portion of regiment. This is what is needed to get our methodology paid for.

I’ll discuss in more detail about what is needed to plan, what to plan for and all that good stuff that gets the message across.

There’s no real short answer to this either. So start reading I guess.

What steps are there in a project?
Most reasonably run projects have the following phases. (all generalisations are dangerous so think broadly here). I’ll also preface that the method described below is based upon an intermediate agile / waterfall model, which seems in the Government, to be the preferred way to operate. I’ll post more on that thought elsewhere. More agile projects have similar steps, so what’s below could be adapted to suit.

1. Initiate:
The initate phase is where all the generalised crystal ball gazing is done for a project. Wild numbers get thrown around to guess the production costs, the technical environment, and generalise the scope.

Sometimes Business Analysts get involved here too. Generally it’s involving the Project Sponsors, the Project Managers, Technical Leads, Business Analyst Leads, Design Leads, Architecture support and sometimes, key users or user reps.

2. Planning phase
This is the phase when specification baselines can be established. This is also when you can start to develop execution plans, accurate time frames, and write specifications. This is when user, task, business process analysis tasks are done.

Some technical prototyping can also occur here.

3. execute / control phase
This phase is typically reiterated in increments. Sometimes the increments can be as short as a couple of weeks. This phase is commonly called the “development” phase in more waterfall oriented projects. Development, Visual Asset Generation, testing, and other more development related tasks occur here.

Of course at the end of each increment, a release occurs.

4. finalise / release phase
This phase is largely the post implementation review phase, where final house cleaning and performance reviews are executed.

When to do design?
First up, if the projects going through its planning phase, where initial requirements baselines are being engineered by the Business Analysts, then NOW is the time to get design involved, in fact, you may already be a bit late so get cracking.

Designers work is NOT reserved for the execute phase. Business Analysts do a large portion of work during the planning phase. So should designers. The BA processes typically involve engaging stakeholders, analysing business processes, and engineering new ones. The Designers should at the same time, be conducting user research, developing profile information, developing ergonomic profiles, and drawing up interactivity specifications and so on.

So why does it get left to the execute phase to do all this work. The horse has bolted already, the BA has done their baseline, and during execute, they would be only refining them. It’s not reasonable for the Designer to come in after the main work has been done, do some research and then have to negotiate to get the process models changed?

Why not do it up front, when change is easy. Why not leverage off the BA and go on shared site visits? interview the same users or business owners at the same time?

I’ve often heard the cry “they never give us enough time to do the research!”. My question is, “Did I make it clear how much time I need, and when it needs to be done?”. My experience in the past would lead me to say “no, I didn’t”.

A mistake I’ll pass to you so you don’t do it also.

My view is that designers should be doing all the user research and specifications during the planning phase of any project. (even agile styled ones).

I also believe that designers should truly ‘design’ during this phase. Design in this context is not cutting code, or pushing pixels. It most certainly is not putting anything into development or production environments. Reserve that work for the execute phase.

Of interest I’ll be posting something soon called “Speed designing”. Which outlines how to design quickly so as to catch more, and stress less.

So what the heck should I do?
During the planning phase, the design process should be broken up into several steps.

Plan, execute, implement.

Plan:
At the beginning of the Planning phase, plan what you intend to do.
Look at the project and deliver to the Project Manager a Design Path Plan.
This plan is not the designs, or the research or anything remotely like hard work. It should simply outline to the Project Manager, what tasks you intend to use to gather information, and then actually design. The plan should also indicate how long each will take, the ordering of them, who else will be involved, and anything that might draw a cost. (Recruiting users could be considered here).

Get the Project Manager to own the document, so they should sign off on it and accept that its what they want. It’s of course up to you to negotiate it with them, but they should own it. That way they are responsible for its execution and co-ordination of it within the context of their project.

Execute:
Everything you said you’d do in the plan?…. do it.
Key points here are to get all your meetings and co-ordination done by the PM. This is important. PM’s need to manage their projects. That includes marshaling resources and co-ordinating meetings and their outcomes. If they won’t, you need to try to negotiate them into doing it. I’ll post more some time about that later.

Implement:
Remember how I said earlier that design work during the planning phase should be constrained to not specifically include asset generation?

That’s entirely true. If you get bogged down into the arduous task of generating assets in absence of the development environment, you are simply costing yourself time.

The implement part here is the final generation of the interface specifications. Plans if you will, from which you or one of your colleagues will generate assets, and which will guide the development teams through their part of the job.

If your outputs from this task are as close to possible as flat files snap shots from your high fidelity screens then your on the right track.

I’ve even successfully taken my HAND DRAWN screen layouts (drawn on my tablet pc so they can be tracked / added to word documents and so on also more on that elsewhere) and used them as endorsed specification from which development work was able to be conducted.

I could write for months about this stuff. So more later.

Good luck everyone.