Month: December 2010

Don’t be evil (product designers)

Posted on by will

Today, for the first time in what seems like ages, my PC caught the flu. This time it was a particularly annoying piece of malware called HDD Low; one of those fake system config utilities that spams you with fake warnings about your hard drive or memory until you give in and buy their special ‘system optimiser’ software that removes the alerts.

I Googled for some assistance, and ended up on a website for a product called Trojan Killer. This site is clean and well laid out and free of advertising. It offers detailed information about the virus and some instructions on how to remove it. It offers two options: instructions to remove it manually, or a free trial version of their Trojan Killer software.

Let’s examine the scenario so far: a clean and modern looking website with no advertising builds trust in the site and in the company (normally ‘bad’ sites have lots of ads and just look unprofessional). The transparency of offering manual removal steps as well as the software install further builds trust (they don’t need me to download their software, so I assume the software is ‘clean’.) I am now at the point where I trust them enough to download and install their software.

I downloaded and installed the free Trojan Killer app, and after a normal install process the app fired up and started an initial scan. After about 30 minutes of scanning it not surprisingly found our friend HDD Low and also a couple of other little things. It presented me a list of 10 or so infected files, with a big red button to ‘Clean infections’. I clicked it…

… and was hit with the credit card details page. SNAP! Now, after 45 minutes of trying to remove this virus, I have two choices: cough up and pay money to buy this app, or go back to the drawing board.

This is a very ‘good’ example of consciously evil product design. The flow from discovery to installation of the software is designed to build your trust with transparancy and professionalism to encourage you to download the ‘free trial’ version which is not really free at all. It tricks you into investing your time letting it scan your computer and then it makes you nervous about the viruses and ‘suspicious’ software it finds. But a solution is only one click away! The ‘remove’ button is even there, ready to be clicked – but first, you just need to enter your credit card details…

Their methodology is simple:

Trust + Nervousness + Time investment = (evil) sale

For me, at least, tricks like this don’t work: I trust this application and this company far less now, and I am far less inclined to hand my credit card details over to them – but I have to wonder how many people fall into this trap.

Treat your customers fairly. Don’t use false offers to trick them into downloading your software. Be honest about what your ‘free trial’ does: if it has the capability to scan the computer but not remove the errors, that’s fine, but tell the customer before they download it. Sure, you might make a few sales with scams like these; but how many of those sales are likely to grow into valuable, long-term relationships?

Being open and honest will always pay off in the long run.

(By the way, I managed to remove HDD Low without installing anything (else). Instructions are here.)

How to remove HDD Low malware without paying for Anti-Spyware software or installing anything

Posted on by will

For the first time in what seems like ages I somehow managed to catch a virus… this time a very annoying one called HDD Low. It’s one of those fake system optimisation utilities that keeps spamming you with false alerts about your system (low memory, hard drive error, etc) until you give in and buy their fake ‘repair’ software to fix the problem. This one was even almost convincing… the first screen had me almost convinced it was a genuine Windows alert.

The good news is that it’s pretty easy to get rid of, and you don’t have to install any extra anti-spyware software or pay anyone anything. Here’s what you need to do:

1. Press Control-Alt-Delete to get to your Task Manager. Open it up and kill the HDD Low processes. They won’t be labelled ‘HDD Low’ – they will be labelled with a random string of letters and numbers. If you’re not sure, just kill any processes that look suspicious. I found that one of the HDD Low processes kept re-opening itself directly after I killed it – but if you kill it again as soon as it pops back into the process list, it is gone for good.

a) If Task Manager isn’t visible in the list when you press Control-Alt-Delete, try restarting your computer. HDD Low will start again automatically, but Task Manager should be visible now.

2. That should have taken care of the pop-up messages that keep annoying you. If you are still seeing pop-up messages, or if the HDD Low Icon is still visible in the task bar, then the processes aren’t dead yet… go back to Task Manager and try again.

Now you need to remove the registry entries to stop it coming back again. Go to Start –> Run, and type regedit. You’re now looking at the registry editor. Be careful! If you remove the wrong registry keys from here your programs or Windows may stop working. Navigate using the tree to the Run folder: HKCUSoftwareMicrosoftWindowsCurrentVersionRun

