The hard parts of designing for users.
,
I’m a computer nerd.
I’ve compiled Linux and BSD kernels from source, I’ve written XML libraries from scratch, I’ve helped circumvent DRM in printers so that they can keep working after reaching a software-defined end of life.
I used StarOffice and then OpenOffice to write all my notes at University — sticking it to the evil man from Microsoft by supporting open source software and open standards. I wrote code in GNU Octave instead of Matlab for the same reason.
But as I’ve got older, and as I’ve built more software and services for the public and private sector, I’ve changed.
Moving away from open.
By the middle of my PhD I’d got so frustrated with things not working that I ditched Linux, Perl and Python and I was publishing software written in Microsoft Access and Visual Basic. By the end of my PhD, I’d ditched Latex and BibTeX and I wrote my thesis in Microsoft Word, with help from Mendeley for references and Excel for figures. I stuck with open projects that worked — a Wikipedia page I wrote to summarise my thesis for example — but ditched those that didn’t.
Today I spend around £100/month with Microsoft, for a combination of Microsoft Office, OneDrive, Azure Cloud Services, and Azure servers running both Windows Server and Linux. I use Windows on my laptop, and I sell software through the Microsoft Store. I write much of my software in Visual Studio, C#, and .NET. When my code is written in the beautifully open HTML5/JS/CSS, I still tend to work in Adobe’s Brackets. I prepare my figures in Photoshop Elements or Inkscape, whichever is better for the task. I browse the web in Chrome and Edge, not Firefox. I use Google Charts as often as D3 for data visualisation.
Why did I make this change away from open for everything, to open only if it works best?
Be a user, get close to users, work with people even closer to users.
The common theme in my change is that I’ve watched how people do things, talked with them about what they’re doing, tried to do them myself, worked together on the problem, and then built the improvements that we want to see.
There are no personas or user journeys. If you start at a large distance from the user, these techniques are good for getting closer. But they can be much more expensive and slower than alternatives.
I find it better to work on small budgets, start closer to users, or be helped to get closer by experts who are close to users. I find it better to release early and often, listen, and keep improving.
In public sector projects, working with local government is a great way to get closer to users than working for national government. In commercial projects, working with experts on the ground can get me closer to users without adding much to costs. Working in the open, using tools like Google Docs, Word online, permanent project summaries on the web, Youtube streaming, twitter, facebook, and disqus, are also great ways to stay close to users.
Be more specific. What are the specific changes we should make?
I’ve been doing a lot of interviews recently. People keep asking me how we create more and better services and software using open data, especially in the public sector. I think it’s useful to have a couple of concrete suggestions for them. And since I work in the open, I’ll share them here.
1. Kill ODS
First, a specific and easy fix to show that people who publish and consume open data are serious about users — let’s give up on .ods. This alternative to Excel spreadsheets isn’t what people want.
Power users of data mostly want a .csv. Normal users of data mostly want an .xlsx. Excel’s default format (.xlsx) has been an open standard for over a decade so “but open” is not a reason to ditch it any more.
Of course .xlsx has all of the problems associated with spreadsheets — data destruction through auto-complete, leaks via hidden data, formatting obscuring machine-readability. But none of these problems are fixed by switching to .ods.
The .csv format has problems too — larger file-sizes, Windows vs. Unix line-endings, culture-variant delimiters, harder for most organisations to publish. But its machine-readability makes up for them.
.ods doesn’t fix any problems. Whenever I see it today, I see evidence that technical people like me have become detached from users. We should ditch it.
2. More politics, fewer personas.
Second, the people building services should put down their personas and get closer to the people.
This does not mean “getting the train from London”. This does not mean inviting people from elsewhere to meetings in London.
Both are good, but they are not nearly radical enough.
Organisations like GDS, DCMS, Nesta, and the rest must find ways to step back from some of their own work, look at where the UK’s cuts have fallen hardest, and get their money in the hands of local government.
Public service innovation overseen by Councillors, Mayors, and their officers is a fantastic way to get close to the people. They live their lives in the communities we want services to reach. They work within the local government and business ecosystems that deliver local services.
I am convinced that empowering local government with significant amounts of money will deliver more improvement than more personas and user journeys collected by national government. We should try it.