Useful BCS talk on Differentiation by Design

It is ironic that working away from London for much of the last few years has kept me away from many of my Continuing Professional Development (CPD) activities and I had not been to a British Computer Society (BCS) talk since the one on Data Quality in May 2011.

I returned this time to hear about Differentiation by Design - The art and science of a great user experience from Dug Falby of Avanade.

Dug started by asking a few questions to find out who is audience was an what they wanted. It always helps to meet expectations to know what they are. Not too surprisingly, most of the people there were techies and were looking for something on the science of User Interface design.

We got some science immediately with a formula:
Adoption = Alignment x Value / Context (of use)

The function of the thing being designed is important but it is just a basic requirement. Softer things like beauty, emotion and meaning all matter. Ask any iPhone user why they bought one to see this.

Dug showed a clip of the famous case where a set of stairs was changed in to a keyboard to encourage people to use that rather than the escalator next to it. This is a good example of how good design led to behavioural change.

A good design starts with understanding what behaviour change we are trying to create. Dug gave quick descriptions of tools available to make these changes, e.g. Social Proof, Curiosity, Pattern Recognition, Peak-End Results, Recognition over Recall, Gifting, Delighters and Anchoring & Adjustment. Some of these tools also come under the category of Gamification which has had much publicity in recent years though it still seems to be much more of an art than a science.

An example of Recognition over Recall is Google's prompts for search terms where it tries to recognise what you are looking for based on what you and others have searched for previously.

Anchoring & Adjustment is about setting expectations (anchor) and then moving from this (adjustment). We did an exercise on this where we had to guess the value of two objects and on the card we had to put our answers on we also had to write down a price given to us individually. Overall, those that had to write the higher prices guessed higher values for the objects.

A more common example of this is a restaurant wine lists where more people by a wine that is around the third least expensive. Knowing this, restaurants compose their lists accordingly, e.g. by putting higher priced wines on that they do not expect to sell many of but it makes the rest of us feel as though we have not been that extravagant when we have paid £30 for a bottle.

In response to a question at the end, Dug said that the Business Analysis tool Use Case (which shows which tasks each set of user will want to perform) is insufficient as it misses Context (see formula above). It is not enough to know what task the user wishes to perform, the design also needs to take account of their motivation and mood. For example, do they care if the job is done well or not?

In the networking session after the talk and Q&A I had a quick word with Dug to follow up on some of this. I was interested in designing for two customers, e.g. a supermarket is designed for the shoppers' benefit in that it is easy to navigate, find the things that they want and to pay for them, but it is also designed for the supermarket's benefit by encouraging shoppers to buy more things and more profitable things.

This conversation leads to the Dark Side of confusing food labels and special offers that prove to be more expensive than the basic price. Here the good design is wholly in the supermarket's favour at the expense of shoppers.

The networking session was fuelled by the usual generous selection of sandwiches and wine. For some reason the BCS still advertise this part of the evening with a picture of me searching for the vegetarian option.

The session was not quite what I expected as I thought we were going to get something specific on, for example, fonts, buttons, colours and dialogue flows. I suspect that most of the techies there were hoping for something like this too.

As an aside, this gives me an excuse to reprint one of my favourite cartoons on design. (Sadly the Stuff That Happens blog is no longer available and I had to pull the picture from another site).

However, what we got was more about behaviour and motivation and so was perfect for a Business Consultant like myself.

I found it to be an informative, entertaining and provocative session and that is exactly the sort of thing that I like.

It helped that Dug had a lot of experience of the subject and was able to pepper his talk with real-world examples to help to make his point. I would much rather hear about how things did work in the past than how people anticipate they will work in the future.

Design is a vital component of every business solution, whether it involves IT or not, and this was a useful introduction to that fuzzy realm.

The Truth about Data Quality

I've found the talks at the British Computer Society (BCS) London Central Branch a bit hit and miss. A few have been far too basic to be useful and in others the speaker has not impressed me with their grasp of the topic.

But I go to the meetings because some of them are good, even very good. The Truth about Data Quality was one of those.

