marc, Author at dancingmango - Marc McNeill

Are you being told the truth?

Thursday, 25 January, 2007
By: marc

I’ve spent the last two weeks listening to users, understanding their requirements, drawing boxes and arrows, swim lanes and all that good stuff to show process flows. But is what they say the whole truth?

When we are doing analysis we are building our own mental model of the work, and potential solutions to problems we are hearing. But unless we can see what is going on, how grounded in reality will our solutions be? Anyone who has sat in on focus groups and observed consumer reality will know that what people say and what they do are often at odds with each other.

Finally this morning I had access to the users in their “real” environment. The user sat at his desk in front of his monitors and I sat slightly behind and aside him, watching over his shoulder what he did. Half an hour’s observation brought the boxes and arrows to life. More importantly, it highlighted how long he spent on each task, and the need for efficiency in the interface we are developing.

In a workshop he can ask for stuff, but when you see him working it is clear that that stuff would just clutter and get in the way of him accomplishing his goals.

Most striking is what is left out of the process discussions. Sometimes we forget about those things that are so obvious, so mundane. We assume that they just happen. Only by observing can you get a real feel for the requirements (and also how they should be prioritised).

So go on, take a half an hour break from your development activities and go and watch the users working “in the field”. You never know, you might just learn something.

Is yours a free coffee organisation?

Monday, 22 January, 2007
By: marc

What kind of employee experience do you have? A good customer experience is going to be an extension of a good employee experience. If I feel good about my employer, I am more likely to be a brand ambassador for them. So how do you improve my employee experience? Well there’s all the usual stuff, benefits and bonusses, but the little things are just important. Like the coffee machine.

There seem to be six different approaches to enterprise coffee:

1. Vending machine that serves [quality] coffee on free vend.

2. Kettle and filter coffee / Cafetiere to make my own.

These two make me feel good about the organisation

3. Kettle. I buy my own instant coffee. Usually associated with SMEs rather than corporates.

Not so good. but better than…

4. Vending machine that serves [quality] coffee that I have to pay for.

I have never seen this. Organisations who know coffee don’t charge their people for it. These vending machines are always on free vend. As in above photo.

5. Vending machine that serves [tasteless] cofee that I insert coins into.

6. Vending machine that serves [tasteless] coffee that I insert a vending card into.

This final one insults me as an employee. I’ve got to “charge” my card up. I’ve got to get a card. My coffee consumption can be tracked. More often than not the same machine serves water (because these organisations don’t have water coolers). And the water tastes like tea that tastes like soup that tastes like hot chocolate that tastes like every other concetrated liquid that is squirted into a brown plastic cup.
How much more can it cost to offer free coffee? How much are you saving by doing so? Because tasteless vending machine coffee is a sure way to send your staff out of the office on regular errands to Starbucks.

Fobidden!

Thursday, 18 January, 2007
By: marc

Apparently my website is not accesible in China. I can only think this is because of content I wrote about Tibet, and most likely links to external Tibetan websites. Once on a restricted list it is probably impossible to come off it. But it does pose the question, should I remove content from my site, effectively censoring myself (like Google)? Or should I continue to deny a large potential audience of my words of wisdom?!

What is your UI debt?

Monday, 15 January, 2007
By: marc

When developers are up against tight deadlines they introduce the concept of “technical debt”. It is a short cut to delivery; quick and dirty code that will have to be refactored (or fixed) at a later date. Inevitably they will pay the price in the future if this is not done.

So why does no one talk about “UI debt?” When projects are up against tight deadlines and scissors are applied to scope, the first thing that the team will look to cutting are any UI “bells and whistles”. They don’t talk about UI debt – we’ll have to refactor (or fix) the UI at a later date. Yet the price to be paid for UI debt will inevitably be far greater than any technical debt. If the UI is hard to use, and satisfies the technical functionality, not user goals, the users are more likely to shun the software. And isn’t the object of software for people to use it?

Is your IT department like the NHS?

Thursday, 11 January, 2007
By: marc

