In order to better integrate my blog with my website, better manage comment spam, and reduce my dependence on Google, this blog has moved to In order to avoid broken links I won't be deleting content from here, but no new content will be added, so please update your bookmarks and feeds.

Tuesday 11 September 2007

You don't have to meet everyone's needs all of the time

Andy Neale
Had handout for 50 people but a couple hundred people there...

Idea of maximising user satisfaction against resources. Really complicated/expensive solutions can be done but not priorities.

Find focus - narrow in on what trying to achieve.
Find key users - make the majority happy first. Eg Papers Past 48% were family historians. If make them happy, that's half already and probably helps make other users happy too. Could also choose to focus on minority as a growth market - but majority better start.

Ladder of progression: browsers -> searchers -> researchers. Use as model of user motivations etc. Start with user research you already have to understand motivations. Individual interviews with target users to get into head, work out what they're trying to achieve.

Focus on important features - the fewer features created the more resources to focus on each. Happy User Peak - point at which don't need to add features, because after this slowly gets too complicated and users start getting confused, etc.

Don't listen to everyone. If various people say "green", "blue", "pink", "orange" and you try to mix them all - you just get mud.

Nielsen says "Don't listen to anyone". If you ask people what they want they'll say something but it mightn't be true. Instead observe -> usability testing. Neale very keen on comparative usability studies. Run tests on other peoples' websites. (cf handout) Lets you narrow down features you want to implement before you've even implemented them.

Build capabilities.

  • 37 signals developed Ruby on Rails. Suggest starting with visual design first and programming second. (Book online.)
  • Agile development - over time the cost of implementing changes and fixing bugs increases. Catch them early reduces cost.
  • Use design patterns - documented solutions to known problems. Other people have done anything you're likely to do - copy them instead of reinventing the wheel. Yahoo has design pattern library released.
  • Use third party aplications - let other people build your applications. Many mega-companies building functions, why should we rebuild them instead of piggybacking/reusing? Many factors but things we should be looking into.

    • flickr - if Matapihi didn't exist, why not use flickr instead of building and maintaining new services? (Not suggesting getting rid of existing services though.)
    • Google Coop - custom search lets you refine google results to create own search engine. Only works for content already exposed to Google. Neale has played with some NatLib sights to simulate federated search. Particularly interesting now WorldCat's up. (National Library of NZ collections) Papers Past online 10 days ago, already indexed by Google.

Narrow in on core user needs and what people will be satisfied with. Simple, cheap solution may meet 60-70% of need. Lets you spend other resources on more advanced needs. Not necessarily final goal but good start and worthwhile.

Source urls: (I don't know what this is as haven't had time to follow it...)