The joys of cardboard

Yes, I did not write anything yesterday. I suppose I should start upping the blog’s excitement to build up a devoted fan base, but let’s face it, why would I want a devoted fan base.

So what happened yesterday that kept me so busy?

I gave a presentation (Yay!). This was supposed to have the twofold benefit of encouraging people to prototype to “define the design space” and also remind people that I do exist, I do care about usability and I am an exciting, rewarding and entertaining speaker.

Any of you people out there want I an exciting, rewarding and entertaining speaker? What, neither of you? Oh well, keep me in mind when you want to enthuse about the joys of cardboard.

Joys of cardboard, you enquire, what could possibly be joyous about cardboard? Well, plenty. It’s low-tech, it’s cheap, it’s flexible, and it’s perfect for rapid prototyping. With the aid of a lot of Sellotape and a Stanley knife you can create almost anything. Of course, it won’t work, (well, unless it’s a cardboard chair or a speedway track for rats), but it gives people ideas. And it clarifies your own ideas. And you can do fitting trials on it.

(Fitting trial, what on earth is a fitting trial, you enquire, that merely recalls the days when my sister was practising her dress-making skills upon me and involved me standing still for long periods while pins were inserted in random places including my flesh). A fitting trial is a practical test to check what can or cannot be reached by the population that you are dealing with. So, you set the percentage of the population that you expect to use your device, age, sex, disability etc, and you check to see if they can, can that unusually tall chap see the screen? Can that bent over elderly person reach the buttons? And so on and so on. There is a useful book called Bodyspace by a chap called Stephen Pheasant that covers much of this. It’s physical ergonomics and is important when you’re designing a real object to be used in the workspace. Of course, it can apply to virtual objects too. Are they accessible by the colour blind? Are the buttons big enough for clumsy fingers… and so on and so on.

Anyway, as I stated earlier, my main purpose in hymning the joys of cardboard (and paper) were to try and get people to start thinking and expressing their design before they became engrossed in coding it.

Did it work? I think you know the answer to that, no, no and again no. But I did start reading a coursera course book. The course is Design: Creation of Artefacts in Society (so obviously I’d find that interesting) and the book is by the guy who produced the course Design: Creation of Artifacts in Society or go to: OR

I like design ideas. I doubt that I’ll actually do the course, but I have this sad weakness for education. New stuff to learn. Wow!, How much can I sign up for. Yay. And it’s free! I’m like a small child offered free sweets – keep stuffing them into all my pockets and my jumper until the scatter all over the floor and I eat so many I’m sick and have to lie down in a darkened room for a while.

But I do hope that I can get people to re-design their way of designing. Even a little bit. Even just to be clear about what they’re taking for granted and what question they’re asking.

Marketing, what marketing?

Someone asked me if there was a marketing department at this company, because they thought it was a bit implausible that there were that many engineers but no marketeers. Well, yes (you know who you are), but I’m not totally au fait with what they do.

Obviously I know about what they do: they redesign the website, they write blogs, they keep up a presence on twitter, they go to shows, they take out advertisements in appropriate places, they check whether it’s worth being in google AdWords, they buy lists of GPs, they talk to previous customers and so on and so on.

But I’m not sure what they actually do. Is this because I’m  incredibly lazy? Or incredibly uninterested? Or because the summaries that appear in the company newsletter are not terribly informative? Or because (whisper it) communication in this company is absolutely dreadful.

To be fair, communication in most companies is absolutely dreadful. People always thinks there are secrets going on behind their back. The urgent strategy planing meeting that had the head of marketing (Jeanette), Gavin and David in it and we never heard what decisions were made. This may, of course, be because no decisions were made, but I know that Jeanette was trying to get GandD to commit to what was going to be in the next product so she could splash out for ads in the Lancet…
And GandD wouldn’t bite.

Jeanette is one of those women who make me feel tired just to look at her. She’s slender and blonde and wears boots and looks amazing at all times. She can sell hot air to Parliament and bull terriers to babies. And she seems to be permanently on a motivational high. “Come on team, let’s see if we can get another ten orders by tonight” she’ll say, “Who’s with me?” And when she has a spare minute she’ll be running marathons for cystic fibrosis research or jetting off for a spa week on a Greek island to cheer up her sister-in-law.