Can Gerry Robinson Fix The NHS? has been compelling TV viewing the last few nights. The thing that really comes across is the lethargy and the inablility to take responsibility to get things done. The two messages that resonate with me are listen to people on the ground and “just do it”. CEOs may chuckle at such incompetence in the public sector but how often are these issues manifest in the corporate world, and in IT organisations in particular. IT is full of reasons why not:

“You may be able to do xyz in Ruby on Rails, and it may only take you two weeks to complete (compared to the six month project we’d take to do it) but we just don’t (and won’t) support anything that’s not on our architecture roadmap…”

“You can’t do abc until we’ve completed our infrastructure refresh project.”

And how often is interviewing / listening to end users on an IT project plan?

Consumer driven development

Wednesday, 10 January, 2007
By: marc

One of the things that makes me passionate about agile is the way that it places the customer at the heart of everything we do. The trouble is “the customer” is often wrong. For me, the customer is the person whose life is transformed by the software they use. This is not the person who is writing the cheque, nor is it the person who is defining the requirement. In consultancy speak, they are the client. The “users” are the customer. I don’t like the use of the word “user” because it implies a choice to use the software has already been made. I’m probably going to have to accept that “customer” is never going to change, so why don’t we call our users (my customers) “consumers”.

So enough about semantics. The team are building an on-line banking product. The team ask the customer (client) what she wants. She bases her requirement around what she knows. Often this will be swayed by the development team talking about implementation detail. (Few things make me as uncomfortable as a customer (client) from the business (product owner) talking about APIs).

So the requirement is to log-in. The customer is comfortable with customers (consumers) having system IDs; a unique n digit number that identifies the customer on the legacy database. It has, after all, always been this way. She asks whether the customer’s credit card number could be used, but the developers tell her (via the BA) that these often change (customers loose their cards) and it would be hard to do. She nods her head in agreement (she’s put on the spot by the BA – the iteration is due to start next week…) And the requirement is manifest on the login screen (“please enter your 16 digit customer number”).

In reality, the “customer” bases the requirement on her experience with the organisation and what she knows about it. The consumer (if they were to be invited into the conversation) wouldn’t come to the problem with any of that baggage. She needs a simple login. She needs a user name that is accessible or memorable. She does not want a 16 digit number.

It may take a little longer to listen to the consumers’ need (we need to find consumers to talk to them). It may mean a little up front analysis (I’d suggest pre-project analysis, doing due-diligence if you like). But it will pay dividends downstream. In the login example above, the developers have swayed a simple and cost-effective solution in the short term, but have failed to consider the down-stream costs. How will the customer find their 16 digit number? Do we have to post it out (cost) on a card (cost) and have a support team (cost) and process (cost) for letting customers know their number if they’ve forgotten it?

As agile grows up, I’d ask for us to spend more time thinking about the real customer, the consumer, the person whose life will be changed by what we build. The inconvenience we may incur during development may be nothing compared to the pain we will experience after we have “delivered”.

Nokia and their charger

Tuesday, 9 January, 2007
By: marc

There once was a time that you could go to any office in the world and be able to charge your Nokia phone. Every Nokia phone used the same charger. A small and insignificant thing, yet this small detail in the technical implementation was undoubtedly important in maintaining brand loyalty and the dominance of Nokia in the market place. Nokia built informal communities in workplaces that no other brand did. Communities that shared their chargers. I’ve not witnessed that with other brands.

Then something happened at Nokia. They changed the charger. The plug is now smaller. I presume this can only be down to the ever decreasing size of their phones. But my new Nokia N80 is bigger than my old Nokia that used the old charger. Bottom line? There are half a dozen old style chargers lying around in the office. There are no new ones around. I leave mine at home / it is broken, and combined with the risibly short battery life of the N80, I am stuffed. This will impact my purchasing decision when I change phones. I’ve been loyal to Nokia since I got my first mobile almost ten years ago. No more.

(As a postscript, I recently found myself with three other unlucky souls who owned a Nokia N80. Not one of us had a good thing to say about it. If you are in the market for a new phone, steer clear of the N80. Buy one at your peril!)

