Goals Versus Features and the Minimum Desirable Product

I was debating with a technical colleague yesterday about the best way to divide up the design and development effort for a website. It’s a guy I trust, like and respect and up until this point we’ve been fairly well aligned in our thinking and approach. Something was niggling me about the debate. I was sure that we were talking about same thing. but it was in the language that described our separate points of view where we seemed to differ. I jumped across the table (literally) to get to the white board to draw a picture and there was a moment of epiphany when we realised that we were talking about the same thing but using different words to describe it. It emphasised a few things for me:
Visual thinking is essential method of communicating. It’s only of the only ways to get a shared understanding across teams of difficult concepts. You need a thousand words to describe a picture, but a quick stick figure or shapes and we solved the problem in a tenth of the time that we had spent wrangling with words.

The need for common language when working on a team. Visual communication can facilitate shared understanding and once you have this it’s the next essential step is to establish a common language so that we know when we have the discussion in the future that we are talking about the same thing. This doesn’t need to be anything more robust that having a sheet of flip-chart paper which lists frequently confused terms or domain-specific language and calling out the definition. It will save a lot of people from feeling dumb or ignorant, especially those who don’t like to assume but don’t want to ask.
So in this instance the terms that were causing the confusion was Epics, Goals and Features. Each of these can be described as the high level units of business or user value that can comprise of lots of lower level detail (aka user stories/requirements). What we were violently agreeing about was that design is difficult at the micro level without first considering the macro level and the context of use.  However he was talking about features and I was talking about goals (and goal-driven design and development). They did boil down to the same abstract concept but the difference lies in the perceived value that each delivers and therefore the ability to prioritise what gets delivered in what order. The business could probably prioritise ‘features’ based on the level of return on their investment multiplied by time and effort to develop. However we need to ask what value do users attach to features because there’s little point in building features that are not going to be used by the end customer no matter how much the business thinks it might be used. There’s a statistic which came from a report produced by the Standish group which says ‘45% of features built are never used’ – which is an awful lot of time and effort wasted. So we want to make sure that we are building the right thing for the right people.
The way we solve this is not by thinking about features per se, but by thinking about goals. A mobile phone has features: it has a camera feature, a text feature, a web connectivity feature etc.

Customers/users however have goals that they want to achieve using the device or application. Customers want to take a picture to capture the moment and share it with family and friends. If we focus purely on the feature we can get hung up on making that feature great and foget the context of use, we can also limit our design thinking. Do we really need infinite mega pixels, a Carl Zeiss lens and photo-retouching that compares with industry heavyweight applications like Adobe Photoshop when actually we’re on a phone contract with a limited data package and we’re sending the image to Great Aunty Beris who has the most basic handset with a small and poor resolution display? Probably not.
By focussing on the goals that the user wants to achieve we can feel much more confident that we are building the right thing. It also means that we are in a much better position to consider the ‘minimum viable product’ and get it out quickly to market. To do this we take the user goal and ask ‘what is the minimum that we could deliver in the shortest period that would allow the user to achieve their goal?’ Granted not everyone is a fan of the minimum viable product but once we have this as a baseline we can then ask, is this enough to engage and delight our customers? If it is, great! We can get down to the business of development and get it out there quickly. If however the minimum viable product is not quite enough then we simply ask ‘what is the minimum that we could deliver in the shortest period that would allow the user to achieve their goal and engage and delight them?’ and we build delight into our minimum viable product.

24/7 web

Weird, i've had some interesting experiences lately when trying to go about my usual internet business. Finding that I can't get on sites that i would expect to be available 24/7...

This is from my supermarket, Tesco. I wanted to do my shopping online but they were a bit too busy, so instead shut the door in my face with this completely off-brand message. I did wait for it to be less busy, but i might think twice if it happened again.

A least Twitter was slightly more polite and on-brand about not being able to let me in and offers a live status view.

I would have thought that mega-brands like these would be able to flexibly scale for capacity?

Thinking of changing banks

HSBC have brought out these new security online security devices. It generates a random number which you use to log in and verify transactions. It makes everything a lot harder. A lot harder. But hey, it’s protecting everyone so I thought I could put up with it. So while there is truth in the fact that customers will put up with a certain amount of pain in exchange for some perception of value, when there is more pain than necessary it’s time to move on.
I needed to reimburse a a friend.

1. Go to internet banking and click logon
2. Enter Internet Banking number (12 characters/numbers allocated by the bank that I cannot remember and have to write down)
3. Enter answer to security question
4. Turn on secure key
5. Enter secure key PIN
6. Generate secure number
7. Enter secure number on screen
8. Go to main banking page
9. Select account
10. Click on pay a friend
11. Enter payee details (name, sort code, account number, payment amount, payment description, transaction date)
12. Turn on secure key
13. Enter secure key PIN
14. Press yellow button on secure key to get a dash
15. Enter last 4 digits of payees account number
16. Press yellow button on secure key to generate transaction number
17.  Enter transaction number on webform
18. Click continue
19. Go to new page and get error message because I put an apostrophe in payment description field
20. Go back to transaction form
21. Remove apostrophe
22. Turn on secure key
23. Enter secure key PIN
24. Press yellow button on secure key to get a dash
25. Enter last 4 digits of payees account number
26. Press yellow button on secure key to generate transaction number
27.  Enter transaction number on webform
28. Click continue
29. Confirm payment
30. Payment confirmed

Seriously? It would have been quicker and more satisfying to jump in the car and go to my friend’s house and pay her the £11!

Apart from the fact that the process is too damn long, what was really painful was the error experience. NOWHERE on that form did it say that you could not use special characters, not even in the pop-up help. That would have been the polite thing to do. The other helpful thing to do would have been some client-side validation that checked for special characters BEFORE I submitted the form. How hard can it be?
Off to find a new bank.