As a Business Analyst / Consultant I deal a lot with data and processes and I learnt long ago that data is far and away the more important of the two. The main reason for this is if you have the data model correct (in business terms) then it is easy to adapt processes to different needs but if the data model is wrong no playing around with processes can fix it.

All that means that a talk on data quality was guaranteed to pique my interest. And so I went.

Jon Evans' talk was in two parts. First we had a useful (i.e. more than basic) introduction to data quality and this was followed by a detailed case study from the NHS that really brought the lessons home.

It was a long talk, around 75 minutes, and in picking out a few of my personal highlights I am obviously leaving a great deal out.

The four cornerstones of Information Quality are Accuracy, Timeliness, Relevance and Completeness. Accuracy is the most important of these as the others are meaningless without this.

We build to Accuracy through Validity, Integrity and Credibility.

Jon explained this well by successfully correcting the colours, fonts, spelling and grammar in a familiar sentence. The result all seemed very sensible until Jon asked, "Does the quick brown fox really jump over the lazy dog?". The point being, this is a valid sentence but is it creditable?

When looking to improve the quality of data we can use the FIRM approach; Find, Investigate, Remedy, Monitor.

At that point we moved on to the case study.

To make sense of this we first had to learn a lot about how hospitals get funded through the incorrectly-names Payment by Results (HbR). This is calculated from the Healthcare Resource Group (HRG) of each episode, e.g. a diagnosis or treatment given to a patient.

The HRGs are recorded by clinical coders working from the doctors' handwritten notes. Clearly there is much scope for error in this process and making a small error can make a big difference to the hospital financially. Jon gave us an example where a patient's condition had not been fully recorded and that doubled the amount paid to the hospital.

The system Jon had been heavily involved in developing with the NHS compared results between hospitals to see if they were creditable, e.g. were the numbers of episodes, as recorded in the HRGs, of each type in line with expectations.

The funnel diagram here shows the distribution of hospitals' results and the statistical significance of this. The hospitals get detailed reports that shows them their relative performance and allows them to drill down in to the detail to see of any anomalies. But, remember, being incredible does not mean wrong.

Using this analysis has helped hospitals to dramatically improve the quality of their data. The two main problems they have had to address are the quality of the original records and training for the clinical coders on the HRG framework.

It was an impressive case study but I was left with the worry that, despite the improvements made, data quality would always remain a significant issue and the inherent instability of the HRG framework (i.e. small differences in coding make a big difference in costs) means that the whole system may be invalid.

Or, as I put it in a tweet at the time: The NHS PbR is inherently bonkers.

But the basic faults in the PbR system take nothing away from the case study or from the talk. I learned a lot and that's what I went there to do.

Information Underload at the BCS

I had a choice of two meetings to go to tonight and made the mistake of going to the BCS to hear a talk on Information Overload.

This a broad topic but it soon became clear (but too late to leave the meeting) that all we were going to look at was email and for the next hours or so. Not only was this very familiar territory, e.g. we were advised not to copy emails to lots of people, but it was delivered with no insights.

A clear warning sign these days is when the speaker proudly announces that they do not tweet. I did my best to  compensate by tweeting myself during the talk. This is what I said.

"The speaker at the BCS talk on Information Overload does not tweet. Not an expert then."

"He keeps saying 'I really worry a lot' without explaining why. Unconvincing."

"Tweeting how long you sleep for seems brilliant for social research but laughingly dismissed by our speaker. Not impressed."

"Ye Gods! Now he's moaning that it's too easy to email your MP! Clueless."

Even the prospect of free wine and sandwiches after the event failed to lift my mood and I beat a hasty retreat home.

Putting the Government in the Cloud

My latest foray to the British Computer Society (BCS) was to learn more about Cloud Computing.

The Cloud is one of the big topics at the moment, e.g. it is one of Logica's three strategic themes, but there are many assumptions behind the terminology and I wanted to dig in to some of these.

Part of this was to try and work out what all the fuss is about as almost everything that I do with computers is in the Cloud already. All my photos are on Facebook, my bookmarks are on del.icio.us, my contacts are on LinkedIn and Google looks after my email, calendar and blogs. There is very little of importance on my hard drive.

