So, what is user engagement, and why do you need it?
Put simply, user engagement is talking to people who use software. In fact, it's not just limited to software, or even computing. User engagement is key in pretty much every field. Any time you are designing something that other people will use - it could be software, a washing machine, a coffee shop - you need to engage with your users. If you're selling something you might call it market research, and if you're into formal project planning you might use the word stakeholders rather than users, but the principle remains.
In software design it's particularly important: if people are going to use your software it needs to do something they want, and it needs to do it in a way they can use. This may seem like common sense; you're probably sitting there wondering why I'm teaching you to suck eggs. Problem is, a lot of large organisations, in both the private and public sector, don't take user engagement that seriously. The field is neither well-defined nor well-understood, and teams often struggle to decide who their users are, how to approach them, and even who is responsible for doing so. Sometimes this means that users get software that theoretically meets their needs but is very difficult to use, but can also lead to very good software that simply isn't needed.
Before I got my current job, I was a developer. I wrote web-based software as part of a small, self-contained team at a large educational institution. Our major client was a national public sector organisation, and our main product for them was used by thousands of people across the country. It wasn't a complex or fancy piece of software, but it was used regularly by a lot of people as part of their day-to-day job. And I hardly ever got to speak to anyone of them. I had no idea if my software was good at what it did, or worked how people expected, or was easy to use. I could make a reasonable guess that it did actually work, because I could track how many different people were using it and how often; so I knew it was being used. But I had no idea how anyone felt about using it.
While I was working there my boss had two big ideas - he wanted to introduce a new piece of software that supplemented the existing one, and he wanted to do a major redesign of the existing piece of software to make it more visually attractive and user friendly. This seemed like a great idea to me, and I offered to set up a variety of ways for users to provide their input to the process. You can probably guess how much user engagement we did in those projects by the fact that I've chosen to make an example of them in my blog.
The new supplementary system was designed based on a loose set of requirements provided by the client and interpreted by my boss, and I didn't get to speak to a single potential user about whether they wanted or needed this system, how they might use it, and what it might do for them. Based on the number of people who used the system after it was launched (and harking back to my second paragraph), it didn't do something they wanted, or didn't do it in a way they could use, or (probably) both. Curiously, however, since we did launch a piece of software that did something, the project was considered a success. This unusual definition of success is, sadly, prevalent in the IT and software world.
The system redesign eventually fell to a different developer. With no brief or requirements, he simply created a design he thought looked good. The first any current or potential users knew about it was when a public beta test opened. Users numbers didn't really change with the new system, but then the information it provided was essential to their jobs, so that's hardly a surprise. A small amount of feedback was received during the beta phase, but given the number of users the system had, the beta feedback was very limited. As far as I know, there still hasn't been any work done to determine whether most users find the new system easier to user or subjectively “better” than the old system. Again, once the new design was launched on the live system the project was declared a success, and the focus moved to something else. After all, if that project was a success you could stop worrying about it.
Two significant software developments, consuming large amounts of time, effort, and resource, completed with barely a nod towards the system users. I wish I could tell you those were the only such projects I knew of, but unfortunately similar practice is rife. In some instances it's due to an office culture where managers dictate the requirements for systems they will never use; in others it's just a case of someone having a bright idea and not stopping to think about the full implications of it. In most cases, more careful planning and involving end users in the design process will produce better software, save money and time, and increase productivity.
