Over the years the University of Liverpool have done some great work in the mobile app space, both internally and externally-facing. They’ve won a couple of Intranet & Digital Workplace Awards. and I’ve also seen Paul Hagan, the leader of the team, speak on a number of occasions and talk a lot of sense about developing task-focused, user-centred apps.
I’ve also been intrigued because Paul used to be a professional musician. I’ve always wondered whether the experiences of being in a band helped him in running a close-knit team and even collaborating with stakeholders. So, I thought I’d run a short interview with Paul.
The original intention was to turn to this into an article, but Paul’s responses are very interesting, so I’ve actually decided to publish the whole interview unedited.
Steve: How did you end up at the University of Liverpool in charge of the mobile development team?
Paul; I actually have an undergraduate degree in music, so feel something of a fraud working in a department full of computer scientists! I was at university in the late 90’s, when the web was first starting to become “interactive”, and a small part of my course involved music for multimedia, and publishing on the web – simple MIDI files and the like.
I’d always enjoyed messing around with computers when I was younger, so pretty quickly got the knack of putting web pages together, and before I knew it I was doing simple websites for friends and family. This continued alongside my career in music, to the point that by the time I was ready to close that chapter of my life I was able to transition pretty easily into a full time job doing web stuff.
Eventually I found myself working at the University, primarily in a UI/UX design role, and then when the opportunity came up to get involved in mobile development I jumped at the chance.
You played in the band Amsterdam for years, played festivals, recorded with Elvis Costello and so on. Has the experience of being in a band influenced or helped you in what you do now?
There aren’t many areas of my life that haven’t been impacted in some way by my experiences in the music business and playing in bands, for better or worse. You really do learn a lot about the value of collaboration, leadership, coping with adversity, and the importance of enjoying what you do – particularly in relation to achieving to your full potential.
To me, playing with a group of musicians is the ultimate example of the whole being more than the sum, which has definite similarities in terms of running a full-stack development team like ours, where there are a range of disciplines, skills and temperaments that need to work collaboratively for things to get done.
Mercifully, after the rollercoaster of releasing records and being on the road, music has gone back to being something that I do strictly for pleasure, and is an amazing form of escapism – which I’m sure in itself has a positive impact on the rest of my life. I’m not suggesting everyone should join a band, but certainly having a few hours every week where you do something that allows you to totally detach from work/family commitments etc. is invaluable.
Which of your projects are you most proud of and which has had the most impact?
There are 2 projects I’ve worked on recently that have made me feel like I’ve done something really worthwhile, which is a nice thing to be able to say about any job.
We’ve been working with the School Clinical Psychology on an app called “Catch It” which is a mood diary for people either considering, or already attending, Cognitive Based Therapy sessions to help catalogue and manage emotional incidents.
We’ve also launched an online recruitment platform for the University’s “Scholars” scheme, aimed at giving young people from under-represented backgrounds a better chance at a University education. Eligible applicants would typically be the first in the family to attend University, and may have lived in care, or be from a very low income household.
Both cases have reminded me that digital tools still have a very real human impact, and that success doesn’t always have to mean increasing turnover, or the number of “eyeballs”.
The apps you produce are always ruthlessly focused on the task in hand. No bells and whistles! How did you end up with that approach and is that ever a hard sell to stakeholders who want all the extras?
Ever since reading “The design of everyday things” by Donald Norman, I’ve been obsessed and infuriated by the ridiculous complexity of the world we live in, mainly thanks to the well-meaning but ultimately unhelpful actions of designers and engineers the world over.
It’s an amazing read which is worth a few hours of anyone’s time, but has essentially has a single message – it’s not your fault. Can’t remember how to log on to your banking app? Not your fault. Don’t know which button to press to buy something? Not your fault. Don’t know how to get a paper towel from the dispenser? Not your fault. These are all problems that are routed in bad design, overly complex solutions, and people being afraid to leave things out – or worse still, breaking convention for the sake of newness.
I think I’m just horrified by the idea of ever designing something where it isn’t immediately apparent what action is required by the user, and what the consequences will be (referred to as “knowledge in the environment” by Norman) – which lends itself to clear, purposeful UI, and a limited feature set.
When we work with customers to define scope we ask them to divide their wish list of features up into primary and secondary functionality. Anything that’s listed under secondary usually ends up in the bin, and if you’ve got more than a couple of primary features you’re also treading on thin ice! This doesn’t always go down well at first, and can raise a few eyebrows, but that’s when the swiss army knife comes out…
Is it true you bring a large picture of a Swiss Army Knife into meetings to explain your approach?
Yes – I’m not above using a couple of props to try and jolt people into seeing that mobile apps aren’t just another opportunity for building bloody portals. The giant Swiss army knife represents an app that’s overloaded with features, while on the flip side of the board is an electric screwdriver. We use it to pose the question “if you had to spend all day screwing in screws, which would you rather use?”.
I guess the point of the whole palaver is to help people to engage with the notion that a successful app focuses on a single, clearly identifiable problem or task – ideally one that’s carried out regularly, and justifies repeated use of the app.
I also have a magic wand that gets brought out from time to time if someone is having difficulty focusing on the problem they’re trying to solve, or is being distracted by the medium. Instead of talking about apps and smartphones, we ask them to wave the wand and tell us what has changed, or what problem has gone away – then think about how mobile technology might help them achieve that.
In the digital workplace space some organisations seem to advocate beautiful, integrated environments while others move to a series of individual, dedicated apps. What works best and can the two approaches be reconciled?
This is something you’re never going to get consensus on, although my personal opinion is that mobile is a great lever to help us move away from the horrendous mega-portals of the past, and into a state where small, flexible apps are developed to solve discreet problems and carry out linear tasks quickly and easily.
Although I don’t think large organisations will ever be able to do away with some kind of enterprise IT platform at the heart of the business, the existence of data warehouse tools like Business Objects (which we use at the Uni) mean that apps can exist more or less in isolation, collecting and submitting data back to a central repository that can then be made available to other systems as needed.
Using this approach at Liverpool – relying on web services for connectivity and a central data repository – means that we don’t need to worry about whether a new app can talk to product X or product Y. They all communicate through a central source, but can be written in difference languages, have different development stacks, and run on different operating systems.
Many thanks to Paul for spending so much time to craft his answers. You can connect with Paul via Twitter.