2008

The scourge of Document Driven Design

Documents, or rather words are the scourge of product design. Because words can never convey the true meaning or emotion of what is really required. All to often, software development projects are driven by the documentation – agile projects can be equally guilty of this- driven by words on paper (or card) that convey what the requirement is. Issue #1. Developers don’t read!

Except for a few exceptions, software is all about a user interacting with a system in order to accomplish a goal. Trying to describe that premise in terms of features and functionality is fundamentally flawed as it will be nested in the language of technical implementation, not in the user interaction. “Find” becomes “search”, “buy” becomes “shopping cart”, “check” becomes “validation” and so on. Issue #2. The desired outcomes become lost in a smog of technical jargon.

Solution: Picture Driven Design. Up front. Yeah! I’m all for up front design! A picture tells a thousand words. It has the power to remove ambiguities, clarify the vision, showing what the journey to realise outcomes look like. Start with a day in the life of… scribble out the flow, the user journey. Nothing complicated, boxes and arrows. Then scribble out what the user interface might look like. Done. That’s your up front design. That’s your documentation. That’s your scope. What you do next is up to you, write loads of documents that describe it and produce the software in a waterfall way if you want. I’d prefer you were more lean and adopted agile practices, but whatever you do, start with the picture. I’m convinced it will save much pain later on.

CAPTCHA: a barrier to entry

When a customer starts completing an application or registration form it demonstrates they are committed. It therefore makes sense to pay attention to the usability of that form. But how often is the content of the form considered? Are there content barriers in the form that prevent customers from completing it?

Marcelo Calbucci (Via Luke Wroblewski) describes a barrier that everyone assumes just has to be there so it is not tested: The CAPTCHA. When the team removed the CAPTCHA from the Sampa.com registration form they recorded a 10% increase in conversion rates. Marcelo writes “we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time” (interestingly when I looked at the page I got the CAPTCHA). A 10% increase in conversion is not insignificant, and probably more than outweighs the additional effort to implement an alternative solution.

Banks don’t want you emailing their staff

You went to the local branch of your bank and spoke to a really helpful person there. In the few minutes you were with her you established a relationship with her. You felt comfortable and confident that she would take ownership of your request. But before she could deal with your query, disaster! You left some critical information at home.

Can I email it to you later you asked her?

Silly question.

Have you ever tried emailing someone in the branch network? Chances are the frontline staff don’t have external email. What sort of business is it that doesn’t give its staff email and the ability to communicate on a personal level with its customers? the same sort of business that has centralised all its customer contact and put it behind IVR.

So you give up on email.

Can I give you a ring with the details later you asked her?

She shakes her head. She doesn’t have a number. you see the branch doesn’t give out its number to the public. Go through the 0845 central switchboard, and let someone in the call centre pass a message to the person in the branch. (With no formal process to get this to happen, good luck if your messages ever gets passed on).

In fact the only way you will probably get a message to the person you talked to this morning is if you send a fax. One step removed from the telex, two away from the telegram.

What is it with the banks that they don’t want their staff to have external email access?

Do Business Analysts Destroy Value?

The usual approach for a Business Analyst is to start with the ‘as is’ situation and then model a ‘to be’ solution.  In understanding a problem, defining the as-is situation can take a number of weeks if not months.  Once the current technology, process and working practice are understood, the BA begins to define the solution.  Inevitably this solution is based upon what has been learned during the as-is analysis, thus the majority of their time is spent dwelling in the current reality rather than what could be.

Where is the value in that?  Where is the value in modelling a solution that is based upon that the current way of working?  What can you really learn about the business intent from the current as-is process?  A process that is based upon technical decisions, practical constraints and inherent complexity that were made at the time the software was built (in the enterprise world that was an average of 7.2 years ago), and hasn’t technology moved on since then?  By specifiying a system in terms of the curent reality the BA is missing a trick, and in the process is failing to add the value that the developement opportunity offers.  Indeed the BA is probably destroying value with over complex specifications that do not get down to the heart of the business need.

If Business analysts really want to create value, rather than dwelling in the past they should start with the “to-be” vision.  What are the desired outcomes of the application?  What should it do? (Not how should it do it).  Challenge existing assumptions, ignore perceived limitations and start with ‘blue-sky’ thinking.  What would we really like the application to do?  What are the customer / user goals and how can the application most eficiently (and delightfully) achieve these.  Think about the what, not the how.  Unlike the usual pattern of analysis, spend most of the time in the ‘to be’ world, only visiting the as-is to ask questions and confirm assumptions.

But that is only the first step of the BA creating value rather than destroying it. Why not go further and question the fundamental business model.  Rather than replace an old system with a new one, is it possible to reinvent the business itself?

Let’s take an example.  The client’s core business was data.  They supplied that data to their customers through an old and cumbersome desktop application.  They employed a service team to visit customers and install the system.  Data updates were sent via CD-ROM.  Their initial requirement was to maintain the desktop application.  The steer was to rebuild its functionality in an updated architecture (only one person in the company really understood how it worked, so updates were infrequent and key-man depecncy was a real concern to the business) develop a new local database and provide the ability to download batch data updates via the web.

The business analysis could easily capture requirements based upon this vision, yet they would be doing the client a diservice.  It would be possible to design and build a new desk-top aplication that woud be installed by the service team.  The technology would be better, database querries would be faster and customer attrtion would be slowed.  But it would be missing a trick.  The desktop application that IT wanted to rebuild was not where the value was.  The value was in the data.

