City of Bits
Louise Ferguson's news and views on technology, usability, user experience, ethnography, paper, the workplace and public policy
Tuesday, June 01, 2004
Necessary online transactions?
This week's eGov Monitor reports that local authorities are behind the game in offering online transaction serices. "Provision of transactional services, particularly those relating to application submissions, are also seen to require considerable improvement."
Given my most recent transactional experience, I'd rather that the public sector offered fewer transactions that actually worked as intended. As I'm not going to be here on election day, and as experiment to find out more about the process, I decided to register for a postal vote. This required clicking through eight pages, and filling out personal information, in order to get a personalised form....which I then had to post to my local authority.
Except after I'd entered all my data and moved to the final screen, I found that the link provided to download the personalised document didn't work. My document had disappeared into the wild web. I then backed up eight pages - great thing, the back button - to find that elsewhere I could download a non-personalised form to similarly post in.
I probably won't get the postal vote anyway: it seems that postal votes may not be sent out until just four days before election day - according to the Electoral Commission website - by which time I won't be here, and the ballot has to be returned by election day (so send and posting from overseas is not feasible). I though postal voting was about making things more convenient, but frankly I'm not convinced, if this is the experience for the postal voter. The housebound voter may well benefit - although a form needs to be signed by someone else, so the single housebound need not apply - but the voter temporarily away from home will not.
With the process so limited, is it even worth creating a personalised online transaction? If we are to have postal voting - and there are issues concerning security - it seems to me to make more sense to invest time in rethinking the process that is presented to the voter.
An interesting BBC Radio 4 programme about eBay this week, which went into much more detail that the usual media coverage.
Check out this and other BBC recordings indexed on Chris McEvoy's UsabilityViews website. Chris tells me he now has more than 172 hours of recorded material indexed.
I'm doing commercial fieldwork at the moment, and shall be speaking on 'Why do fieldwork?' at a business-focused (rather than academic) conference in Minneapolis next week. So my mind is fairly concentrated on the subject.
One of the questions raised by the Minneapolis organisers is 'how much can you rely on other people's studies?' Good question, and it's linked to the issue of doing team fieldwork and then bringing the results together, and then reporting them to the client.
Perhaps the analysis and synthesis process - in the area of rapid ethnography/commercial projects - is the area where we need to focus effort to develop useful yet cogent material for clients.
Traditional anthropological reports from the field are extensive texts, pieces of careful writing providing an account of an experience. These are all well and good within the academic context, but don't work within the business world. In business, information representation is almost the antithesis of the ethnographic report, with much summarised data, preferably representated in visuals. Anthropologists, however, are rarely 'visual people'. We need to extend the repertoire of visual tools for representing ethnographic research.
The NIST report (US) on an approach to e-voting standards has been published, under the auspices of the Electoral Assitance Commission. It could perhaps serve as guidance for people in other jurisdictions considering e-voting standards (there are virtually none anywhere in the world, as far as I can glean). There's good coverage of the current state of standards, and the issue of guidelines versus standards, and how/why they should differ.
Thanks to Whitney Quesenbery for keeping her eye on these developments.
Since the publication of Nicholas Carr's article 'IT Doesn't Matter' in the Harvard Business Review last year, there's been a great debate on the value of investment in IT.
Carr argues that IT has become a commodity, just like electricity or water, with the consequence that there's no competitive advantage to be had from it. Firms should therefore reduce their investment in IT, he says.
Microsoft, Intel and other industry players have been keen to counter Carr's arguments, going so far as to sponsor the launch of a new research body dedicated to demonstrating the value to be gained from IT investment.
Carr now has a book out, with the somewhat less provocative title of 'Does IT Matter?'. This essentially reiterates his arguments from the HBR article. The business and IT press has dived back into the debate, with John Naughton in today's Observer being one of several commentators.
Well, not really commentators - none of these people are actually adding anything to the debate, just presenting the two sides.
My own view is that Carr - who does not have an academic or business background, but held an editorial position at the Harvard Business Review - is somewhat misguided, while MS & Co continue to take simplistic approaches to IT.
First, what is IT? Sure, IT is a load of boxes with silicon chips. So far, so commodity, so much like water or electricity or kettles or kitchen ranges.
But IT boxes cannot be disassociated from context; it's what we do with IT. All IT is situated. We take boxes and cables and give them to people to work with. But not 'as is': we arrange and connect boxes in a work environment, build networks that make sense in that environment, write or adapt software for that environment, put lots of different software tools together for those people....In other words, we design something that incorporates IT boxes, and that also incorporates people and their environments. IT is not just boxes. And 'investment' in IT generally involves spending more money on people than on boxes.
When we put in IT systems, we 'design' with IT boxes, for people, to produce an IT environment who's intention is supposedly to enable tasks to be more easily carried out, and so raise effectiveness. This design involves everything from deciding what to automate and what not to, to deciding what to call every field, where to put it, and how it relates to everything else in the user's environment.
But design, designers and people are not commodities. We can design well, and we can design badly. We can design for people, or we can design to meet sub-optimal policial demands in the firm. Depending on how well we design, IT can add value to the firm, or destroy it.
Think of a good cup of tea: the electricity and the kettle are both commodities, as are the teabags, the water and the milk, but finding a good cup of tea is not guaranteed. In fact it's quite rare. In some countries, it's almost impossible. Someone ususally under-brews or stews it, while other tea-makers even manage to boil the kettle dry. Teabag standards vary tremendously around the globe and fresh milk can be a rare commodity. And if someone's cleaned the teapot with bleach, there's no way you're going to get a good cuppa, regardless of electricity, kettle, water, teabags and milk.
Tea-making is a simple process, you would think, but still leaves room for many things to go wrong. Somewhat more complex are the systems introduced into organisations. Here, the room for failure is almost infinite, and the consequences somewhat more serious. Take one example: in the UK, there's a major project to generate a data 'spine' for individual healthcare records, along with a drive to merge data from health systems run by the National Health Service with social services systems run by local authorities and the voluntary sector. But take one element: informal support services such as community drugs agencies often use only people's first name (that's all they need and all clients want to give), whereas health sector systems have a raft of identifying data (necessary for risk management when conducting medical procedures). How are the needs of the two user groups to be supported from the same datasets? More seriously, what happens to your expensive system system if you haven't done any user research and don't realise that the drug agency and other records only include client's first names, or even nicknames?
In organisations, the usual attitude towards IT investment is that boxes are one-off commodities, whereas people are a recurring expense. Decision-makers so often prefer to spend money on physical boxes - maybe that tangibility gives them comfort - rather than on ensuring that people can work with systems, which is the real challenge. This is perhaps a view promoted by the computer press, always eager to review the latest gadget, and always eager to believe - and publicise - the frankly preposterous claims of IT vendors.
So we get a system that virtually nobody uses, despite it being classified as a 'success' because the implementers did in fact manage to get the system put onto desktops (though everyone uses much faster off-line work-arounds). Or we get vast amounts spent on a new system that increases time spent on essential regular tasks by 4700% compared to the old system (I kid you not). When staff put off issuing company bills for weeks because of frustrations with the billing system, then it's bad news for the company concerned: for its bank balance and its future. In clinical healthcare, the consequences may be more than monetary.
Investment in IT is not about investment in boxes, and anyone who still believes that is doomed to failure, and their company probably destined for the receiver. It's about designing something that works well for people. Design will never be a commodity. It's based on user research. It's dependent on the existence of empathy and an open mind, and on the application of intelligence and experience to the design process, which needs to be user-focused. It's based on a thousand different things being done in such a way that the people who have to use it are comfortable doing so, and may even want to do so, to get the job done. IT in business, in healthcare, will never be fun....but it needs to deliver for the user.
IT boxes - servers, desktops, laptops, cables, PDAs and all the rest have become commodities. In this sense, Carr is right. But my question is : so what? Systems design - and system incorporates people and environment - is not a commodity and shows no sign of becoming one. And it irritates me that Naughton - and dozens of others like him - fail to concede that IT is anything other than server farms and desktops. In his article, Naughton refers to the cheapness of Google's rack-mounted units - but fails to refer to Google's user experience. Google's USP is not its rack units: it's the amount of work that goes on to design complex systems that look incredibly simple to the user. It's all about design. Google employs user experience people, takes user experience seriously, and it shows.
My hope is that one day we can move away from this situation where user research, user experience and user-centred design are ignored by business people and technology journalists alike. But I'm not betting on it. In the meantime, I shall continue making most of my income from being called in to sort out IT design 'issues' (to put it politely) after the event, and the minor part from contributing to the design process. Ah well...
The last week has seen serious concerns raised by most political parties in the UK - except that in government - about the all-postal voting 'pilot'.
With the government finally pushing through the pilot in four regions (all in the north of England), rather than the two recommended by the Electoral Commission and supported by other political parties, the problems have not exactly been unexpected.
Well-known printing firm De La Rue - known for printing banknotes and other high-security documents - reportedly refused to tender for the job, saying that the timescales were too tight and that there was not enough printing capacity to do the job properly.
Recourse was made to other firms. Incorrect ballot were printed, the quality of printing has been called into question, and large-scale reprinting has had to be undertaken for some areas. Some users have reported that printing has been so bad that the 'grey' side of a paper cannot be distinguished from the 'white' (colours referred to in the instructions).
To make matters worse, those living in the UK will be aware that the Post Office is providing a poor service right now, with items going missing and being mis-delivered on a regular basis. (As an example, I'm currently waiting for company documents, a book parcel and a large cheque, all posted more than three months ago, while clients report not having received material posted first class. I receive mail for neighbouring properties at least four days per week, and have just been awarded compensation by the Post Office for yet another cock-up.)
The deadline for 'issuing' ballot papers (to the Post Office) is 1 June, but apparently the legislation does not cover when these ballot papers should be delivered to voters. It looks as if a significant proportion of voters may well receive their voting pack after they can do anything with it.
As with so many projects and systems, decision-makers often seem to assume that the decision to take action is the very same thing as the action or process. That by deciding something, somebody, somewhere will magically sort it out and make it happen. Instantaneously. The contraints of the physical world so rarely seem to impinge on the thought processes of such individuals. This is so often the reason why we end up with bad design, late project delivery and system mess-ups.
With an increasing number of new books from major international publishers it's proving difficult to get a copy out of Amazon UK: "hard to find" they say, "may have gone out of print" perhaps, even for books recently reviewed on mainstream media (you can't get more mainstream than the BBC).
My latest efforts include two recently published books (one in December). Months after placing the orders, there is still no sight of the books, and no word from Amazon about when they might think fit to dispatch them.
The marketing department of one of the major publishers concerned (US in this case) is equally perturbed. Its international sales manager has written to me today concerning a book written by one of their Europe-based authors, which I've been expecting for some months now, as follows:
"I am equally perturbed at Amazon about this and have tried my best to communicate this to them. Of course, as a publisher, we have little control over how they choose to stock their various warehouses around the world. They have apparently run out of stock on this title in the UK and are informing readers there that it is "hard to find." This is simply untrue. Amazon.com in the US and even Amazon.jp in Japan can both ship in 24 hours. The book is also readily available to individuals and booksellers through our UK distributor [names major major UK publisher]."
Others of my acquaintance have been pressing for the same titles for months, without any joy.
Poor stock management and crap service. What more could you ask for?
PS this evening, I finally received a formula cut-and-past response from Amazon. God, how I hate these ("You will notice that there is some crossover between the Amazon catalogues..... some items being available for order at more than one of our websites..... This is possible due to fluctuations in availability." ....go the formula paragraphs....)
Amazon has written to me about this order (yes, but about a different book in a 2-book order - even more of a ridiculous timescale for a widely available book). It has managed to 'procure' something-or-other, it promises...but still no sign of a despatch date. Still no sign of anything being delivered among several orders, all outstanding for months.
When is a feature not a feature? When people are too scared to use it
I blogged a few days ago about India's take-up of voting machines. The feature that allows permanent closure of the device "in the case of booth capture" seems to be a complete waste of time. In the NY Times (27 April), David Rohde reports that "booth capturing" has also modernised:
"...In what appeared to be a carefully planned series of events, two small bombs exploded near the polling place and party workers threatened the five policemen guarding the booth and then brazenly took control of it. As poll workers and policemen averted their eyes, young party workers pushed the button for their part on the electronic voting machines over and over again, casting vote after fraudulent vote."
Margaret McGaley has been in touch to say that the Irish government has abandoned plans to use e-voting equipment in the upcoming local and European elections. The decision comes in the wake of an adverse report from the Irish Independent Commission on Electronic Voting.
"The commission emphasises that its conclusion is not based on any finding that the system will not work, but on the finding that it has not been proven at this time to the satisfaction of the commission that it will work," says the report.
A few days ago, the Royal Academy of Engineering and the British Computer Society published 'The Challenges of Complex IT Projects'. There's considerable criticism of current practice: in general, those in the sector know what best practice is, but fail to follow it, according to the report.
Usability gets a few mentions (2 to be precise), as do the poor old users. Though user-centred design is not explicitly mentioned, there is some criticism of the 'waterfall', or sequential approach to projects, and support for iterative development.
Fred Brooks' Mythical Man-Month, originally published in 1975, gets quite a few supportive mentions. As the report states, "Despite its age it contains observations and advice of great relevance to current projects, which in itself is telling."
By the way, there's an improved anniversary edition of MMM, containing a number of later essays, including the widely cited 'No Silver Bullet: Essence and accidents of software engineering'.
All too often, a major problem is the decision: what to design? I feel the issue of requirements gathering gets inadequate treatment in the report. It was, after all, Fred Brooks himself who wrote, "The hardest single part of building a software system is deciding what to build...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later".
One recent UK example of failing to research user requirements was the Criminal Records Bureau system, designed to provide obligatory criminal record checks for prospective teachers, social workers and many more employment groups. Designed by the contractor as a call centre-and-website to deal with individual applications, only as implementation was imminent - and the marketing roadshow in full swing - did developers talk to potential users of the system...and accidentally discover that the vast majority planned to apply for checks in writing (probably to cover their backs in this legal minefield). Nor had developers figured out that applications from user locations would be submitted not individually, but in groups (mostly because every applicant or interviewee for a particular job would need to be screened at precisely the same time - say, by the headteacher or other hirer). Some things seem so obvious when you find out about them...