Jeanette is busy seeing how we could alter the product so it would be suitable for care homes and private secure units. She’s looking at what regulation is coming out of the government about what these people will need and she reckons that there’s a huge untapped market.

And David agrees. There’s a whole lot of legislation that needs to be chewed down and flagged up, what your levels of staffing need to be, how many people you have on your books, where you can make things more or less efficient, how you rotate your on-call staff, how you can manage handovers effectively. We could integrate it with a little mobile note-taking system that doctors could carry with them when they go on call so they could…. And so it goes on. Questions of data security and encryption and touch screen infection issues….

And Gavin loves all that. He’s quite keen on encryption and security and new ways of setting it up. And can we get secured prescriptions sent directly to a chemist for an out of hours call… and so forth and so on. I don’t know the ins and outs of it. I would love to shadow a doctor or two and see what they actually did and what was really needed, but we don’t have time for that, says David, we know what they do, we know what they want, we just have to produce it. And if you developers weren’t so inefficient we’d have a product by now. Didn’t you estimate that it would be finished by September so we could test it in time for the New Year and it would be ready to go when people are spending their budgets left over from this tax year?

“Yes” says Ian, “But you’ve changed the spec four times since then.”

Why do I think it happens like that?

When you’re creating a new product, it’s like the band’s first album, or a first novel. You can put all your best work into it. All those hours of sitting in a back room, thinking of how it should work while you’re supposed to be doing something else. All those evening hanging out with your mates and discussing it (for a band) or those rich ideas that have bubbled up for years (for a novel).

Then comes the new release. It’s the follow-up; the second album that flops or the second novel that arrives with hype and leaves with its tail between its legs and an apologetic wet spot on the floor.
(Of course some of it is straightforward regression to the mean: great one time means more likely to be not so great the next.)

In both cases, you normally have a clue what it’s like when you make it, but it’s only when it’s bought that you really understand. People react to what you’ve done. And software is interesting, because it’s a tool. Users use it. They don’t just listen to it or read it. They want to make stuff happen with it. And what they want to do may or may not be what you think they want to do: or even what they think they want to do.

They find bugs. They find things that they want to do and can’t. And if you’re lucky they phone up the support desk or email in or write on forums so you can find out what their problems are.

So, in your second release you fix the bugs (obviously) and you add some of the features that youwanted to put in the first release but couldn’t, and you put in some of the features that you discover that users really want that you never thought about. And that is where it all starts to go horribly, horribly wrong.

Let us imagine our basic Dalek with exterminate facility. You have choices when working on the upgrade design:
a. add levitation to deal with the “cannot conquer a world containing steps” problem
b. assume that wheelchair access will become normal so that Daleks will learn how to campaign for it c. point out that Daleks were never designed to conquer the world, they were designed to be defeated, so use them in the way they were intended
d. redesign the sink plunger
e. offer people a re-badged helicopter that can carry Daleks

Gavin, obviously, wants to add levitation, because that is the correct solution and it has interesting coding challenges. David wants all the other things because they are fast and cheap and there is a massive mark-up on the helicopter. Nick would like to work on levitation because that is an interesting problem, but he designed the first sink plunger so he knows that he will be the sink plunger re-designer. Mr Grumpy and Jack are supposed to be fixing bugs. Both of them have a talent for introducing new bugs. This is because they don’t realise the side-effects of their fixes. Mr. Grumpy doesn’t always bother to find out how the code he is debugging is supposed to work, so he breaks other bits while getting the first bit to run smoothly. In Jack’s case it’s just because he writes it badly. Jiri has already started researching levitation techniques and has found an interesting paper that implies it can be done very efficiently if you can redesign the Dalek so it doesn’t require a sink plunger.

Ian tries to find out whether there is going to be levitation or not. He knows that Gavin and David are arguing about this and whichever one he meets in the corridor will tell him something different. He sits down and writes the spec as he understands it, so at least there is something for all the developers to do until the decision is made.

And I try and find out if users actually want levitation, or whether they really want to use the Daleks as pest controllers and would like a fumigation option.

How did I get into this anyway?

