Bored bored bored bored

The more astute among my gentle readers will have spotted that I have not written much about the company for which I purport to work lately.

There are two reasons for this. One is that it hasn't been very interesting. Life has carried on, with the dreaded rain of brown envelopes, asking for the normal collections for birth and marriage (though not death). There has been canoeing down the Wye for charity and people's children running marathons for other people's children who have (take your pick) need of a mouth-operated wheelchair, a cancer ward, or a memorial charity for drug rehabilitation.

I could discuss the difficulty of making people redundant and the effect it has on company morale, or perhaps whether the privatisation of the NHS is going to bring us in as much money as we hope. But the second reason that I haven't written about the company is because currently I am totally and utterly bored by it. Everyone is working very hard, and their little foibles are more concealed than usual. It is intriguing to see who is browsing which websites on the run-up to Christmas: is it amazon or ebay? Hunting for a job or trying to move house?

I myself am spending more time researching the latest discussions on the benefits of U/X thinking than is required for working through the tests I have devised for the latest products.

I don't know whether it is the time of year, the shortage of daylight hours, or just an overwhelming weariness with the futility of life and the avarice and laziness of a vast proportion of the populace.
Perhaps it will improve when the child has its wheelchair, and a few more teenage souls are reclaimed for hard-working family values.

Come cheer me. remind me that applied cognitive psychology is not merely about making it easier for people to do what you would like them to do, but can also be used to, somehow, encourage people in those seasonal pastimes of good will towards mankind.

Net promoter score (NPS) - or how do you think about customers.

First of all, I'll start with the credits: The Net Promoter Score, or NPS® was developed by Fred Reichheld, Bain & Company, and Satmetrix in 2003. (See The One Number you Need to Grow). It assumes that all customers can be divided into three categories: Promoters, Passives, and Detractors.

It seems that the big idea was who you should concentrate your marketing on. There are your loyal recommenders, who will buy your stuff pretty much whatever, there are the people who don't really care one way or another, and there are the people who had a bad experience with you. Given a limited budget, where should you concentrate your efforts?