This folder specifies what should run when windows starts. There will be (at least) two registry keys that look like random numbers, and the entry in the ‘value’ column will link back to a folder in your User Data’s temporary folder (something like: C:UsersYour_UsernameAppDataLocalTemp47456096.exe). Delete these registry keys.

3. The hard part’s done. Now you just need to clean up the files HDD Low leaves lying around. First remove the application files from your Temp directory: C:UsersYour_UsernameAppDataLocalTemp47456096.exe. Again, the file will be a random string of numbers or letters. Remove anything that looks suspicious. Then remove the Application shortcut from your desktop, and you’re done!

I hope this helped!

Analytics, data and product innovation

Posted on by will

It’s important to understand what your users do, how they use your product… but remember: data never paints the whole picture. User research, user testing, usability studies, behavioural analysis, usage statistice: it’s all important – understanding and making sense of this data is crucial for your product’s development – but this data doesn’t exist in a vacuum, and it’s not enough to (alone) drive a product.

An example: The first iMac was released in 1998 and apart from looking really funny it was the first personal computer sold by default without a floppy disk drive. There wasn’t even a place to build one in… you had to buy an external one and connect it with a usb cable. It caused an uproar – analysts and journalists called them crazy – you can’t ship a computer without a floppy disk drive!

When was the last time you even saw a floppy disk?

If apple had have run a survey with all their customers before releasing the iMac and asked the question: “would you expect a new computer to have a floppy disk drive?”, I’ll bet most of their respondants would have said ‘yes’. But product and market innovation doesn’t happen through user surveys or focus groups, and it doesn’t happen through analytics… It comes from visionaries who challenge expectations.

I had a similar conversation with a colleague recently as we were discussing including a new feature in maps.ovi.com. A couple of days after the discussion he came back to me and said: “we checked the application logs and site analytics, and we see very few instances of user behaviour that indicates that people want that feature, so we conclude that it’s a not feature that people want.”

Well of course there are not many instances of this behaviour in the logs. If your product interface doesn’t support a particular functionality (that is, if you don’t tell your users about it), how should they know to try it? And if someone did think to try it, and it doesn’t work, how many times would they try before they gave up?

User analytics is extremely important for optimisation and product evolution, but don’t confuse optimisation with innovation. Innovation is something else. Innovation challenges the analytics; it challenges the market, it challenges expectations and it challenges users themselves.

Do you innovate or optimise? To be remarkable, I think you need to do both.

Better scrum user stories: save the solution for the spec

Posted on by will

In the world of Scrum the user stories are at the heart of everything that’s added to the software: it’s how you break down the product strategy and requirements into discreet, develop-able chunks. We build software for our users, so it makes sense that everything that’s added to or taken away from the software is expressed in terms of a user need.

The Scrum textbook recommends the following standard form for a user story:

– As a user, I want to do {thing} so that I {reason}.

The trick is to focus the story on what the user really wants, not how you plan to solve that need. You need to keep the solution out of the story.

A couple of examples:

“As a user, I want to see my favourite places in a list so that I can find the one I am looking for.”

What’s wrong with this story? It is not a story about a user need; it is a specification for a solution. Does a user really want to see their favourite places in a list? Or do they just want to see their favourites? Is a list the only way to solve this need?

How about: “As a user, I want to find the favourite place that I’m looking for, so I can see information about it.”

Another example:

“As a user, I want to see Public Transport lines on the map.”

Do they? Or do they want to know where Public Transport lines run? Is putting them on the map the only way to do that?

How about: “As a user, I want to understand where Public Transport stops are in my city, so I know where to go to get the next train.”

Why is it important to keep the solution out of the story?

The User story represents the problem that the user wants to solve, to which you and your team need to find a solution. The steps to finding a solution are understanding the problem, brainstorming/investigating possible solutions, possibly in conjunction with benchmarking of competitor products and user research, then selecting a solution and specifying how that solution will work. When the solution is already embedded in the story, you spring over the first two steps, which not only means that you’re not looking at the problem broadly enough, and you will potentially miss good, new or innovative ways to solve the problem, but you’ll have no data to justify that the solution you chose was better than any other.

Write stories that focus on needs, and save the solution for the specification.

A good scrum sprint demo

Posted on by will