A quick summary of my trajectory into user experience:

  1. Write embedded programs to control freezers. Try and make them suitable for maintenance engineers to use: i.e, give clear info easily
  2. Describe programs and write manuals
  3. Become a full-time tech author
  4. Train and write training courses
  5. Become very aware of what users had problems with
  6. Work for software companies
  7. Realise that whenever I couldn’t describe something easily, that meant it was poor design
  8. Try and persuade engineers of this
  9. Do an MSc in Human Computer Interaction and Ergonomics in an attempt to convince engineers that I really did know what I was talking about
  10. Lie on floor and bite carpet.

No. Omit the last step. I have never lain on the floor and bitten the carpet. I have been tempted to, frequently. I have succumbed to offering engineers chocolate, looming over them, complimenting on their English skills and wearing fairy wings. But not carpet-mastication. Yet.

My current problem (the one that is making me consider taking a quick chew on the washable wool/acrylic shagpile) is how to get people to think about what a user does as opposed to what they do.

In fact, to understand that users are people too. I sometimes feel as if I’m trying to explain to a Daily Mail reader that there might be a reason why people are in debt that doesn’t involve feckless spending on alcohol, tobacco and Sky sports.

Yes, users are not interested in how wonderful and clever your product is. They don’t care. They just want to do their job and then do something that they find interesting (which may, of course, involve feckless spending on tobacco, alcohol and Sky sports). They may have to run their payroll while a patient is vomiting in the waiting room and two doctors are off sick and someone has forgotten they’re the on call doctor that day and their car has broken down and they’re thinking about their snowboarding holiday. They do not have a calm uninterrupted environment to set up the best possible way of doing it. They just want it done and out of the way as quickly and effectively as possible: in their terms, not ours.

OK.  Developers might agree with this, briefly, but they don’t have time to make it any simpler because they have to get a new release out. And they need the new release out because the sellers have to have something to sell so that we have money coming in which will ultimately pay for my tobacco, alcohol and Sky sports habit. And how does it get decided what’s in the new release?

It gets decided by David and Gavin, chatting about what they can do and what they think is cool and what they imagine people might want because one of them saw something like this last week on a website and thought that’s a good idea and our competitors are doing it anyway. If they were designing Daleks they’d have vampire teeth and a six pack because they’d heard Twilight was making a fortune. And they’d produce a full working prototype of a Dalek with vampire teeth and a six-pack. Not a wireframe or a sketch or even a mock-up. No, because it will be brilliant and they need it by Christmas so they can’t afford to waste time. And they’d get all the engineers to stop what they were doing to redesign the Dalek head set to fit in those vampire teeth. And to rewrite all the libraries to make them incorporate a blood-drinking ability. And then look at the results and say “That’s not what we wanted at all”.

At which point the temptation to fling myself to the floor and get a mouthful of tufts is quite high.

That elusive work life balance

I was going to post about all the wonderful people in development in that Suffolk company, but I felt the need to side-track for a moment. Why is it when talking about work-life balance it’s all about picking your children up from school, taking them to dentist’s appointments or watching the little dears at the school play. There’s never trying to get yourself into balance after being told “I wish you’d fuck off and die” by your teenager before they storm off for school and you have to go to work. Everyone else’s children are  amenable little things, who might possibly be ill and need a lovely caring parent to hold their head while they voimited into a bucket, or need to be ferried between their violin lesson, their karate and their advanced programming course.

I look round at the developers and I wonder what will happen to them. Most of them, (four out of six, if you include Gavin), are single. Whether this is because they are painfully shy or whether it is because they have not yet found a woman who is deeply interested in Star Wars X-wings modelled in lego, I have not, as yet, been able to find out. Of course, that might be a hunt for another man who is deeply interested in Star Wars lego. I wouldn’t like to make assumptions about any of these people’s sexuality. For all I know they are secret furries.

OK. Here are the developers. In order of developoriness. Most extreme is Jiri. He is from the Czech Republic. He likes wearing black. There is a rumour that he is from Transylvania and cannot go outside in daylight, but apart from that he has nothing in common with film vampires. To start with, he has bad hair. He loves algorithms. And Diet Coke. He sits as far away form the other developers as he can. This is possibly to justify the way he shouts very loudly when he wants to encourage people into sharing his point of view on such matters as the level of code indentation.

 It’s at this point that I feel that I should point out that the developers haven’t all been men. There have been women. They just leave. Generally after about a year. They come in bouncy and bushy-tailed and confident, and you  can see the sparkle go out of their eyes and the gloss leave their hair. When it returns you know they’ve had a successful interview, and they will soon be moving on.