Storyboarding with comics

Monday, 8 January, 2007
By: marc

Storyboarding is a really powerful way of communicating how a tool will work. The Sun design team have put together some cartoons that can be used for presenting storyboards; for example taking a bunch of wireframes and using the cartoons to tell the story through them. The cartoons are in powerpoint here. I’m looking forward to using these, to ditching the dry persona description and annotations and replacing them with a more compelling cartoon journey…

Early Learning Centre fail to deliver

Monday, 8 January, 2007
By: marc

Last year I wrote about Early Learning Centre and how impressed I was with their revamped web site. It was recently picked up by About Customer Relations: The New Competitive Edge. Whilst I stand by my comments about the site itself being well designed, the rest of the experience leaves a lot to be desired.

In the summer I bought a product on their website – the product that was delivered was not the same that was ordered. They succeeded in repeating the mistake twice, delivering two toy pushchairs before the pram finally arrived. With no present arriving on time we had to postpone our daughter’s birthday for a day whilst we waited for her birthday present to arrive.

I probably should have learnt from this experience. I didn’t and on 11th December I ordered toys on their website for my daughters and their cousins. The on-line shopping experience was faultless, I received a confirmatory email and the following day, on the 12th I received the following note:

We’re pleased to let you know that the following items from your order of 11 December 2006 have been despatched from the Early Learning Centre warehouse… You can expect your toys by Wednesday 20th December.

That was great, managing my expectations, keeping me informed. Only on Thursday 21st December no delivery arrived at my address. We rang their number and were informed that the delivery would be made, the order would be with us by Christmas. That was a promise.

Friday 22nd and still nothing. I was getting worried, I could postpone my daughter’s birthday, but postponing Christmas because of ELC’s incompetence was not on the cards. I got through to the call centre and was told that sorry, the delivery had not left the couriers warehouse, and would not go out before Christmas. The call centre representative said he’d phone local stores and see if the toys I’d ordered would be available for pick-up. I was put on hold as he rang a local store. All sold out. I suggested another store and was put on hold again. After fifteen minutes on hold I gave up and rang back. This time I was told that the courier firm would be making deliveries on the Saturday morning and I could expect my order to arrive first thing in time for Christmas.

Saturday morning and no delivery. I rang the call centre again. The representative I spoke to said that she couldn’t tell me whether the delivery would be made. I put the phone down. I rang back again and asked to speak to a manager. “Sorry, all our managers are in a meeting” came the response. This was not good enough. I asked for a manager to ring me back when they came out of the meeting. I’m still waiting for a call.

A little later on, the parcel arrived, in time for Christmas, but not in time for me to have anything good to say about ELC’s ability to execute on their web promise.

Central to my experience was a breakdown in communication. The call centre had access to the courier firm’s tracking website (that they wouldn’t share with me), but seemed to have no way to talk to someone on the ground to find out why my gifts were not put on a van before the date they’d promised in the email. I don’t care that the courier company let them down. For me, the courier is ELC. In the call centre it was clear that they’d brought in extra people to handle the Christmas rush. These people probably had a bare minimum of training and were not able to handle queries from disgruntled customers in a consistent way.

The lesson learned here is that having a good website is just part of the total customer experience. You may have the right products at the right price, easily found and simply paid for. My web experience may end with me parting with my credit card details and receiving a confirmation e-mail. But I’m not satisfied until the right goods arrive at my home and they meet my expectations based upon promises made on the website. At any stage of the whole process I expect a consistent and excellent experience. Anything less and I won’t return. Worse, I’ll tell others how bad my experience was.

WWW. Why. Why. Why.

Friday, 5 January, 2007
By: marc

The www prefix is redundant. Technically, and now, given the ubiquitous nature of the web, in marketing as well. So why do companies insist on retaining it. Worse, why do some companies have URLs that only work with the www.? This is sloppy, a couple of lines of code would direct either company.com or www.company.com to the correct IP address. There are some big names who suffer from this sloppiness. Will ’07 be the year that WWW, an acronym that takes longer to say than to write, drifts into history?