You will notice some sympathy with triage. I think the human brain is naturally comfortable dividing things into three groups. Like Gaul. (For anyone who has neither read Asterix or De Bello Gallico, that is a reference to Caesar. Caesar's title is not a reference to his summer holiday in beautiful Gaul, but to the Gaulish wars. I love faux amis, or in this case, armies.) Back to triage. This used to be the battlefield technique used to decide who to save and who to leave. The ones that you saved were the ones that you could save and who would not survive if you did nothing. How does this relate to customers?

You don't want to spend much effort on your loyal supporters. They don't need it. You don't want them to resent you (see the bad publicity that accrues when people realise that new customers are getting better deals than old faithfuls) but you don't need to woo them either.

The people who hate you hate you. There are those who bad-mouth you, which has a major effect on your business, and those who only chose you because you were the last one left in the playground. Who can you safely sacrifice and who is worth turning around?

This is where one number doesn't cut it. Bye bye NPS. It's a fair measure if all the bodies on your battlefield are privates, but we all know that what counts is the power that the body wields. You're obviously better getting a loyal high-spender than a low-spender, turning round the opinion of someone who whose opinion is listened to than that of a dead end Derek. The thing is, you can never be quite sure who that is. First, you can see who in the middle section has money and is worth investing in. Secondly, you can see what the cost of attempting to fix the problems are. If it's going to cost more to fix than you're going to gain in sales or spend in support, then consider leaving the problem as a straightforward problem. People do it all the time. Look at the list of known bugs. Look at that well-known bug category of "won't be fixed". So long as it isn't a deal breaker, you can ignore it.

Finally, be honest to yourself. Remember that everyone likes to think that they're important. If you can convert someone, they may turn out to be your strongest supporter.

The arthritic kitchen

First exciting information. I have an MSc certificate. With a hologram.
Second less exciting information. I have early-onset arthritis. In my right hand (I'm right-handed). As I said to one of my friends, this wasn't in my life script.

There are many good things though. I'm not saying that in a "cancer is a gift" sort of way, but in a "well, if this had to happen" sort of way.

First of all, I realised it was happening while I was designing the kitchen rather than afterwards. This meant that I chose nice big handles for my cupboards, rather than those invisible finger-tip numbers. Note well, kitchen designers: if your hands are swollen and painful, you cannot hold those dainty handles, your pinch grip is not what it used to be.

Secondly, I can still type.

Thirdly, pain-killers are brilliant.

Fourthly, I can find it funny that I'm running my hand sensuously along the cold edges of the cabinets in the supermarket because it eases the pain. Hot bodies, though probably more appealing, are less capable in the anaesthetising department.

I've had a functional kitchen for nearly a week now.(yes, that's terribly terribly exciting). Big handles (remember the big handles), iroko worktops, soft-close shiny white units.

I'm already discovering lots of things I got wrong. The most crucial of these is the distance from the oven to the sink. It's delightful, there is space in the kitchen, I can have friends in and all that jazz, but if, as I have done, you suddenly realise that you cannot carry a pot of boiling pasta to the sink to drain one-handed because it hurts too much, those extra steps are a total waste of space.

Next week, the exciting limitations of posh kitchen utensils. Send me your incredibly expensive item, and I'll review it from an ergonomic arthritic perspective. I'll even show you the hologram on my MSc certificate. If you don't, I'll just have to review what I already own, starting, perhaps, with the Samsung fridge.

And finally, assignment of blame

I was discussing the natural progression of projects with an experienced friend. Here are the real project stages:

1. Planning (have an idea)
2. Estimation - always wildly optimistic
3. Design - this stage may be done while implementing
4. Implementation - project starts to overrun
5. Private discussion with customer introduces a few trivial changes
6. Design is finally written down - this stage may be omitted if time pressing
7. Changes are discovered to double the project time and budget
8. Project starts over-running severely
9. Features start being cut, but are replaced by new features
10. Project now massively over-running
11. Features cut again
12. Project released in beta
13. Steady set of bug fixes
14. Blame assigned
15. Testing carried out - this stage can be omitted if customers desperate
16. Innocent punished

Obviously this is different from the Design - evaluate - implement - evaluate - test - evaluate cycle that I learnt during my MSc, but I fear that even that included the two vital stages: assignment of blame and punishment of the innocent.
The easiest technique for blame assignment is, of course, to blame the absent. They are safely out of the way, and it will not harm them. Second is to blame the customer and the boss. This does not damage the team. Finally, blame may be placed on whoever appears most vulnerable to it. This has no relation to responsibility

Costing projects

I'm very aware that I should put keywords in my blog. I'm also aware that I'm not attempting to monetise my blog. Anyone who reads it regularly, leave me a comment and I will be most grateful. Anyone who doesn't read it regularly: you're missing out.

I was comparing the fantasy of Agile management to the joys of converting a house.

Firstly, no matter how tightly you plan your project, it won't work. The tyres get punctures, the render doesn't go off because it's cold, the plaster sets too quickly because it's warm and so on and so on. One of the illusions that computers peddle is that values are fixed and unchangeable. Over years of experience one discovers that an apple this year is not the same as an apple last year: it may be smaller, sweeter, less common and so on and so forth. In the same way, programmers get ill, libraries get updated, life turns out to be a little difficult. It's fine if you're building on a greenfield site, but in the real world you may not be.

So we are dealing a non-representative series of events. Estimates are based on normal - that frictionless set of billiard balls or that perfectly rational economic creature... Life is imperfect, unbalanced, frustrating, and driven by chance. People on the top want to believe that it is driven by skill. They wish to confirm that it is their qualities that have given them their privilege, and others' failures that have denied it. When talking about becoming a premier league footballer, people are willing to admit that some people are born with more talent than others. You rarely hear the fact that given a couple of X chromosomes, you'll never make it. One sperm over another. Your chances ruled out, just like that.

Given the innate unpredictability of life, you need a reserve fund to cover the likely overruns in time and cost and temper whenever you're planning a project. You also need a contingency plan.
This is one of the things I find most interesting. What do you do when a project has overrun? At what point are you prepared to say "pull the plug/cut the costs"?

It is my belief that life is much simpler if you have a hard deadline, chosen in advance, such that when you go over it, the project is pulled automatically. I would be curious to see how many things would get sacrificed if you knew that at fifty per cent above the original estimate, or at twenty per cent above the original time, consequences dropped in.

When I was in a partnersip, I rekember bidding for a contract. We honestly told the buyers "It's not possible to do y in the time, but we can do x". We didn't get the contract. We were correct, of course, but people want to hear that they can do y in time t. Anyone who says "No" will lose out to anyone who says "yes". You therefore need heavy penalties for misleading on contracts.

There is less temptation to gain a contract bby being over-optimistic if you know there is an automatic penalty for getting it wrong. But how may customers prefer illusions to truth?

Project management and priorities

As detailed before, I have the hardback book (it's green - anyone else remember the Porridge quote). It has pages and pages of lists, all neatly sorted into four sections, interspersed with scribbles, diagrams of flues, back of the list calculations and so forth.

Approximately once a day we have the discussion.

The discussion consists of:

1. What can we cross off yesterday's/this morning's to do list?
2. Oh, what did you do then?
3. Oh

Long pause

4. Well, I'll add them to the list and cross them off.
5. Where are they in the list of prioritites?
6. OK, these are my priorities
7. What do we absolutely have to get done before we move in.
8. OK, we can survive without a shower.

Heated drawing up of two lists: one of things that must be done and one of things that are nice to have
We end up with three things crossing the line (insulation, decoration and chimney cowls if you must know).

9. So when you say do floor, what exactly does that involve?

Calmer and much longer list of all the components of the "things that must be done" list. During the discussion, we discover other things that must be added to said list.

What user interface design point am I demonstrating (or any other point)? I would say that it's a technique that is a refinement of Bill Buxton's Sketching User experience.

It is only when you have your ideas out there in some form that you can discuss them. I cannot stress this enough.

What I have in my head is non-negotiable because nobody knows about it.
What I say is somewhat negotiable, but it is often not clear what I mean.
What I sketch or model or put on paper is utterly negotiable because there is something to negotiate over.

Here is a mock-up of the stairs to the basement. It's a starting-point.
They're not on the priority list though.

Houses and the Harvard method

Do you know about the Harvard method?  I'm not talking citations or negotiation; I'm talking making lists. I was told it by a friend of mine and it's the best thing ever. (That, obviously is a wild exaggeration. I can think of many things that are much better, including champagne, my daughter's GCSE results, the smell of jasmine on a summer evening, etc etc, but in the breathlessly excited tone that is required for this sort of blogging, I will let the statement stand.)

Step 1: You take a piece of paper, preferably A4 or letter but it can be any size

Step 2: You divide it into three or four sections using a pen, pencil or other writing implement of your choice

Step 3: You write your list

The amazing and wonderful thing is that the process of thinking "which section shall I add this item to" causes you to sort the list items on the fly, and helps you to prioritise.

Because that point is, after all, the key struggle in project planning. How do you set your priorities? Do set priorities, you need to know what your goals are. And if you haven't recognised your goals, then they change and flip around and mess up the priorities. I've been reading a book by Gavin Essler, "Lessons from the Top" (no, I am not going to cite that correctly in italic and publisher and blah, I'll give you a link, isn't that enough? And it's not to amazon because of their behaviour on UK tax - correct but amoral.)

Sorry, got slightly distracted their. Essler quotes Alistair Campbell as saying that the key questions are: objective, strategy, tactics. And if you lose sight of the objective and get distracted by the cleverness of the tactics, you will fail. The tactics must always be subordinate to the strategy which must always be subordinate to the objective.

This is true for all projects.

An example of how it goes wrong (substituting stategy for objective) is to think that the point of the house conversion is to have a beautiful house. It's not. It's to have a happy family life. If you get stuck on the beautiful house bit, then you invest all your resources into the house, lose money, have enormous rows and go bankrupt, get divorced and everything goes phut. Having a nice place to live is a way of assisting the objective. And the method of converting the house to make it a nice place to live is merely a tactic.


So when you sit down in the morning or the evening with your piece of paper (or in our case a hardback book) and draw the lines on it, and start sorting the items in your list. Think clearly, think long-term. Some of it really doesn't matter that much, but sometimes, short-term goals will hinder that final objective.

Feature development and house conversion

I've not been blogging for a while because we have bought a fixer-upper house which needed a fair amount of work. I can't help but be struck by the horrifying similarities between house conversion and software development.

1. The estimates are always too short: people calculate the work period, and even when they're being generous, they forget to allow for being pulled off onto another more important (paying) job, set up costs, or the time spent searching for the library routine/thermostat which will do the job you want rather than all the others which nearly do the thing you want.
2. The code/wiring/plumbing that you have to interface with is always spaghetti and it takes much longer than it should do.
3. The code/drainage/etc that you have to interface with has not been documented and you will need to follow it through twisty strange paths and try and work out where the spurs go.
4. Even if it used to be fine, old code/wiring/plumbing does not match with current building standards/operating systems and has to be re-done.
5. Good programmers/builders etc cannot resist the temptation to do something well rather than well enough. This can take a long time.
6. Ambitious heads of engineering/house owners will suddenly have a brilliant idea about how something could be done better and require the whole thing to be re-designed half way through. They may well be correct but it adds a great deal to the time and cost.
7. It is disheartening to see no apparent progress.
8. There is a struggle between designing a usable interface and a functional system. Sometimes the people who have to do the extra work to make something easy and pleasurable to use rather than the way they'd first thought of it can be resistant to extra work.

So, given the fact that all the engineers/builders involved are intelligent craftsmen, how can the process be less painful?

I decided to apply some of the principles of Agile project management to the building project.

In Agile management, there is this fantasy (and it is a fantasy in many cases) that you can work on a discrete feature and get it through design and test in a solid blast, close it off, and then go onto the next thing. There are various buzz words around it, such as the scrum, the daily stand-up meeting when everyone talks through how they've got on and what needs to be done.

It's not a place for novices.

Solidified thought and an Inkscape review

Life has been busy lately. I've been revising the test schedules; not my absolutely favourite thing but better than a poke in the eye with a blunt fish. After the first desperate loops round the build, build broken, build buggy cycle, we have reached the stage of catch-up that we should have been in to start with, where features are being cleaned and polished, and software updates are being released every couple of days.

Apart from work, I have bought a house, and have been using Inkscape to plan the structural changes. It's a nice tool. I started using Autocad Architect, because I can get it free as a student, but it isn't merely using a sledgehammer to crack a nut; it's using a Boeing Dreamliner to commute down the road to work. Yes it's possible, and no doubt once it's all set up it would be quicker than walking, but the learning curve is so steep and time-absorbing that I'll just slip my shoes on for now.

OK, why do I like Inkscape?
It's pretty basic, but it's a proper vector graphics program, and it has all the things that I like using, in terms of converting objects to paths, grouping, layering etc. It lays things out properly with co-ordinates, and gives you accurate measurements.

There are some things that I'm pissy about - such as the way it seems to scale things proportionately when you don't want it to, and I look forward to discovering about using 3-D stuff.

You can import bitmaps, and export bitmaps, so I've done some beautiful scale drawings of walls and windows so I can do accurate sketches of the planned mural.

All right, I admit it. The whole Inkscape exercise was a procrastination. It enabled me to spend a whole evening doing scale drawings. Possibly even two, and I haven't done a single sketch on them. I have, however, borrowed a nice large book of tree photographs from the library. Get me!

Naming names at the Cheltenham Science Festival

I didn't get the grant to attend the Cheltenham Science Festival (though I was runner-up, thanks UCL). As a result, everything I currently write is entirely unbiased and paid for by myself.

I attended several events today:

1. The Web and Us

2. Conversation without Words

3. Stand-up maths

It should have been four events, because there was a follow-up to Conversation Without Words of a tango lesson (as an exemplar of conversation without words) but we were fortunate enough to find a buyer for a tickets.

Right, report back. My name is now on this blog, so I have to be willing to stand by what I say.

The Science of the Web didn't say much that I didn't know, but it reframed my knowledge. This is never a bad thing. My quote of the week (and possibly the month) was provided by Aleks Krotoski quoting Melvin's Kranzberg's first law of technology "Technology is neither good nor bad; nor is it neutral.".This was in response to a question of mine (self-aggrandisement is not good, nor is it bad, nor is it neutral) about the fact that the web was designed and created by a specific sub-section of the human population and how does the virtual society it supports mirror that social group. The panel for this discussion (the aforementioned Aleks, Uta Frith, Nigel Shadbolt, Bill Thompson and facilitated by Wendy Hall) was extremely (a) intelligent and (b) optimistic. Having read "The Social Life of Information" I'm not sure that I'm as optimistic as they were. I would like to name-check Bonnie Nardi, but I have a horrible feeling that many of my concerns are based on family experience, and after listening to Aleks Krotoski talking about the identifiable behaviours of your online anonymous persona, I don't want to admit to anything. Any where.

The sceond talk I went to was on conversation without words. This talk embarrassed me so much that I emailed one of the headlined participants with my criticisms. It was so bad that I'm not even going to say who that was - you can look it up if you really want to know.

The final session of the night was Matt Parker's Stand-Up Maths. I've seen him before, and he was just as entertaining this time as he was the previous times (which for sad, geeky people like me, quite a lot). My only regret is that I'm not quite sure if I learnt anything from the experience, and let's face it, people like me only fully value experience if they can come back and wow you with what they've learnt. anyway, it's late, and having not gone to Botany of Gin lecture, I have been doing my best to make up the shortfall here. I think that I now need to turn my main (and tastebuds) to Bombay sapphire and leave the blog for another day.

The value of big data versus confirmaton bias

The first thing is a massive Yaaayyyy! And possibly Hurrah, hurray, hurrah. We have released. Doctor's surgeries all across the land are getting their beautifully designed boxes, or their download invitations, and installing OUR software on their systems. Ian and Mr Grumpy are busy de-bugging as fast as they can, ready to release an update straight away, but marketing and sales are hap hap happy. Gavin and David are cheerful for the first time in weeks.

Obviously one of the things that sells the software is the way you can analyse your data. So you can see hours of work and rotas in pretty little patterns. In theory it will even calculate the nurses and doctors rotas for you. You can connect it to your appointments system and see who works hardest and spends the most of prescriptions and so on and so forth et cetera et cetera et cetera. GandD's cunning plan is to allow people to register their data (anonymously) and see how it compares with other people's data

The question is then what do you do with the data. As I've mentioned earlier, quite frequently, there are people who change their mind because of information, and people who don't. This may be for two reasons. One is that well-known problem (or achievement) of human psychology; that we prefer information that backs up the position that we hold. We look for facts that support our viewpoint, rather than facts that will disprove it. This is why the null hypothesis is such a fabulous idea and is more common in myth than in reality.

The other problem is that the data may be useless. Firstly, it may be data rather than information. Information is data which has been judged, and it takes a human to judge (or, of course, an omniscient deity). Given humanity's penchant for partial information and prejudice, we would often prefer to pass our judgement elsewhere. Secondly, it may be useless if one can take no action based upon it. What is the use of information that cannot be used?

So maybe, it's best to hide data. Leave it in its data buckets in the garage, unmined and ignored. After all, all that unused data will only clutter up the minds and computers of the people who have to look at it. It will distract them from the decisions that they wish to take.

Perhaps I should introduce the concept of small data. Instead of "just-in-time" information, "just enough" information. Let the rest of it sit around if people want to go fossicking through it because they have an idea, but otherwise, don't encourage them to mess about with it. Concentrate on the things they want to do, such as where to go for lunch and how many times you can read the same detective story with a different title.

Shintaido is weird

OK, how may of you have ever even heard of Shintaido? None of you? Yup, that seems about normal. If you want to find out more about it, google is obviously your friend - or if not your friend, at least your tolerated acquaintance who you can't not invite to events of importance. You can find out about Shintaido by reading up on shintaido,co,uk or even shintaido.org.

Why I am mentioning a little-known, barely practised non-martial art on what is supposed to be a blog about user experience? Well, I went to the fortieth birthday celebrations of Shintaido in Great Britain this weekend, and realised that I hadn't written much about experience.

We talk about experience as if it was all the same thing. There is the sensory experience - visual response, haptic feedback, aural stimulation etc. etc. but we don't really use experience in the old way, in the sense of getting of wisdom. We don't talk about the experienced user as the concomitant of user experience. Someone with experience might be someone who knows better than to pursue a path to the end. The experienced user might now when it is best not to bother. When we talk about dealing with the elderly, we are willing to consider their motor skills, their eyesight, or their cultural background, but we don't value the experience that may help them make the decision not to do what we are asking of them.

Shintaido is about changing your experience of life. It's not an easy thing today, you don't particularly get transferable skills from it; although there are moments of pleasure, they are embedded in moments of severe embarrassment and occasional pain. You may make friends, but you may also meet people who you like and then never see again. In other words, it is like life, compressed into a weekend. You hope it has a purpose, but there isn't an obvious one. In that, it is unlike most other pastimes.

If we are offering users experience, is it something they want to have? Often what we are offering is to make the drive to the supermarket or pleasurable, or faster. We talk about peak experiences as things that you can guarantee, without giving due consideration to the fact that people might arrive at the waterfall in tears, or with cancer, or too busy kissing to look at the view.

I honour the fact that most user experience professionals want to help people live their life. After a weekend of struggling with Shintaido, I would like to occasionally find a way of helping people make sure their life is worth living.

Test plan, or the joys of hindsight

We have now reached the exciting stage of pre-release procrastination known as testing. This is, of course, a vital and money-saving period, full of return on investment and this and that.

There are several ways to test:

1. The developer tests their own code. They don't want to break it, so they treat it the way that it is supposed to be treated, much like a museum curator unpacking the latest Ming vase on loan from China, with extreme diplomatic and personal repercussions if anything goes wrong.

2. The customers test. This stage can follow immediately after 1. The customer attempts to do all the strange things that they used to do with the previous software, and immediately breaks the new version. In doing so, they may also lose their own work, ideally something that took several months to achieve and which they did not back up before upgrading.

3. The software is tested before release, according to a pre-arranged test plan. This plan usually consists of going through all the things that broke it before (using examples provided by customers), plus checking that any new functionality does what it is supposed to. The problems with pre-release testing are that the examples of failure may have been provided years ago, and that part of the code is as solid as a rock, so you are tempted to skip - always forgetting that code may have been re-factored, and, like the river chewing its way under wharves, large chunks may collapse into the spaces that have been newly undermined.
The other problem is that when you are testing new functionality, you need to know what it is supposed to do. And quite often you discover that there are large chunks of let us charitably call it "undefined behaviour". Ie, the developers made it up on the fly because they couldn't get a sensible decision out of anyone else, did not document it, and have forgotten what they did. For best effects, you need several developers who have all implemented the undefined behaviour slightly differently in different areas of the software, but sometimes you can achieve quite good effects with one developer, working on different bits of code with long intervals in between, so they have plenty of opportunity to forget what they did last time.

I have spent today working through the test plan. It has been an exciting and rewarding experience. Obviously we have loads of dummy data in files so that we can automate the tests as much as possibly, feed it in automatically, write out the log, but for various bits of interface testing, we have to sit there and run the test by hand and see what happens.

And as always, I discover that it has been tested that it behaves correctly if someone puts in the correct information, but not if someone puts in the wrong information.

All I can do here, is offer you the joy of http://xkcd.com/327/ on the matter of dirty data. Yes, you happy folk out there, people can be malicious, or merrely drunk, or just lost. Be prepared.

So I have filled out all the little boxes in the spreadsheet and logged several more bugs.

Personally, I think it's all to do with the user experience. Much like watching people have forty-seven cats put down their trousers - they do it so that you, dear reader, do not have to.

100 things not to do before you die

I am so tired of living in a culture where everything appears to be about grabbing as much as possible. It feels as if we are being encouraged to act all the time, that any action is better than no action, and the idea that goodness might be expressed in refraining from action is just seen as weird. So, in the spirit of Zen Buddhism, I will suggest some things not to do before you die.

Don't try and get a tan. It's much more relaxing to read inside. If you want to sleep, why do it in public?

Don't wear a bikini. It's not a great look, even for men, and the bits come off when you dive in.

Don't get wound up by your boss. They're going to die too. Maybe with more money, but it doesn't  save you.

Don't watch any of the amazing, highly-recommended TV series. Wait until they come out on box set and then don't buy them.

Don't put up shelves in your house. You'll only put stuff on them.

Don't write lists of things to do, or not to do. You end up padding them out with rubbish,

This is an obvious substitute for actually writing up anything about the software release. Jiri currently has three half-empty bottles of Diet Coke underneath his desk. This is not a good sign. Mr Grumpy has decided to sell his house and move into a caravan in his sister's drive. I'm not sure if he actually means this or not. He claims that it is the only way he can get away from the badgers that are building a sett in his garden. GandD are spending most of their days closeted in the conference room. Can you in fact be closeted in a conference room? Caballing in the conference room? Anyhow, they are busy, either having meetings with each other or with a set of lovely lovely doctors who are very enthusiastic about the possibilities of Jeremy Hunt and the NHS reforms and how our software could do just they wanted if only they tweaked it a bit. I have a terrible feeling that this won't be a case of feature creep but a case of explosion in the feature factory and there will be a massive recruitment drive shortly, swiftly followed by a massive redundancy drive. But hey, I'm cynical.

I'm still trying to work out how to stop Gavin coding. Well, not how to stop him, just how to lock him out of other people's work. There was a very bad scene a couple of days ago when Ian discovered that some of the stuff that he had checked into the code management system had been checked out by Gavin and horrible things had been done to it. Basically it wasn't a case of his ewe lamb being taken, it was more it being taken, dyed pink, dismembered, and then returned attached to the back half of a leprous rabbit.

I think I will draw a veil over the coffee room conversation.

Time and attention

We are limited by the time and attention available to perform tasks. As the old saying goes, you can have X that is good, fast and cheap, but you can only choose two out of the three.

In the real world, you don't even get the choice of fast very often. Some things just take the time they take. If they can be delivered quickly it's because you have a lot of skilled people giving it their full attention for a short space of time. If they're not skilled, it doesn't matter how many people you put on the job, they will a. waste their own time and b. waste each other's time.

In fact, I started this post last week, but I have been giving it neither time nor attention, so it's sitting exactly where it was. I've been removing dandelions from the back garden now that the sun is out.

You will now claim that there is a third point to the triangle, which consists of rsources. I'd agree with that. Good tools can make an enormous amount of difference, but they do this - no, I wanted to say, either by reducing time or by focussing attention, but actually I can't quite do that. Of course, they make the job easier, or sometimes you just can't do the job without them, you can't make bricks without straw (well, you can now - I assume that saying goes back to the days when the bricks would fall apart if they were only made of mud - can I be bothered to look it up? No, there's google out there, I'm not that interested. It's not a vital reference. I'll just not bother, and, as it were, leave it as an exercise for the reader).

Anyway when designing interfaces, the two things that you need to think about most are time and attention. Do you have the user's attention? More important, do you need to have the user's attention? The user is going to be sparing with those two resources, she doesn't want to waste them, you only have a limited amount of either, and somebody else's crap interface that wastes your time and makes unnecessary demands on your concentration is the last thing you need.

So in appreciation of you having got down to the bottom of this post, I'll give you a free joke.

Where does a general keep his armies?
Up his sleevies.

I never said it would be a good joke.

Blogging Easter

Let's tick off the Easter rituals carried out:
1. Member of the household in bed with flu? Check.
2. Feeling sick after eating too much chocolate? Check.
3. Brisk walk in icy wind while strange dog inspects your groin? Check
4. Loud and entirely justified row in which I am totally, completely and utterly in the right at all times (apart from an occasional fact)? Check.
5. Bottle of champagne chilling for celebration that does not, in fact, occur? Check.
6. Search of internet for exciting event to take part in over bank holiday weekend which ends up as a serious gogglefest of 1960's St Trinians films? Check

OK, I admit the last one isn't quite traditional. They were actually quite entertaining. I could possibly have gone for the Carry On... series to drop down a notch in the non-blockbuster black and white left-field arthouse option. Or the relentless replay of incredibly bad Hollywood blockbusters aimed at five year olds. Or climbed up through the arthouse credibility stakes by claiming to have watched the entire Studio Ghibli season. Mock not, I lost the family copy of Spirited Away before my daughter hit her teen years and may never be forgiven. As far as I am concerned, a video/DVD/bitstream shelf that does not include Some Like It Hot, Casablanca, Die Welle, M, The Battleship Potemkin and the original Wicker Man is the mark of a family that is not giving enough cultural attention to its children. Before you know it they'll be skipping the Suzuki violin practice, forgetting whether Pride and Prejudice was written before or after Northanger Abbey, and omitting hashtags on twitter.

Anyway, I am proud to feel that I have done my duty. Easter baking took place - with the traditional drop of the cinnamon jar lid into the mixture, thus enabling all products to have a deeply intense cinnamon flavour. Easter egg trails took place. Suffice it to say that I wish they could have more unexpected anagram solutions than either "Happy Easter" or "Easter Egg". We spent some time trying to convince the children that there was a small but real possibility it might be Faster Dog, but they didn't believe us.

Next year I plan a complete set of clues leading to a small soft-boiled egg lurking in a handwoven nest. Disappointment should be rife.

Affective interaction: why feelings matter

Obviously feelings matter to people, there is at least one case study that shows that if you cannot feel emotions, you cannot make decisions, because you have no way of deciding what matters. But why do feelings matter to computers? Or rather, to how computers communicate with people or people communicate with computers?

It's easy to think of people monitoring your feelings as frightening. For example, there's one discussion of what would happen if the computer interpreted your voice, so you'd have to say "good morning" to your computer every morning, and your computer would thereby gather a stack of data about your speech and be able to respond to your emotions. Yes, this all does sound a little like the extremely irritating lift in hitch-hikers guide to the galaxy. And in fact, one of my favourite bits of research on computers and emotion is that people prefer talking to a grumpy, irritable computer than to a smooth ingratiating one. There's a possibility that this is due to the person attempting to get the computer to be less grumpy. In other words, "Go Marvin!, we really do love you".

But where computers responding to emotion is already important is in hospitals. Robots are used to take people around, and they need to recognise from people's movements and expressions how important it is to get out of their way. We like that. Well, I do anyway. That's robots avoiding us when we're in a hurry. That's the automated check-out at the supermarket noticing when it is being outrageously irritating and shutting up. That is the ATM that argues with you.

I think there is scope for developing a computer version of a teenager. That you could practice being irritated with and when it kept arguing back to it you could "SWITCH IT OFF". Smugly.

The joys of failing tests

Did I mention that we had the opportunity of a massive contract if we could set up the interfaces between the system that is currently in use by a group of practices and our amazing easy-to-use fabulously intuitive (or not) new system?

Well, what has happened is that justintimeJack has been pulled off his bit of the development work so he can concentrate on working out all the interface code. JustintimeJack is going skiing next week. He's very excited about it. Every time I pass his computer I see that he is checking the current snowfall in France. Oh I am so so sorry Jack, it's snowboarding not skiing. You are sliding down an icy and cold slope on one bit of laminated fibreglass, not two (yes, I know it's not fibreglass, I am merely giving all your cold-weather sports pedants the opportunity for a brief moment of superiority as you get a photo taken of yourself drinking marshmallows soaked in cocoa in your hot tub).

I, with my well-known talent for knowing what the user wants to do, am writing the test plan. I like test plans.

What does this one involve?

This one involves creating a massive number of spreadsheet records, containing every possible combination of hours and rates and holiday and part-timeiness and whether they're a partner or not, and whether they're claiming civil partnership adoption allowance and so on and so on and so on.
And running them through Jack's conversion algorithm to see if they all come out in the right place with the right rates on them.

And then adding the record where it fails to bugzilla along with a description of how I managed to make it break THIS time, and assigning it to jitJack along with one of the highly-amusing states that the developers put on a bug.

These can be summarised as follows:
Not a bug
Can't be arsed
Can't recreate
Duplicate of xxxx
Only if they pay us more money
If we have time
Crucial
Deal-breaker

And of course, all the ones that people spend all the time on are the ones they find interesting and the deal-breakers, where smoke is emerging from Ian's nostrils as yet again Nick explains why he did three of the "if we have time" bugs rather than the dull but crucial one.

And I get re-sent endless copies of can't recreate - often with a "which version were you running it under" or "where's the file"

to which my replies nearly always "the latest" and "It's attached".

Anyway, my skills at describing exactly what went wrong this time are going up by leaps and bounds. Let us celebrate. We nearly managed to complete a whole import export and re-import data cycle. Doesn't that sound fun?

Why can't life be more like the movies?

So why isn't life more like the movies?

On film, boring moments are skipped. This period before a release would be covered in a few shots: Ian in earnest confabulation with Mr Grumpy, Justintime Jack throwing a juggling ball up and down, Gareth swigging coffee as he types , Jiri's head resting on his desk. And that would be it. Perhaps a minute of screen time encapsulating the last desperate push towards the release.

In the perfect world, I would already be on the next project. I'd be out there in the world, researching, discovering, designing, exploring. My 3B pencil would be glancing swiftly over drafts in my sketchbook, which could be converted to mock-ups in balsamiq or Axure or...

But that's a film fantasy, right up there with happy marriages ever after. Instead I'm testing testing testing. Let's face it, a usability consultant is a wonderful thing, but even more wonderful is someone who will sit and write a test plan. And then carry it out.

Happy crashes and the world of risk analysis

There was a great conversation at work today, about what a real emergency is. Someone pointed out that a real emergency is something you haven't planned for. In this case, it wasn't the total system crash (that's all in the disaster recovery plan) or the mirror server not being online when it crashed (because that's not really a problem and it was only a couple of hours of data lost). It was that the crash happened at the end of the month, when pay normally is transferred into bank accounts, and the four hours recovery time would make a significant difference to how long the pay transfer took. And there were a couple of members of staff who had mortgages to service and credit card bills to pay and speed of access to their dosh was a bit vital. So the manager at this GP practice went round the car park and emptied all the parking meters. And with the fine collection of £1 pieces and other items of change, managed to procure enough cash to provide emergency tide-over to anyone who really needed it.

It was wonderful. I only heard about this second-hand, because our IT manager/support queen was out there  with tranquillisers, damp towels, caffeine tablets and the off-site back-ups. Apparently the manager told everybody what the situation was, and they all decided who really needed the money. Of course, that might be because it's a doctors' practice, and let's face it, doctors are normally in the job (or at least started in the job) because they wanted to help people one way or another, so it's not really surprising that that's how they dealt with the problem.

Could the problem have been averted? I don't see how. Even if we'd done a full model and considered the effect of different scenarios at different times of day or coinciding with crucial events, we probably wouldn't have done anything about it. And let's be honest, we wouldn't have spent the time or effort modelling, what happens if ... the crash happens during a royal wedding. We might have got as far as thinking, what happens if it crashes with someone in the office/no-one in the office, but I don't think, realistically, we'd have considered what happens if the four hours downtime coincides with payday. And if we had, we would have decided that it probably wasn't worth the effort of providing cash on the premises to tide people over.

So I might blog about risk analysis another day, but until then, I want to send many many thanks to the guy who saved our bacon by opening the parking meters. Or rather (because our bacon is absolutely fine, thank you very much) the guy who helped the staff members who would have been severely disadvantaged by the side-effects of a risk that had been assumed to be acceptable.

Last minute featurettes

Did I say that we're heading for a release? This is always an exciting time in the office. (Especially when one crucial member of staff was off for two days after an after-show party. I have my suspicions about whether said tin man was in bed with a hangover or something else, but I hope he had a lovely time either way.)

It's especially challenging at the moment as David came in looking somewhat stressed and very excited.He has made a massive sale (he hopes) to a whole group of GP practices, but (there's always a "but" isn't there) they have an extra set of financial issues. They have been using some other package, and want to be able to export all the current data from package X and put it into our package (hitherto not given a name but let us call it "VAT's up Doc"). And their database and our database have some differences of opinion.

Now Ian, lovely Ian, treasures databases as if they were his third child (and more than his five-a-side football team). He is happy when thinking of such things as efficient sorting tables and effective queries. I don't talk to him much about it, but occasionally I hear snippets as I go by. Apparently incorporating this other system means a total restructuring of the data tables (whatever that implies). I, of course, want to get my filthy, little hands on the interface and see how their work method compares to our work method. But I won't get a chance. They are pulling Ian out of the development push to the release date so he can restructure his tables. Worse than that, if he restructures the data tables every other transaction that we use on the data will have to be checked, tested, and possibly rewritten. So there are some heartfelt meetings going on as to how they're going to organise the development effort and what features are going to be cut so they can squeeze in the restructure and whether the sale is absolutely guaranteed with a signed contract with plenty of exciting trailing zeroes.

And I know that they will cut it and hack it and do whatever it takes and it will require some front end re-design to make it work and no-one will have the time or effort available to ensure that the re-design is going to be user-friendly because what matters is that the transfer is going to work first time.

Oh well. At least I know it's doomed and I understand why. And at least there's something fairly stable there for them to hack about with. And looking on the really bright side of life, this does mean that David won't put any other featurettes in.

What is maths for?

Some of you will have been following the controversy about Michael Gove's (the education secretary) ideas about the curriculum for primary and secondary education. Some of this has to do with how maths is taught and what it's for.

There appear to be two views about education: one that it is designed to equip people to operate in the world. So you teach people how to hew wood and draw water, so they will be efficient and effective wood-hewers and water-drawers and increase the country's GNP and so on; the other that it teaches people to think, so they suggest maybe we could have an aqueduct.

And maths can be seen as a set of tools in your toolbox, to tell you how much wood to hew and water to draw, or even how to set up the aqueduct at the correct angle and flow rate. Or it can be seen as a philosophy, a way of thinking about the world. Or even an art form, an occupation that is a human pleasure and delight and not necessarily for anything.

One of the thing that concerns me about interface design is that sometimes, it is a series of incremental improvements to make things easier, rather than a question as to whether the thing that is being done is worth doing at all. Yes, I know, that it is seen as a luxury. firstly, there are the bills to pay and the food to cook (and the wood to hew and the water to draw). But occasionally, if you have the time, ask yourself if there is something of delight in what you are doing. If so, it is probably worth it.

Organisational culture

I promised everyone an organisational analysis of the GandD's company. You've probably already worked out that I'm a bit of a fan of soft systems methodology (Peter Checkland). NO, you probably haven't, after all, I don't think I've mentioned it before. Well, I am, because it tries to deal with complex problems.

OK. Back to organisational models. You can think of an organisation as made up (like Gaul) of three interdependent parts. These are:

1. Systems: the functions that are carried out
2. Structure: the layers in the hierarchy
3. Culture: the norms and values of the environment in which you operate

Systems and structures are pretty straightforward. Most people can say what they do and where they stand in a hierarchy. Culture is a bit more complicated.
This is because the culture of an organisation arises from its history and previous purposes, as well as its current ones. It can also change according to the people who are in post.

The notes |I have refer to four types of culture:

1. Power
2. Role
3. Task
4. Person

You'll have probably worked out  (oh, I was wrong last time when I said that)... Maybe you've worked out that GandD operate a power culture. They have it, and they want to keep it. One of the weaknesses of a power culture is that it is static. Information flows to and from the hub, but it doesn't tend to move much between departments horizontally. Also, the owners of power don't tend to want to train up successors.




GandD have each other, and they've pretty much split the company between them. You can think of them as the left and right hemispheres of the brain. There's a lot of communication running between them, but they have one to one communication with each part of the body. They see their company very much like that. They can't see why Ian would need to chat to Jeanette or Jeanette would want to chat to me, because you don't get hands talking to ankles, or ears chatting to livers: except of course, you do. There isn't just a nervous system running through the body, there are other ways messages are carried, most obviously in the blood. You can think of gossip as all those molecules being transported about, from lungs to heart to liver to pancreas to skin...

I'm quite enjoying this analogy. And then you can have new people coming in like blood transfusions, and how your muscles behave differently when they're tired, and how the placebo effect works and, well, anyway, I think I'd better stop there before I go too far.

Oh, did I mention it's Nick's show this weekend? I don't know who sneaked onto his computer when he'd gone out to get some coffee and changed all the system sounds to snatches off music from The Wizard of Oz, but they did a very thorough job. Even now, you're never quite sure if "Ding, dong, the witch is dead" is suddenly going to come pouring from his speakers when he's compiling a library.

The value of installation guides

I was updating the installation guide today. This is not one of my favourite tasks. Obviously, I have to install the software as often as possible, on as many different operating systems as possible, locally and on a network and so on and so on. (Did you say that sounds like testing? You'd be right.)

I wonder how many people ever look at an installation guide these days? Download the program and there it is. Perhaps you might have a CD or DVD drive with a disk that needs installing, but mostly it is an unnecessary item.

Except for all the other messages it carries. What to do when things go wrong. What your license number is. Whether the company is solid, reliable, reassuring. Some of this is to do with human emotions. Although we may be suspicious of marketing, we still succumb to it, the weight and glossiness of an object. The sense that somehow it has value. The booklet is the only tangible evidence that we have that we have bought something. It must represent the value that we have paid.

I haven't mentioned much about the developers lately. This is because they all have the "heads down, arses up" aspect of extreme concentration before the release date approaches. The steady ones are getting more frazzled: Ian, normally calm in all situations, is drinking more coffee than usual. Nick is going straight from work to rehearsals. Loadsoftime Jack seems to have realised that there isn't loads of time, and is frantically flip-flopping between all the different bugs that he is fixing and introducing. And GandD are both very happy. There is a very very big contract in the offing. Yes, the re-organisation of the NHS, so disturbing to so many, has been a wonderful gift to them.

Data, capta and astonishment

I'm starting today with a digression about data and a slightly mind-boggling quote.
The quote is from an article by Richard L. Lanigan, "Capta versus data: Method and evidence in
communicology", Human Studies 17: 109-130, 1994. (If nothing else, doing an MSc teaches you to cite, cite, and cite again.)

"Like most other human practices, research is largely a symbolic activity
in which "evidence" is mediated by converting experience ("observation")
into consciousness ("measurement") and calling it "humanistic" or
"naturalistic." Postmodernity has come to favor this methodology and
names the evidence thus produced as capta (quod erat inveniendum; which
was to be found out). Capta is that which is taken as evidence; it is the
methodology of discovery (Lanigan, 1992:215)."

OK. Have you recovered? Basically, I can summarise his position as data only has meaning once it has been organised, whereupon we call it capta (not a term that has made much headway in the world, as far as I know). Organised data, plus significance, equals knowledge.

So,  a string of numbers is data. An organised string of numbers can identify your bank account.

Letters can be organised into random arrangements, into words, into sentences, into this blog. But they only have meaning if you have the knowledge, the mass of education and culture and abilities and humanity to read them. And they only have value to you if they stimulate some response. Interest, amusement, anger, whatever...

It is your emotional response that matters here. Boop boop a doop
Why did the turkey cross the road? It was the chicken's day off....
Arise, ye starvelings from your slumber, arise....
My country, tis of thee

And so on and so on and so on. Maybe each one of those organised clumps of data triggered some sort of response in you. And from our shared culture, I might have a pretty good idea about what they might be. Perhaps I'm even toying with you, setting up one expectation to enjoy watching it crash and burn.

And I can hear quote my favourite user experience recommendation (wherever I roam, I get back to UX eventually) by Harold Thimbleby "the principle of least astonishment".

In normal life, we love being astounded, amazed and delighted. It's rare that this is a good scheme in user interface design. Much like the rubber chocolate biscuit or the exploding cigar, an user interface that thwarts our expectations makes us feel that the world is a little less to be trusted, that our understanding of how it works is not as reliable as we wished.

And....
.....
......
I'm not going to say anything more about it.

It's been a long week

First of all, have I name checked Dekker's Just Culture book in this blog? "Just", in this case, doesn't mean merely culture, or only culture, but a cultural environment that is fair, based on justice. My mind has gone off at a tangent here - it's Friday and I no longer have to pretend that I am a serious person. I merely cross-referenced to Robert Hughes "The Culture of Complaint" and then to C.P. Snow's two cultures and then culture vultures and then the culture of herbaceous borders and so it goes on.

Culture appears very much of a buzzword at the moment. There's a little bit that we covered in the MSc about it, about designing for different cultures, which covered how university websites present different aspects in Greece, China and the US, depending on what is seen as important to students and/or their parents.

That in itself is an amazing question. Is it the student or the parent who chooses the university? Behind that lie a whole set of assumptions and values that are tagged with the word "culture". Then there is the idea of someone being "cultured" which has a faintly superior air to it. we don't talk about people being cultured if they talk about Jay-Zee and the chip shop, but if it's Liszt and Chez Panisse, then that is cultured. But it isn't culture as in cultured pearls - though in both senses there is an implication of it being created rather than emerging naturally.

Our culture can be summarised as the totality of the external experience which we have internalised and trigger our emotions and inform our values. Some of it will be common - for example, western music conventions are widely recognised across the world, and some will be more particular to our own experience (such as breakfast choice).

When you create an interface, it is informed by your culture. What matters is whether understanding it requires an understanding of the culture or merely of the interface. A famous example of this, is the different meaning of a red light, which can mean a live socket or a problem (or an invitation, or a veto). Just because you know what you mean by it doesn't mean the user will. But luckily, most of the time they don't have to.


Oh, and the Dekker book? That basically says, that if you get punished for making for mistakes or discovering errors, you're going to hide the fact you make them, and this will lead to some very big problems

Gossip, gossip, gossip

Yes, there has been a major excitement at work, and every office is buzzing. Nick has shaved off his beard. It took a little while to percolate, but once people realised, there was a continual stream of people coming to check this, that and the other, and make sure to get a good look at the previously-concealed jawline. Needless to say, it was Jeanette who stepped right out there and asked why he'd done it. And lo and behold, our unremarkable coder has managed to bag himself a starring role in his local village production of The Wizard of Oz.

He explained that some years ago someone had heard him sing, and suggested that he would be an asset. So he had joined the chorus, and stood in the back row whenever possible. Being painfully shy, he had never admitted to anyone he was there, but apparently there is photographic evidence that he dressed as a cowboy in Oklahoma. This year, flu and children and university had struck at the available menfolk. He had boldly stepped into the breach and auditioned. (I would have paid good money - or money with no moral qualities whatsoever - to have seen that) and either due to his assets or the company's liabilities, he had been given the role of the Tin Man. This is a part that demands a certain absence in the facial hair department, so he had ventured into the local Boots and bought one of those cut your own hair devices to remove all the long hair, and a razor with seventeen blades at different angles (I may be exaggerating slightly for effect here) to create the required metallic smoothness.

I think that it probably, all in all, lost the company half a day's work as the news was passed from room to room and cubicle to cubicle. Dates were put in diaries for people to go and see the show.

Even better than that, of course, was what the company gained. Enthusiasm, interest, and a better understanding of developers. They were cheered by people coming in to see them. They were happy that people wanted to know what they did. Even better, the people who dropped by to see the amazing, never-before-displayed chin also dropped by to see what was going to be happening and signed up on the "I'm willing to test" sheet.

I think that the person who made a comment about whether Nick really was "a friend of Dorothy" was being a little unfair. After all, a liking for musicals is perfectly possible to combine with a liking of lego. It's just a little unusual.

Anyway, I'm definitely going to be buying my ticket for the team night-out to watch him saunter down the yellow brick road, singing "If I only had a heart". I'll even offer to give other people lifts.

Sorry, I seem rather to have omitted any user interface information at all, but this is seriously exciting news. I'll be back on the Doctors V Accountants front real soon now though.

Let it snow, let it snow, let it snow

I live at the top of a steep hill. The main road up the hill has been gritted, and after the first few hours, was perfectly passable. The side roads have not. The pavements have not, and a series of adults dragging their tots and toddlers up and down the hill on toboggans have compressed them into a sheet of ice. (I need to point out, smugly, that I, of course, have taken a spade to the ice so the pavement outside my house is walkable.)

I became incensed when listening to the radio, when there was the normal interview with a Canadian, or a Swede, or someone from some other northerly environment, saying "We have X metres of snow a year and we cope, so why is Britain brought to a standstill every year".

OK, all you UX people out here, why does it happen?

Firstly, it doesn't happen reliably, so it is not worth investing an enormous amount in machinery that may lie idle three years out of four. Secondly, it doesn't happen reliably, so there isn't a culture of dealing with it co-operatively. Our local council appointed snow wardens this year, so now the bend that I got stuck on last time it froze like this has been gritted by a public-spirited chap who was willing to take the responsibility, but most people don't understand the need to contribute. Thirdly, it doesn't happen reliably, so people don't know how to drive in it. Fourthly, it doesn't happen reliably, so the road infrastructure is designed for rain, not snow.

Those are all UX problems. How do you design for something that people only deal with occasionally (possibly never)?

The other problem is also a type of UX problem. Snow in England and Wales is normally at a temperature where the weather switches between freezing and thawing, so we have to deal with ice as much as snow. Many of the solutions used in other countries rely on there being a nice consistent layer of cold snow, rather than one which melts and then freezes. Importing a solution wholesale that is a perfect fit for a different situation is not always the right way to go.

So, who sets the priorities as to whether this problem needs to be solved?

Question one.
Who bears the cost of preparing to solve this occasional problem? In this country, it's the local councils (funded by grants from central government and the rates).
Question two.
Who gets the benefits of solving this problem? We all do, but especially businesses, because people can travel freely.
Question three.
Who educates people as to how to behave in snow? Teaching them how to drive? Well, you're not going to put that on the test, because it won't happen. You can't even put motorway driving on the test because some test centres are in towns that are too far from a motorway. ||Maybe there should be a special, "Hey, it's going to snow next week, everyone in the UK sign on for your one-day 'how to drive in snow' course." Somehow, that doesn't quite work.

Clear your pavements? Well, how to change the culture of a country so that clearing pavements becomes the norm? Do those snow wardens need to go round knocking on people's doors saying "I see that your pavement is not in a walkable condition". Hey, I could go for that. Lets make all pavements walkable. No parking on them. No heaps of rubbish blocking them. No enormous bins and signs and.... I'm ranting. Calm down. After all, one of the fabulous and wonderful things about snow is that people get out of their cars and walk. They greet each other and smile and walk in the road because the pavements are slippery but the roads have been gritted. They co-operate.

Maybe it's worth having a day like that, just occasionally, where people are forced to drop out of normal life. Maybe UX designers should consider, just occasionally, putting a glitch in the UX that says "This isn't working today, why not go and enjoy yourself instead, talk to someone who you don't usually say hello to, bake bread, spend time with your children, see if you can stop the leak round the windows."

Oh, they exist. It's called a bug (or possibly a feature). And everyone gets very cross when they find them. Next time you meet a bug, email the guys so they know about it (otherwise it won't get fixed) and enjoy your brief minute of snow day.

And I've just looked out the window and seen someone taken their cello down hill on a sledge. How lovely is that? Happy snow day, everyone.

The joys of communicating the wrong idea

I have an embarrassing confession to make. I got an interface totally wrong. Let's say that there was a complicated VAT procedure that surgeries only needed to use if they had a pharmacy attached that sold old-style bottles of kaolin and the moon was pink. So it's not done very often, and you need to know about adding the kaolin and the moon to the references.

I looked at the dialogs and went, why do you have pharmacy on this page and clay on that page and gibbous on that page? It's just totally ridiculous. And I hacked up a new version of the dialog and scrawled red bits all over it and said it would make much more sense if it was like THIS!

And because I am the user interface designer and everyone thinks I'm lovely, they re-designed the interfaces to match what I thought it would be.

I'm going to digress for a bit (partly because I adore digressions). The most important thing you can do with any idea is record it. Keep a sketchbook handy, or an ipad or whatever you find a quick and easy method. Your phone will do. I like paper best because you never need to switch it on, the response time is minimal, and you have the best haptics. Yes, I could go on for quite some time about the tactile experience of pencil meeting paper. It's also utterly flexible, you can sketch, write, explore. And then take photos of it to record it electronically. And when you're recording a visual idea, record it visually. The big problem I find with people commenting on designs is that they write out their comments in an email, without pictures, and it is not obvious what they mean. When they say, put the checkbox together with the associated field, there is no clarity as to how you put them together, where they're laid out and so on. Sketch it in front of them. At the low end of the scale scribble over a screen grab in Paint or draw boxes on a bit of paper. At the high end mock-up the work flow in a wire-framing tool. Just make sure that you have agreement what the idea is, before you decide whether or not it's a good idea.

That leads me back to where I started. I'd communicated my idea on the mock-up. They'd implemented it. And the next time I worked through, I still didn't understand it. You know why? It was the wrong idea.

I had totally misunderstood the functionality. I thought that they were developing an add-on contraceptive planner requiring the use of the moon and kaolin that was VAT-free, rather than a VAT calculator for kaolin sold during a gibbous moon. So obviously I'd put the wrong bits together in the wrong order.

And I'd made things much worse. 

So today's top tip is remember the difference between efficiency, effectiveness, and efficacy. Sometimes you can go through all the right steps, exhibiting enormous skill, but you're still going in the wrong direction.

Ethics and personal responsibility

Sir Peter Rubin, head of the GMC (General Medical Council), was invited to give evidence to the parliamentary commission on banking practices about the requirements of a regulatory body.

He pointed out that the GMC had considerable control over medical education, and therefore doctors educated in Britain had been required to learn a standard of ethical behaviour. He also pointed out that doctors bear personal responsibility for their actions, whereas bankers do not. (Parliament TV of the evidence).

My education has included little practical ethics (a philosophy module at York covered Kant's categorical imperative, which offers useful advice about behaviour about speaking truthfully to men carrying axes). My MSc discussed organisational behaviour, risk management and research ethics. In the module on ergonomics, we were told that bad design can cause accidents, and told that in future we might bear personal responsibility for accidents that were due to poor design. For example, is the person who decided on the position of the signal passed at danger at Ladbroke Grove (wikipedia details here) personally responsible for the deaths of passengers caused by the signal being difficult to see? Geoffrey Counsell organised a fireworks display near a motorway. He is being prosecuted for manslaughter, because it is possible that smoke from the display obscured visibility and caused drivers to crash. They can't be prosecuted, because nobody really knows whether they were driving dangerously or not.

How is responsibility shared out? When something goes wrong, we look for an individual to blame. It is as if we imagine that there is a single chain of cause and effect, that we can follow, and find the original person who didn't spot the missing horseshoe nail, or who put the shoe on badly, and then blame them for the consequences. While it's never that simple (I'll talk about organisational cultures another time), there's still a question for any interface designer. Does what you do make it more likely that someone else will make a mistake, and possibly destroy their own or someone else's life?

Another moment of fury

Back at work. This time my fury was inspired by Jack. He has been occasionally closeted with GandD over the last couple of months, and today he was demonstrating his cool new stuff.

Cool it may have been, but only in the sense of an approaching iceberg. We (in theory) have until the end of January to finish and test the latest release. Three weeks, loads of time isn't it? That could be my new nickname for Jack "Loadsatime".

For reasons best known to himself and GandD, they didn't want, well, anyone with experience of users, such as myself, training or support, to comment (or even know about) the new features until they were properly implemented. So this was the gleaming remove the drapery moment; cut the red ribbon and reveal the glorious finished product.

Except, is there a way of putting this tactfully? Except there is no point in asking for feedback on a finished product unless the only feedback you want is "Isn't it mahvellous dahling".

What is that there for? Oh, I thought it might be a good idea. Do users need it? I don't know. Is that very important bit that users might actually want to use easy to find? Well, it's obviously really easy, you just open this dialog and find that button and then set this option.... You can imagine the rest. And, given the fact that there is three weeks left, they aren't going to change anything at this stage, are they?

Admittedly, he did have three cast-iron and valid excuses
1. Gavin wanted it like that
2. David wanted it like that
3. It would have taken months to implement in a sensible way.

Well, maybe excuse no. 3 isn't that valid, because it hinges on that big elephant in the sitting room, well, not merely an elephant in the sitting-room, there's a volcano in the bathtub, a hyena in the kitchen, and fourteen zombies locked into the attic bedroom.

And they're all asking the big question?
How are priorities set?

Loadsatime Jack can't set them, because he does what GandD ask him to do. They have a difficult call to make.

First, they have limited development resource.
Second, they need to use it in a way that brings in returns

Some things, such as re-writing the whole thing from scratch, just ain't going to happen. Not unless we get a massive injection of cash from some venture capitalists. And GandD wouldn't sell their company unless it was sinking.

How can I persuade them that a project that is easier to use may be more worth having than one with more features?
How can I demand that a lot of that limited development resource is spent on making existing stuff better, rather than adding new stuff. At the moment I can't think.
But perhaps I could persuade them that involving the idea of the user earlier in the process would be a good plan. Before they decide which features go in, even. At the moment though, I think I'll just go out for a long walk and avoid the undead for tonight.

Hawthorne and placebo and real benefit

The Hawthorne effect (here's the wikipedia link: http://en.wikipedia.org/wiki/Hawthorne_effect) describes how any intervention has a positive effect. By paying people attention, you change their behaviour. Were I a Deepak Chopra or a dancing Wu Li master, I would probably relate that to the idea of Heisenberg's uncertainty principle or Schrodinger's cat because everybody thinks they know what those mean and they sound as if you're wise because there's deep maths in there somewhere.

Instead, I'm going to relate it to the placebo effect. This is much more straightforward, and is obviously used in medical trials. People are given a placebo treatment, which resembles the active treatment with the active ingredient removed, and the effects of the placebo and the active treatment are compared. In a double-blind trial, neither the experimenter nor the subject knows who has received the placebo and who has received the active treatment.

The reason this is important is because people want to believe that interventions work. One of the subjects I studied at UCL was affective interaction: how humans, computers and other devices affect each other emotionally. One of the theories expressed was the idea that humans are attempting to achieve homeostasis. You have an input of one sort or another, and you change your behaviour to achieve stability. One of the ways you do that is to tell yourself a story in which things have meaning and value. And one of the ways that things achieve meaning and value is how they fit into a culture. Tall people (on average) earn more money than shorter people. Good-looking people are more likely to get jobs, etc., than ugly people. We live in a world of admiration of beauty, where beauty is equated to goodness.

If someone tells us they are doing something to help us, we want to believe them (unless we are cussed and cynical creatures).

The vast number of self-help books, business-help books and teach-yourself books are sold to us by people who have persuaded us that they can help. We want to believe them. We listen to their advice. And the more we pay for it, the more highly we value it (just as the more we pay for wine or pain-killers, the better we think they are).

So if we are told that someone is coming in to tell us how to redesign a control room, and that person is being paid $5000 a day, then we react to it. And when the control room is redesigned, we react to that. But until the change is seen in practice, over time, we don't know if we are reacting to what we think is a valuable intervention, or to an intervention because it's a change and we have been paid intention to, or because it has actually improved things.

With any luck, that highly-paid consultant has listened and observed the people doing the work, and added their insights and experiences to the redesign. So when they complain that they knew this all along, and they could have told management how to do things better, they will have done so. And management will have listened because this time it comes with a high price tag that conveys its worth,

Preparing to return to work

It has been a long break for me, and I have mixed feelings about what awaits me on my return to work. Most of the other staff also took the week off between Christmas and New Year (though Jiri did not). I am slightly embarrassed to admit that I always feel that I should invite Jiri round for Christmas lunch and never do. He is probably perfectly happy on his own.

There is the standard stuff that always appears when you have had a break. The stack of problems that people discover because they're not really working but are exploring the software to have something to do. The new features that Gavin has invented while going on a long walk after an all-night party. The new contacts that David has made while playing golf on Boxing Day, and their suggestions for what is needed to penetrate new markets. The stale issues that people couldn't deal with just before Christmas so they put on the pile to be dealt with after Christmas when they would feel more inspired and less jaded.

All the tinsel that draped the stairs and monitors has been put away. Jiri is very happy because he managed to get an enormous amount done while the office was empty. The cleaners haven't been in over the new year so his desk is festooned with crumbs and empty packets of Czech festive items. Jack isn't back yet - he's gone ski-ing with his girlfriend. Mr Grumpy is in, and he is delighted to be back at work. For someone who complains so much, he seems to enjoy life far more than most of the people I know.

I promised that I would provide a systems analysis of the company and I am just considering how to do it. Like most small companies, it consists of a series of departments, each run by a manager. Departments contain some specialised staff and some people who have ended up there and learnt on the job. In a good company, the departments will be work-shaped. That is, a department has a function to perform and its staff and systems enable it to carry out the function within the department. That's easy if it's a closed function, but speaking from experience, every function will require (at the very least) information from the rest of the company.

For example, marketing has a big marketing push to carry out in the new year - get customers before the end of the tax year in April, when they're likely to have some extra budget to spend. Marketing need to know all the stuff about customers patterns of purchase (which is their own skill) and they need to feed that back into the company. They also need to know what the company is producing that they can sell in the new year. How do they do that? Do they get the over-optimistic views of GandD, or do they get the more realistic views of Ian? Do they have to come and chase and check whether what they have been told is true, or will the right information be passed on at the regular meetings? Have they got the experience to discount GandD's over-optimism, and if so, how do they know which bits to discount? This is not something that can be codified, because the (say) 30% of stuff to discount will change each time? This is skill, but to be able to learn the skill, you have to know what goes in and what goes out. You have to know at what point the product starts to stabilise and you have real information to deal with. And from that, you have to find out what customers want and feed that back into development.

So marketing has several roles:
1. To sell stuff to customers (this is how it's seen within the company, anyway)
2. To understand what the company produces and when it will be ready
2. To understand what customers need and when they buy it (that's their own skill that enables them to do their job)
3. To tell the company what customers need and when they buy it
4. To create a trustworthy competent public image for the company

Now Jeanette is fabulous at selling. She's pretty good at knowing what the company produces and how much of GandD to ignore. And when to ask them what is actually happening. And when to tell them stuff is a waste of time. But I'm not sure how much all of her knowledge about customers - why they buy, and even more importantly, why they don't buy, filters back into the company. Should it? Can Jeanette's sense of what people want be as important as what David picks up on the golf course?