When the design is not user centerred...

I have to admit, I generally love Google's products. I am however often not impressed by their way of handling customer requests or the whole customer experience thing for that matter.

The last deception for me is this feature that now allows to do an undo after sending an email. I can relate to this feature because I have requested the ability for my sent email to sit in my outbox for some time (like you can do in Outlook for example).

From the point of view of listening to their customers they do well, it is easy to submit feature request or bugs.

But when I enabled this Labs feature I was up for a major deception. It was clear that they got it all wrong. In this case, the code mechanic and feature works:

1. I can effectively undo a send email
2. I can personalize (minimally: 5 or 30 seconds) the time is stays in my outbox.

Where it fails miserably is how the user interaction is done. It is so poor that the working feature is more or less useless.

When sending, I have to click on the "undo" link at the top of the screen but this is only there until I do another action. Since after hitting send I always do something else (I am not waiting 30 seconds staring at my screen to maybe think that I should not have hit send), the message disappear thus rendering the working feature useless.

What as gone wrong? Or, what could have happened to prevent this? (note that I am assuming that this is the implementation they choose to do to fulfill my feature request)

It is simple: Get someone involved on the development side at Google to validate the approach they were to take with the customer.

Doing so would have allowed them to:

Understand my goal

• I need the ability to cancel sending an email.

Understand my motivation

• I sometime use the wrong tone in an email, I get excited, I need time to cool down before I realize I may have said something the wrong way.

Understand my workflow

• I need the period to be longer than 5 or 30 seconds, I need 10 minutes.
• This above implies that I cannot rely on the last action "undo" link there is for everything else.

This is so simple that it is pathetic that they do not do it. This is something that is important and a lesson that we made a loooooong time ago at Macadamian: validate your understanding with your customers/users so you reduce the risk of mistake at the soonest possible time.

Now if someone at Google can read this an start interacting with their customers it would make my day.

Kanban collaboration nirvana?

I've been educating myself more and more lately on this Kanban buzz. For the neophytes, this is more or less the Toyota model applied to software development.

One thing that struck me is how it enforces collaboration. The cool thing is that I can relate to some of the inherent benefits when thinking of a project that I worked on a few years ago.

One thing Kanban ask you is to be lean. To be lean implies to have control over your queues. At Toyota it meant that the door maker guy would only start making new doors when the door installer guy would have only X left in his pile. How does that translate to software you ask?

Well it is simple. The number of stories accepted on the board are limited, the WIP (work in progress) is kept to a low number, similarly all the queues of your SDLC are kept to a small number too. There goes for the queues optimization theory, you can read more here.

However, these limitations on the queues size have an interesting side effect, and it is that it will promote collaboration over everything else. In a Kanban system a team member for example, is encouraged and might have to offer help to the QA team in order for them to free some room in their own queue, which will allow the dev to promote the new completed story to the QA stage. Similarly, a developer could also assist in the UCD (user centered design) activities if the bottleneck was found to be there.

Isn't this beautiful? I think so. This is something I recall doing at a small scale when I was project leader, I would find myself occasionally helping my QA team to reduce their queues.

At the time I did not know that much about Toyota nor Kanban, but it feels good today to see that I had such behaviors without really knowing much about some of their benefits.

Another side effect of this is the growing requirement for highly agile team members, team made of people that can do just about anything for the benefit of project... and the team!