Tony Heritage, of IBM's Central Government Team, kept a packed room enthralled with the story of the Government's adoption of the Cloud, the G-Cloud.

He opened with a warning about Shared Services, the Government's last attempt to drive down IT costs. This produced lots of providers of shareable services but no consumers.

However, the prospects of the Cloud are much better with, for example, Google able to run 2,000 servers per employee.

The G-Cloud has a fairly common layered approach with networks, data centres and applications.

Consolidation of networks and data centres is a no-brainer. There are some budgetary and governance issues to fix but the rewards are big enough to make them worth tackling.

Thinks get a little trickier after that as the promise of shared applications has never worked before because every organisation will claim vigorously and loudly that they are unique and need the applications tailored to them. With tailoring comes cost and then trying to share applications becomes even more expensive that keeping them separate.

The many questions and comments from the floor shared the cynicism, perhaps not too surprising given that most of the people there were from my generation and had lived through bureau services, outsourcing, software components, applications frameworks, etc. etc.

I was left with the conviction that the G-Cloud is an oversimplification of what is required to consolidate and share, in particular the market dynamics required to make it work (e.g. who could possibly bid to provide this, how would the government contact with them, how would they engage with the many user organisations). It won't work.

Social Computing in the Enterprise Comes of Age

Given my personal interest in KM and my employment in the IT industry, I was clearly going to be attracted to a talk on Social Computing in the Enterprise, E2.0 if you will.

Social Computing has been a phenomenal success in private lives and we are all aware of things like Facebook, Twitter and blogging even if we don't all use them ourselves. The challenge is to take this enthusiasm and collaboration through the corporate firewalls so that the people who pay for our time can reap some of the benefits that we ourselves get.

It was the bold promise that this has come of age that most attracted me to the talk and I was hoping to hear compelling case studies of how leading-edge organisations are already making good use of web2.0 tools. Unfortunately we were given some bland promises of tangible business benefits bit no real evidence of them and certainly nothing we could take to sceptical executives in our own organisations.

What we did get was a basic, but useful for the uninitiated, introduction to what E2.0 is that while not challenging was interesting enough to sustain and hour's talk.

Then came the networking, wine and nibbles and the evening picked-up the pace. I spent most of that time talking to people I know mainly from the LIKE and Gurteen events and it was good to have more time for this and to be able to compare the events.

Overall it was not a great night out but it was certainly not a bad one either and I'll be on the look-out for more BCS events like this.

Business Analysis: Theory and Practice

It had been quite a few years since I went to a British Computer Society meeting (my techie days are long behind me) but I was tempted to go to one on business transformation in local government.

It was a meeting in two halves and my reaction to these was quite different.

First up we had Debbie Paul giving us Business Analysis 101. This was a bit basic but was obviously useful to the techies, i.e. most people there, who are more used to dealing with boxes and code than business processes and people.

I had no real complaints over this part, as demonstrated by the lack of the usual derogatory comments in my notebook. I would argue that some of what was described crept from Business Analysis in to Business Consulting (this is where I think Business Change sits) but there is no point in arguing over imprecise terms so I was happy to let this ride.

In the second half of the talk James Archer gave a detailed explanation of a current project where some Business Analysis techniques were used.

There were some good parts to the story but it brought back too many bad memories from Lambeth of how bad local government is.

In particular, the project was not that ambitious, it was little more than a new web site, but it had still taken almost a year to get to the initial, and not yet working, release.

And secondly, the approach seemed to be well behind the latest thinking. For example, they had made the step of realising that they should describe their care homes in as much detail as their hostels but had completely missed that the current expectation is to include user feedback too. Sites like Amazon and Trip Advisor have done this for years and, frankly, this should be a minimum requirement these days.

The speaker was sincere, enthusiastic and knowledgeable but I felt that he was trapped in a small cage without seeing the bars.

The evening ended well with some networking over unexpected wine and nibbles which probably did just about enough to tempt me back to another BCS event if they ever stray into Business Consulting territory again.