Monday, August 02, 2010

Build a Bridge, not a Pier

I once had a meeting with a potential customer that caused me to pause and think about why they really needed my services. Yes, I did my usual user expectations pitch and expected the usual feedback, but a few things came up in the meeting that were a little out of the ordinary for me - and perhaps for them - because until then I believe that neither of us had noticed the big elephant in the room.

The big elephant I speak of is something I haven't seen since the dot com boom and bust days, and that was the old idea of technology for technologies sake.

Yes, they had a product, they had customers and they had a development program that was working on a number of technically brilliant additions to their core product, but they didn't seem to have looked deeply enough at the way the customers actually used their product. There were several reasons for this, but none should have stopped them from seeing what I saw within the first hour of our initial meeting.

So, after talking with the developers and scientists working on the project I found myself wondering if they saw the glaring omission in their product offering the way I did, and should I tell them about it? As I said, I'd only been in their office an hour and although confident in my work experience I was across the room from some pretty impressive scientists and software developers doing pretty bleeding edge work.

On the plus side for me was the knowledge that here was a "meaty" protect I could really add value to. On the negative side, would these guys "get it" enough to do the proverbial "of course" with the accompanying smack to the forehead with the open palm, or would they be offended without getting it, like Nigel talking about going up to "11" in Spinal Tap.

How do you move forward on this - these guys are brilliant in what they do, but they had only really built half a product. They had built a pier, not a bridge.

The metaphor goes like this. Let's say you have a stretch of water that you need to provide a method of moving people and goods from one side to the other. If you build a pier for boats to use you are providing only half of the solution. You still need a boat and another pier on the other side of the watery divide to unload your passengers and goods. You still need a method for the people to move around on the other side of the water and you need a method of handling the goods on both piers.

Yes, you have provided a solution, and probably a cost-effective one at that, but you have also only lessened the barrier to the users of the ferry service getting to the other side of that stretch of water. You have provided an enabling solution but you have also inbuilt into that solution choke points that will still stop some people from using it; people who get seasick for instance.

So perhaps you build a ferry instead? People get to stay in their cars but it can only operate at set times of the day and only when the weather conditions are calm. It doesn't solve the seasick passengers choke point though.

The real solution is a bridge. It is the most expensive option for sure, but it is also the best enabler to the users. Ask any Mayor what their constituents would prefer - a pier, a ferry or a bridge and the bridge wins every time. It is the solution with the least friction.

Going back to my potential new customer. You may have gathered from the monologue so far that they actually have built a pier. They have provided only half the solution - they have allowed the technology to overshadow the task. They have built a mighty pier with all the bells and whistles and don't seem to be as worried about how their customers are going to get to the other side as I am. Their customers actually complete their tasks outside their software; there is a disconnect between what the software achieves and how it is used by the customer.

Don't get me wrong, it is a beautiful pier that does exactly what they want it to. I was very impressed in what it does and as a user interface designer I had some simple ways of improving its current form.

But it is as a user experience designer that I could help them improve their work and marketability. I could help them turn their pier into a bridge by helping them to design the choke points out of their products. I could help them provide the total solution for their customers, and hide the complex technology interfaces so that the customer only has to deal with what they need to know about and use on a daily basis.

A user experience designer can help them build a product that allows their users to start and complete their trip across that "watery divide" using software that is simple, intuitive and provides a total solution, not just a partial enabler.