(This is Part 3 of a 3 part series.)
So when’s it going to be ready?
I know you want to launch your website as soon as possible – just as much as I, the developer want it to be done. We’re on the same page, truly we are! So when I offer an estimated time frame, I can only do that based on what’s known, not on an unknown set of changes that might come later.
Which means, we come back to that all important planning phase which is why a developer will want all the content and functionality of a website in the questions and design phase (see Phase 2 post).
A Pro tip for you: Your developer will be more accommodating to any changes at the planning and design phase – i.e. the beginning – rather than at the end of a project. What many developers don’t do well is deal with these changes. Some say it “can’t be done” and others try to say “no” indirectly, or talk you out of it entirely; or disappear (the Passive approach). I’m sure you can understand why, they are charging you (usually) on a project basis. If you change the project they may need to change price – you don’t want that.
Project Management cannot be ignored
Project Management is something that gets ignored but it should be considered first. As I’ve been bleating on about for three posts now, planning is everything. A plan does a few things, it makes everyone aware of what will be done, but also, what WILL NOT be done. What will not be done is vital because this is where many dreaded Expectations lie. “My website will have a spinning logo and work on a watch and a 90″ plasma tv and all the content will appear out of thin air…” Another website dashed on the rocks of unrealised expectations. I’m being a bit cheeky here but you get the idea.
The usual line is, “time is limited” so a good plan accounts for this. Project Management and change rounds should always be considered early and not skipped or ignored. Don’t design a townhouse then ask for a skyscraper to be built on that townhouse foundation; they are meant for different things, and as such have wildly different initial approaches. Put simply that skyscraper is going to fall over.
What is the role of web technology in all this?
Web technology should not limit a design but help to make it happen. It can do many things within all those rectangles on the page that move and shift. Try to think of a website as the building and the content as the windows, and the tech is the automatic lighting, elevators and escalators. Does a change improve the facade for the user and everyone agrees it should be done? Then add it to the plan and also to the budget. If a change means tear down all walls and rewire all the electrics, then the first question is: “Is this change worth the trouble?” and “Why wasn’t this change obvious to us until now?”.
Disappointment, unmet expectations, at any stage means things usually slow down as distrust starts to creep in. “Who wants to tear down the building?!” Head off this disappointment by referring to the plan again – “we said we would do X, Y, and Z; but now we want to remove Y and add A instead”. To a developer this can mean tear out part of the foundation (and with it whatever wall of the building it supports) and start over. An unanswered consequence, or a change not paid for, can bring a project to a halt and you may simply hear, “nope, it can’t be done.” That usually means, “I don’t want to do this anymore because all value has been lost in this work.” Coincidentally this is how a user feels when you don’t speak to her but to everyone in the world. Why should she listen to you if you aren’t speaking directly to her and her needs?
The key here, as simple as it sounds, is to keep your developer happy and she will move mountains for you. She wants the site to rock just as much as you do.
Keep testing the site with users as you build
As the site nears completion it’s important to check in with a sampling of users to make sure everything is on track. Some call this “hallway user testing” others call it “guerilla user testing”. But how often is this actually done? Not often, if at all. Developers, agencies and clients can easily get stuck in their own agendas and fair enough; a lot of money can be involved in these projects. Usually because everyone is under the gun to launch. But if you take the time to complete this testing step, you will have a robust and well designed website for your user. It’s a check-in to make sure the missing is being accomplished.
What we look for at this stage is: Are your users confused?
If so, why? Then lets see how we can solve the issues. We might find that some features a user wants is out of scope and we can’t do them now. But we can do them later in ‘Phase 2’, which is why early testing is much more helpful. In fact, test your designs as early as possible on paper. The best place for this testing is at the very beginning. Can a user see how to do an action important to her? If not, then take another look and adjust if the disappointment was big enough.
I read a tweet from Ze Frank that brought this home for me. He said he’d arrange his silverware in the drawer that his guests most often went to first in their search:
It all comes back to expectations. What you expect from me the developer, what I expect from you and what the user expects from your website. If we do our jobs right we can exceed and delight the user and in return they will give you money to show their enthusiasm!
Planning is the key to meeting expectations, because they set the expectations early on
Expectations are laid out with planning and great communication. So make sure you talk to everyone on your team like you know they will do good work. I will talk to you as if you trust me to do my job well and that I’m not trying to make a quick buck. Trust begets trust, and higher performance and satisfaction! Good teams say they all feel better having accomplished something together, larger than themselves. And isn’t this what we all want?
