Piers Jones

A summary of User Experience in 2009

For those interested in Product Development and User Experience, this is a good summary of how User Experience design has evolved from the Information Architect, Jesse James Garret. 

Its quite a long video and quite heavy on theory but worth the effort if you have half an hour to set aside.

Jesse James Garrett | UX Week 2009 | Adaptive Path from Adaptive Path on Vimeo.

Talking to users of your product

It goes without saying that the more people that you talk to that actually use your product, the closer you are going to get to understanding what they need. Then you stand some kind of chance of delivering a product that actually meets those needs. However its very easy to forget to do that as often as you should and get wrapped up in the process of delivering products instead.

In my experience as a Product Manager to date I've found a variety of ways of taking feedback from users in order to improve the quality of what is delivered. There are times when pouring over web stats or undertaking formal usability testing is exactly what is called for. Sometimes though its just good to get out of the office and go and talk to people.

Today I tried out a new and very easy way of gathering product insight by using some software called Silverbackapp. I had know about this software for a while but never actually used it in the wild so to speak.

Its very very simple, you can talk to website users and as you have a conversation with them the software records the on-screen activity as well as filming a video of people's reaction to the product. This all plays back in a video at the end.

With the expert help of Martin Belam - we recorded quite a number of sessions today from website users. I hope the results will help us design some improvements to the product we were discussing based on those insights. I would recommend silverback app to anyone wanting to try more informal testing of their product - as well as recommending that getting out from behind your desk and talking to real customers is a really worthwhile thing to do for anyone in product development. You learn a great deal for free, just by asking.

Here's a video explaining silverbackapp in more detail:

Essential strategies for creating a successful web product from Dion Hinchcliffe

There is some excellent advice from Dion Hinchcliffe in this article outlining '50 essential strategies for creating a successful web 2.0 product'

Although web 2.0 is mentioned in the title I think these ideas could apply to most online products, especially "start by solving a simple problem".

I have a feeling that this is one of those reference articles that I may have to come back to from time to time. Its a great checklist.

Simple ideas work best - number 1

3 simple ideas that I have seen lately that have really impressed me;

• Having white roofs and lighter colour pavements could help reduce global warming
• A great simple tool for working out whether a website is down for everyone or just me? (via Lloyd Davis on Twitter)

• Probably the most successful idea from tv series dragon's den is a plastic cable tie, that just got a £36m order

Yep, the simple ones are the best.....

U.A.Tea

my own tea pot and cup, originally uploaded by perago89.

We introduced a new user testing session on our jobs service this sprint called U.A.Tea, it's just like U.A.T (User Acceptance Testing) but with tea and cake.

The tea and cake bit definitely worked to get more people along. We received some really helpful input prior to release of the product and it helps the team catch changes early in the process, or at least before we release the product to live.

Signposting your direction with a product roadmap

Directions mosaic, originally uploaded by robynejay.

I have just spent the past few days producing a visual product roadmap for the web service that I am a Product Manager for. There is some debate as to whether you need a roadmap at all but I find them very valuable for the following reasons:

1) They build consensus. Agile development is team based and it helps if all the members of that team are headed in roughly the same direction. A roadmap is a reference point for all the team.

2) They are visual. My roadmaps start with the current situation in the left hand corner and the stated vision for the product in the top right hand corner. Each new feature is then plotted onto the roadmap showing progression against a given theme eg. improved search. Dates are not included as they are bound to change, it's the direction towards a stated aim that is important here.

3) They are iterative and allow for change. A good roadmap is flexible and achievable in small steps.

4) They communicate the long term / strategic vision for a product. Its very easy to get stuck in the day to day and forget to focus on the overall direction, as new ideas emerge you can then plot whether they fit with the overall plan and then decide whether its the plan that needs to change or the request for the new feature.

Our roadmap is now pinned to the team planning board and I hope will be a reference and discussion point as we move forward.

UPDATE: A really clear case argued here by Tyner Blain on why you need a smart product roadmap 

 

Benchmarking your product against a competitor

Having just returned to the world of product management very recently I have been spending time getting up to speed with my new product.

Something that has struck me in the first week is the focus that the team have to deliver a product that compares favourably to a key competitor.

37 signals were right when they said that you should have an enemy.

So I'm spending time this week on benchmarking metrics and tools which will allow us to track our progress as the year progresses. A bit of healthy competition can be a good thing.

Planning poker

Planning poker cards, originally uploaded by tlaukkanen.

After a recent course on agile development I learnt how to play the game of planning poker. Since being back at the office I have used it in a couple of product planning sessions and found it to be really useful.

The principal of the game is that in any group of people you will have difference of opinion as to how important a new product feature is or how complex it might be to build. This is where poker comes in to help you gain consensus during estimation.

Each player takes a set of cards with a series of numbers on it (based on fibonacci). The person taking the meeting would then read out the summary of the new product feature that is being suggested. Maybe in the form of a user story.

Each member of the group then picks the value that they'd like to assign to the idea without showing the rest of the group. So you might pick a 100 say if its really really important (if you are assigning  business value) or an 8 if its somewhere in the middle. 

The group then turns over their cards at the same time. At this point you will usually find that someone has given the idea a high value, another less so. This is everyone's opportunity to discuss why there is a difference in their scores. It's the conversation at this point that I have found the most valuable. Planning poker is a great way of getting a very detailed opinion from everyone in the group.

The aim of the game is to keep up the discussion until you play again and everyone has agreed the same score for the idea / feature / backlog item. Then you can move onto the next.

This is one of the more useful and fun tools that I've used in product development for a while. If you haven't tried it I would suggest getting a pack of cards and giving it a go, or playing online at planningpoker.com