Then there is Nick. Nick has a beard. It’s not a very successful beard in the world of beards. He’s not going to manage Father Christmas or even Charles 1st. But it is definitely a beard. Nick probably has a point of view on many things, but it is very hard to extract it from him. He has been working for the company almost since start-up, and has found his niche. Extracting him would probably be like extracting an unwilling kitten from a wellington boot; it can be done, but at severe cost to all concerned

The first one in the non-single stakes is Jack. He is still quite young. He roller-blades. And has bouts of enthusiasm for all sorts of things, ranging from software to apple pie recipes. He’s not really a very good coder, but he has a girl friend. And he’s a Christian. I still haven’t worked out what sort, but there is no doubt that he is a firm believer and goes to church.

Jack has the good fortune to sit next to Mr Grumpy. Mr Grumpy is divorced. He has worked as a contracter and resented paying a large section of his pay as alimony, so he has moved into the world of paid employment on the grounds that his ex-wife has no rights whatsoever to his pension contributions and his private health insurance. Mr. Grumpy knows that whatever innovations have been suggested have been tried in one of the other myriad companies that he’s worked in and they didn’t work there. He does at least have a scathing sense of humour and a willingness to do what he has been asked to do (on the principle that it won’t work anyway so he might as well waste his time with that as anything else).

Then there is the lead developer, Ian. Ian is married. And has children. And is calm and competent and willing to try and make things work. Ian is probably the wheels on which this company runs (and I am sure that his children will never swear at him before he leaves for work).

And finally, of course, there is Gavin, he of the fast cars (he has just bought an Aston Martin), high dividends and absolute knowledge that he is the cleverest man in the building. He has a weakness for designer shirts that look like Mao jackets. Because Gavin owns half the company, Gavin’s opinion carries quite a lot of weight. And did I mention that he is the cleverest man in the building? Jiri might fight him for that position, but Jiri is handicapped by not owning half the company.

These are the people whom I must persuade to redesign their interfaces so that they can do simple things easily, instead of complicated things ingeniously.

So this is November

I’ve just been to the IEHF careers fair. It wasn’t exciting. To be frank, it was extremely unexciting. The high point was a discussion of the ergonomics of samurai armour. Who knew that the shoulder flaps were to confuse the eye?

I came back from it in the rain, determined to record something about life in a company that isn’t really interested in a better user experience. Or rather, is only interested in a better user experience for the director.

I expect there are a lot of companies out there like that, so we’ll invent the company. Let’s say it’s a small company in, oh, pick a random place in the country that I know very little about – let’s call it Suffolk. We’ll assume it’s a software company, because I know quite a lot of software companies. Let’s pretend that they make something which is used occasionally by a lot of people who aren’t really interested in it. I know, it can be some small business accounting package, which is marketed to doctors’ surgeries and the like and is specially geared to people working all sorts of weird hours.

The company was set up by two guys. (No question, they’re guys.) They’ve known each other since school. One is glamorous and good-looking and all that sort of stuff, but is really rather interested in money and success. Let’s call him David (any resemblance to anybody currently in power is totally coincidental). He feels pretty confident about his software ideas because his mate, Gavin, is a really, really techy person.He’s not a total geek, he skis and likes fast cars, but there’s no doubt that he loves coding and he loves cool stuff and he is very, very bright.

And it’s been a success. David is good at selling ideas and knows about the issues around small practices and large patient numbers and how you manage all the shifts and payroll and stuff like that. And Gavin is a whizz at software. Their company has expanded and they’ve now got sales people and a human resources person and about six developers. And they’ve rolled out more products and they are happy happy people.

But, their client base has changed. They’re no longer dealing with people who are spending a lot of their time in setting up systems and running systems. They’re dealing with people who want to run a payroll program once a week or a report once a year amid a ton of other things that they need to do.

And they want their program to be whizzier and faster and cooler and better. BUT even though their program is amazing and you can set it up to do everything you want to for ever and ever in the most complicated ways possible so that their clients can personalise it down to the last acorn, they’re losing market share.

So they sort of realise that they need to make it easier to use. And that is where I got involved.