Earlier this year, I embarked on a journey into user experience design and development. You see, I’ve always been a database person, but I knew we needed to think much more about what’s known in the tech industry as “UX”. So I got into studying user experience academically and applying the insights day to day. It’s been great to do – I was able to improve my understanding of how users are actually understanding the product I manage, and how they don’t, and start to gain more understanding of what might be done to improve the overall experience people have when using Akvo Really Simple Reporting (RSR).
When Akvo RSR was conceived, it was as a project database that would support the opening up of highly networked partnership structures in international development cooperation – a web-based multi-tenanted content management system. It was designed to scale to thousands of projects. And today we have 2137 projects online, covering project budgets worth over €1 billion. So in many senses it’s achieved what we’d wanted – a rock solid web-based project database used by lots of organisations. But it’s set to grow in use dramatically, so now is the time to look at how it’s used – it’s vital to me that using RSR is not seen as a burden, an extra thing to be done. I want it to be a joy to use. How we design RSR from here will absolutely affect its uptake and the attitude users have towards it.
Improving user experience is a journey of discovery and starts at the source of truth for all software products – the user.
After undertaking many informal interviews, speaking with internal and external users and analysing as much quantitative (and a little qualitative) data about RSR I could get my hands on, I started producing some materials that would help pave the way for improvements.
Red routes, personas and user stories
To begin with, I pulled together all the features and functionality that RSR delivers and categorised this into a red routes map. This map gives a clear overview of where the most important items are within the features being provided by RSR, and is a great resource to gauge the kind of effort and attention we should be paying within areas of product development.
Following this I took information from the people I had spoken with and created a set of RSR personas that accurately reflect the real users in the RSR environment. These users all have back stories, ideas, requirements and needs that RSR needs to meet in order to ensure user satisfaction is taken care of.
Coming out of the personas work I was able to make a full mapping of user stories that cover every area of the system, linking each user story to one or two personas, I was also able to give a valid voice to these requirements. This board has now become such a handy resource for me. When I get a request now I first check to see if I have the user story already in place – if not, then I can add this, but I have to be able to allocate this to a persona. If I cannot, then this means either that I’m missing a user in my plans, or the requirement isn’t relevant for our users.
All of this information put together painted a clear picture to me about the state of RSR as a product, and places where we’re not meeting the needs of users. We have many pieces of functionality, but there are some tasks that users need to carry out that the system was simply not designed to do well, when it was conceived. It was also clear that some of the things we wanted to do to improve user experience would be difficult to fit into the existing structure and design.
So I had a good reason to get us back to the drawing board – the drawing board being an open office space in Helsinki, to meet with the Akvo design and engineering team and really get to grips with the options available to us.
Putting all the information and resources I had gathered on the table, we went through all the major user routes. Defining the problems users are currently facing, what caused these problems, and starting to understand how these might be resolved.
So what are these problems? Firstly the user registration and administration process is unclear – the majority of our support requests are directly related to user management, forgotten passwords or usernames, admins not able to find new users and incorrect registration applications.
Secondly there is some uncertainty on what users can actually do in RSR. There are no clear call to actions in the system, so you arrive on RSR, but then what? There are many actions a user can take, from viewing and working with projects, updates or organisations, donations, sharing or investigating deeper into the data – but you have to know upfront that these are possible and then search for them.
Thirdly is the distinction between the Admin and the front end of RSR. The fact that there is a different place to log in to each confuses people, and then further how do users find the projects they need to edit? How do they know which projects they have access to? What updates has a user placed? Which other users belong to their organisation? All of these are questions our users have, but the existing structure doesn’t easily reveal answers.
After a week of working together, we came up with the redesign plan. We call this a redesign not just in the visual sense, but in the structural and engineering point of view also. The way our users interact with the product will change in some fundamental and really useful ways, and help to streamline activities to reduce the overhead that using RSR has on our partners.
At the core of the redesign work are 3 critical areas:
2. IATI and Content over time
3. Distinction of RSR as its own product
The introduction of MyRSR will provide a new interface that is clear and directs users to the features and functions that they need to access for their work. It simplifies the user registration and authorisation process by removing the necessity to access the existing Django Admin module, ensuring that the Administrators of an organisation can clearly see new and outstanding user registrations and relies much less on email and other non system-based communication methods.
MyRSR also gives users a history of the project updates that they have posted in a central place – effectively a personal portfolio, as well as a list of projects that they can update. It reduces the requirement for users to bookmark or keep track of individual projects by giving a smaller list an individual person can work on.
Another key change is the introduction of object-based permissions. When we started out with RSR it deliberately attacked head on the old-school command-and-control politics that said only marketing staff in head office should publish on the web. But that was 2009, and 2015 is a different place. Now, sharing activity from the ground is fundamentally understood as a good thing, and we have partners with hundreds of projects who want more sophisticated ways to assign editing rights to different people across the world, so with minimal training they can share updates on their work without messing anything else up. So organisations will determine access to projects and updates per project if they wish, and not just at an organisation level. This will increase uptake and reduce training and support for end users.
IATI and Content over time
The implementation of the IATI data set within RSR gives us huge potential for both reporting and understanding project data not just as a snapshot, but over the duration of the project. However in order to capitalise on these changes, the data being entered has to be visualised in a manner that makes sense to both the users working on the project as well as the general public.
If you’ve ever seen IATI visualisations, you will notice that many of these do not stray much further than the plotting of points on a map – this is because the data is both rich and complex in many ways. If we tried to stuff this into the existing user interface of RSR, not much would have made any sense, and even more would have been giving the incorrect indication of what is actually happening. As a result we’ve needed to work on how we can better display this by making new designs for projects, in particular.
Distinction of RSR as its own product
Users of RSR are often heard to be quoting the product as being called Akvo. This is troublesome for us as an organisation, and even more so for me and the team working on RSR. If you visit RSR in its current version you will notice that it has the same website header and footer as the Akvo.org website. This means that users cannot differentiate between RSR and Akvo as an organisation that provides a range of tools and support. This is a legacy of RSR’s roots as a project marketplace and something we’ll be unravelling.
The work being done on RSR v3 started in earnest with the first code being written towards the end of September, the team is pushing forwards and delivering new elements of functionality, visual and structural changes each day. We’ve just kicked off the pre-alpha internal testing process that will help to ensure we remain on the right path for our users and allow us to make any changes in the plans based on the feedback we receive.
As we enter the beginning of 2015, we will be sending our work out to the wider world with a full roll out of the changes, but the work doesn’t stop there – we’ll be monitoring the uptake to make sure that we have indeed made the improvements we need to. Tracking user support requests, satisfaction and organisation uptake we’ll be able to put real figures behind the changes. For a modern and effective product to compete in the growing market of development aid project visualisation and reporting.
Adrian Collier is the product manager for Akvo RSR.