The Sprint Demo is one of the most important meetings on the sprint calendar. So why are so many sprint demos so poor?

Firstly, why is the Sprint Demo so important? I think for several reasons:

  • It makes the progress (or, where applicable, lack thereof) of the team transparent (to management, to other teams, to themselves…).
  • It gives the team an opportunity to show what they have achieved and a forum to celebrate their accomplishments.
  • Ticking things off a list is fun!

I’ve had to sit through many exceedingly poor sprint demos, most of which could have easily been far better. Here are a few points or tips that I think can help get the most out of a sprint demo.

  • There should be an agenda. If you are demoing with multiple scrum teams at once, it should be clear in what order the teams are demoing. Each team should also have an agenda of which stories from the sprint backlog will be demoed.
  • There should be a demo computer in the demo room with an agreed and consistent configuration which connected to a demo environment. What is not able to be demoed on the demo computer isn’t demoed – this means no demoing from the developer’s local computer or any other temporary test environments. (Note: the demo computer configuration should ideally match one of your key users.)
  • The Product Owner should accept a story as done in the demo, or return it to development (ie, to the product backlog).
  • The Product Owner should remember to provide a bit of background to each story as its being demoed – specifically, what the business value for the story is, what problem the story is solving, what benefit there will be, and so on.
  • All issues discussed in the demo should be recorded and transferred to either the product backlog or to the bug tracking system. Some teams might like to appoint someone to be the meeting scribe, or the QA people may enter new defects raised directly into the bug system.
  • Stories should have passed a certain agreed defintion of ‘done’ before they are eligible to be presented.
  • Never cancel the demo. If the team has no stories to show, then display no stories at the demo – but never cancel it. Canceling the demo sets a bad signal to the team that demos aren’t important.
  • There shouldn’t be any surprises in the demo, and teams should prepare adequately for the demo if they want it to be a good one.

The demo is the chance to shine and celebrate for you and your team… make it count!

Seek understanding – not insurance

Posted on by will

When you communicate, you have two responsibilities:
1. communicate your message
2. ensure the message is understood

#1 is easy – but it is #2 that counts.

You can do #1 and forget or skip #2 – but you haven’t really communicated. Saying words out loud is not communication – it’s just making noise. Communication implies an understanding from both the initiator and receiver of the communication.

You can also do #1 in such a way to make sure that #2 doesn’t happen – that’s called covering your arse.

Be delightful

Posted on by will

Every interaction with a customer is an opportunity to surprise and delight them.

Two great examples of this have stood out to me in the last week.

Amazon.com

I’m a shockingly frequent Amazon shopper. There are so many things that I used to go to the shopping centre for that I now order from the comfort of my couch. Normally the stuff I order turns up at my house without a hitch, but this week (admittedly for the first time ever), a package went missing.

It took me a while to find the right email address to write to, but I found a link under the support section for enquiries about missing deliveries. I wrote a careful email describing exactly what the problem was, and I took special care to explain that I had looked at the delivery tracker and the package was listed as “undeliverable”. After an instant auto-responder mail, two days later I got a canned response back that politely asked me to check the delivery tracker if I wanted to see the status of my delivery…

The point is, it was quite clear that the person dealing with my inquiry didn’t really take the time to read my email properly or understand my situation, or else they wouldn’t have asked me to check the delivery tracker again, when it was clear that I had already done so, and that was the reason I was contacting them in the first place.

WordPress.com

I had a bit of a silly blunder and purchased an upgrade from wordpress.com for the wrong blog. In wordpress you need to purchase upgrades for a particular blog you own, and somehow I bought it for the wrong one.

I emailed support and told them what happened, but I didn’t really expect much in the way of support. To my surprise, less than 30 minutes later I got a response from a real person, who told me he had simply switched the upgrade to the right blog, and that was that. Then he signed with his first name, which I thought was a nice, personal touch.

I was astounded, surprised – and absolutely delighted.

As a user, which of these two experiences am I likely to tell my friends about? Well, both of them actually…

Every interaction with a customer or user is an opportunity to delight them. You don’t get many opportunities… opportunities are difficult and expensive to get, and users are becoming increasingly more fickle and the number of other options is ever-increasing… so don’t you want to make the most of each and every opportunity you have?