Understanding what clients actually wanted and how they used the data (they used the desktop application to mine the data then copied and pasted into excel) it was possible to begin to challenge the existing assumptions.  The desktop app had charting and graphing functionality – why rebuild that when Microsoft do rather a good job of that with a product called Excel.  The requirements slowly changed into the ability for clients to pull data into excel via a web service.  It now would be possible to charge for data usage enabling creative new packages to be offered to different customers.  Previously customers had requested for changes to calculations and models to be implemented on updates for the desktop application.  Now the business started thinking about building a community where customers could create and share excel models and calculations on community website.  IT was helping the business create new value, setting aside the current reality and entering a domain of new possibilities.

The business analyst moved on from being a requirements taker to a change agent.  This was possible only with the mind-shift away from paying lip-service to the way the current application worked and thinking in terms of what and what if.

HP – Rude and impolite

This makes me mad. I’ve got a HP all-in-one printer, scanner copier. All I want it for is to print and scan. On the Mac the printer is plug and play so no messing about with drivers for that. I just need a driver for the scanner. So I insert the disc and find myself having to download 18 applications weighing in at 55 meg. No option to just install the scanning application – I’ve got to take the whole lot, picture editing, the works. Now that is rude, it is impolite [pdf] and it is selfish. If Mr Hewlett and Packard invited me to dinner I would come alone. I wouldn’t bring my family, extended family and assorted hangers on. So why do they think they can gate crash my computer like this.

What is it that makes your product distinctive?

In the recent copy of the Hong Kong British Chamber of Commerce magazine there is an interview with Fergal Murray, the Master Brewer for Guinness. He is asked “what do you think it is that makes Guinness so distinctive?” He replies,

I think there are a number of elements. From the brewers point of view, we want you to have a great all round experience. We don’t just want you to have a beer that’s refreshing, we want you to have an experience, to go through the ritual and theatre of emptying that glass. We want there to be a visual impact as well, it has to look fantastic. Finally, there’s a lot of flavour…

And you thought you were buying a pint of the Black Stuff because it was refreshing and tastes good. Yet for the Master Brewer these are bottom of the pile. Most important is the experience.

This is something that is missing in much software development. There are very few master brewers who go beyond just satisfying their customers with features and functionality, to focus upon delivering “a great all round experience”. To turn the mediocre and mundane into theatre. Like Apple have done with the iPhone. Like Guinness do with their stout. Yet something gets lost as you move away from the strategic owners of the Brand, to those responsible for tactical implementations. And this loss can obviously be costly. If the Guinness Master Brewer was only responsible for a drink that is an acquired taste, would it still be the sixth top ranked global Beer brand?

What the customer wants

I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.

Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.

I want an intranet portal“.

No, you don’t. You want a place where your employees can share files and documents.

I want a google search appliance“.

No you don’t. You want to be able to find documents quickly and efficiently.

Worse is when vendors try and force products onto the customer…

You want an integrated BI toolset“.

No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.

OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.

I’ll write more about this in the future…

Bag of risk

I’ve only thought of blogging about Lois Vuitton once before and that was on how they positively encourage queueing outside their stores during busy periods. It’s a pretty strong brand that can tell its customer to hang about before being allowed to come in and shop.

This time I’m not blogging about them in a positive light, and nor are many others. Jeremiah Owyang describes the situation they are in well. Their brand has been hijacked by Nadia Plesner, an artist trying to raise awareness about Darfur and how the media considers Paris Hilton with her “designer bags and ugly dogs” to be more worthy of attention than genocide in Darfur. She uses an image of a LV bag in her T-shirts. LV take offence and sue, she refuses to budge and suddenly the image, the issue and LV all hit the spot-light. And in this David and Goliath contest, who is going to come out worst? There can only be one looser.

So why didn’t LV just ignore it, or even as Jeremiah suggests, harness the issue, turn it into a conversation that would paint them in a good light? I’ll argue that it is because they don’t understand risk.

There was always a risk to the brand be de-valued by being associated by asociation with Dafur. And this is what the marketing and legal team jumped on with such zeal. Did no-one think about the risk to the brand of turning this into the issue it has become on the web? Laying out the options and doing a risk analysis would have been a worthy exercise.

Option 1. Assess the global impact of nadia plesner, assume it is minimal and do nothing. Risk to brand: minimal.

Option 2. Follow standard route of brand defamation and sue. Ignore association with ‘good cause’, ignore blogosphere. Risk to brand: potentially significant.

Sadly, it seems that LV ignored the whole concept of risk and went with the default option – sue. They are not alone in failing to assess the risks properly before pursuing a course of action. In IT this approach is endemic. Where is the greater risk? Placing all your eggs in one basket, investing heavily in a desired outcome that will be many months before it sees the light of day. Or take a more gradual approach, investing ‘just enough’ to get ‘just enough’, ‘just in time’. The latter approach is lean and agile. A good agile project is a lesson in risk management, building resillience into the process and testing options as you go. It is organic and evolutionary, (rather like nature), as opposed to the plan and control approach of waterfall which is brittle and will struggle to react to or accommodate risk appropriately. I should write more but there is a day’s work ahead.

Web 2.0, retail banks and a Slide Share presentation

This is nothing new, but there are still people out there to whom Web 2.0 is a bit of a mystery. What exactly is it, and more to the point, should our business care about this stuff? Or, as I have heard senior executives argue, is it just another bubble, a distraction to let others waste their time, effort and money on. In an attempt to challenge this assumption, I’ve used a model with a few sceptical clients to hang some structure on. This is central to the below presentation that I’ve given to a few financial services organisations. It discusses what Web 2.0 is, and towards the end describes what it could mean for their on-line retail bank website. (Thanks to Duncan Cragg and Prashant Gandhi for some insights).

[slideshare id=377944&doc=web20public-1209431680446543-9&w=425]

4 of 6
123456