"I would like a preferences page like Facebook."
Audible groans and mental switching off can sometimes be heard when requirements like these are raised in scoping meetings. Maybe the role of the technical team is to 'just build it' and such is the nature of the environment that there isn't time to second guess and think broadly about what the solution should be. Will this work? Some of the questions that the technical team will have to ask at some level:
- Are they to literally 'build the Facebook preferences page'?
- How will they know when they have succeeded at building it?
- Are there any details that this requirement doesn't capture? e.g. your site doesn't actually allow people to share things, just be notified on updates.
Depending on the dynamic of the organisation, such as low-power technical team and aggressive sales/marketing/other business unit, I have seen the technical team try to 'just build it'. Usually not with the result expected by the requirements gathering team and usually after many developer days.
Goals
Picking sites that I want my site to look like isn't necessarily the problem. We often ask people to provide 3 sites they think project the values of their brand when doing website design work. 3 sites provides a bit of abstraction. No longer does a particular implementation have to be slavishly followed and no longer is it assumed that the thinking has been completed (by proxy).
Following exact designs and assuming that thinking has been done can be quite expensive mistakes. Exact designs reduce technical flexibility. Prematurely peddling into a technical corner and stepping through the process by proxy reduce the options to make a process work for a visitor from beginning to end.
The purpose of goal development is to enable a discussion that is not completely closed off. Technically what would the site builder be guessing at with the 'Facebook preferences specification. The first thought would be that the specification could mean a number of things and this is why the first step should be to have a discussion with the development team. Some people like to do preparatory thinking, and in this case some technical goals could be listed:
- Ease of use. The Facebook preferences page because 'inline editing' is nice. The preferences page should be easy to use.
- Safe. The inline editing also means that it is my perception that people will lose fewer changes while editing. Whether this is true or not, or whether 'safety of changes' in other preferences forms are matters of best practice.
These thoughts might be what the person was thinking, but at the end of the day it is a preferences form that has a function for people using the site.
Bring the Site Visitor In
Bringing the site visitor in allows for a discussion to be developed around important factors.
'Ease of use' is probably important, maybe you are providing a website for people who have a history of being scared of websites and it is critically important. 'Ease of use' is rarely the end game though.
A preferences form is to make it easy to change settings in some user process. The 'user process' is the important context. Site visitors might need to 'manage sharing privacy preferences' or 'customise profile so to ease recognition'. If the context isn't the same as Facebook's - and it won't be - then more thinking through the process is needed.
More likely goals are to make the site a pleasure to use to increase subscription or to increase take up of an online service to save costs and increase loyalty to the organisation. ecetra.
Discussion
What benefits are there to having a discussion with as broad a group as possible, including the technical team?
Technical accuracy. The best technical team has been selected to do the job (of course) and they were hired for technical wizardry and because they have built websites like this before. Technically they might point out that the Facebook preferences solution has been panned for years for lack of usability. A range of best practices that do a better job might be raised.
Experience. Similarly, the technical team may be able to look at your goals and use past experience to improve the workflow. We did this in a particular way in the past and found that this worked better, allowing experience to take iterations out of development and therefore produce a better product earlier and cheaper.
Existing tools. The framework supporting the development may already have a preferences panel tool. This may let you build the solution - better or worse - in 1/10th or 1/100th of the time and expense than trying to implement a specific framework. It is unlikely that the project has the development budget of Facebook - or its preferences page team.
Doesn't Work. The experience, particularly in big companies who can afford to attempt to 'shoot the lights out' is that an analyst sits in a room for 3 months - about 3 weeks before the site 'absolutely must be launched'. A large document, 100s of pages is produced to describe the solution. Maybe 'the business' had a couple of meetings for discussions at a high level. The program can be distilled down to something - perhaps we want to drive customer loyalty by sending their pets a birthday present. Oops - no pets are recorded in the marketing database let alone their pets birthdays so we need a campaign to get these details first. Technical development is an intellectual and social endeavour. If the technical people can't visualise the process working, it won't.
At least try to keep the development as simple as possible in the first instance so that you can test in the market quickly. We have in the past spent months perfecting a particular tool only to find that having the tool at all wasn't the best way to run the site.
It makes sense to have as broad a discussion as possible and keep it as open as possible in the initial stages. Sometimes politics and personalities prevent this - but personally it is a lot more exciting to produce something that is really does its job and perhaps in a different or innovative way.
Further traps: The Checklist
My website should have:
- A blog
- A wiki
- Inline spell checker
- FAQ engine - just like Stackoverflow
- etc.
Sometimes as web developers we take this approach too. People think they know what they are getting for their money and can tick off when they get it. Better still we can probably build it with the tick of a button and maybe a customised logo. Who knows, it might even cost us time if we had to get rid of it.
There can be a huge difference between turning on a tool and applying it to a specific user problem. 10x?
Keeping a Website simple - Targeting
The main problem with this approach is that while it can be imagined how fantastic a site would be if it combined everything in the New York Times with Facebook, Twitter, Stack-overflow and a banking website, using the checklist approach will probably end up with a site cluttered up with tools that don't make sense to visitors to the site. The car that Homer built. Many of the mentioned sites are effective and popular because they focus on solving a particular problem - answering questions, or sharing photos.
Cost. Providing all the tools might be cheap to setup but cost will probably become a factor at some point. The pieces should be connected together into a meaningful something at some point. At the least a forum will require some oversight, content areas updating and graphical areas refreshed. As experienced by the makers of Homer's car, the cost is likely to be too much.
Complexity. Can the purpose of all these tools be communicated to people?
Energy. Like the largest shopping centre in the world, having more may dissipate energy rather than build it. Someone looking at a site sees lots of unused parts they are likely to make a conclusion that the site doesn't have great energy. Building one piece at a time helps prevent this.
The better approach, again is to focus on goals and user needs and cut out anything that doesn't directly match these. Keep it simple and the ticking off tool approach isn't the most direct way to a popular and effective site.
Conclusion
A better and cheaper site can be developed by focusing on what visitors to the site do. This can keep the discussion open of particular implementations until ideas on how best to deliver can be gathered from as wide a group as possible. Inform the final design with 'what already exists' to save money and market test as early as possible as well as the whole groups experience of best practice and what has worked and what hasn't in the past.
in the end website building is a human endeavour and the shared understanding developed by going through an open discussion process will certainly help smooth development and probably in better spirits.