TolaData for NGOs and foundations

Case study summary

What is TolaData?

TolaData is a web application designed to simplify the way non-profit organisations track project progress to provide relevant and timely reports to stakeholders.

Features:

• Project data management e.g. sites, stakeholders, budget, documents, etc,
• Indicator tracking & reporting, including dashboards
• Data collection & management

Project team

As principal UX designer, I collaborated with the client team, internal project manager and development team. This was my first deep dive into the all encompassing world of software development. Within the first 2 weeks I was introduced to enterprise design for an app with a wide and complex scope, agile work environment and the NGO world.

My UX process

The process I outline below, as well as in all my other case studies, is based on Elements/Phases of UX by Jesse James Garrett. The chart below outlines the tools I have worked with at various levels of complexity, with the star indicating my areas of strength. I have had an opportunity to use the tools and methods mentioned below across various projects with varying level of detail.

Strategy phase for TolaData

The design brief

There was already, in existence, a TolaData v1 in use by one organisation. It was developed to streamline the internal processes of this organisation across several geographical locations. However, a split by the repository owners initiated a separate web app dubbed TolaData v2. This was essentially a startup product built off of the original code base. A separation of staff and users meant that we had to cultivate our own user testing base.

With a large potential client presentation on the heels of development, my first tasks were

• to improve the user interaction for a new UI for features already developed by the frontend engineers;
• to design all features from v1 in line with the new UI;
• to design new proprietary features for our new target clients.

Prioritisation

Since we already had knowledge of the current usage of TolaData v1, we used it as a benchmark to define the roadmap, which prioritised key features. In a workshop session, we compared the potential client’s needs with what TolaData founders wanted to achieve and prioritised a backlog of epics and features to work on. We also analysed the few competitors in the market to see what features seemed to be used most.

TolaData is a very wide scope product targeting several user personas and offering many features. Firstly, being new to the team and the only UX designer, I had to familiarise myself with NGO program management as well as the history of TolaData app. I audited TolaData v1 app, went through training, combed through several online resources, spoke with friends and colleagues familiar with TolaData and generally NGO work. I also took a course on NGO program management, PMDPro, which is the framework TolaData is based on.

3 key challenges for a successful design were prioritised as follows

• Permissions management without restricting access to information when required;
• User data management security as emphasised by GDPR laws;
• Change management from current user processes to a new highly digitised way of working.

Scope definition phase

As intimated in the last challenge above, the NGO world is notorious for outdated, heavily paper-based processes. The use of technology is mostly limited to spreadsheets and email. The sheer amount of data generated disappears into paper files and manually updated cloud solutions. The complexity of accessing this information ends up not contributing true insights to any reporting done.

Initial scope

4 prioritised high level pain points that TolaData seeks to address.

• Labour-intensive and complex data collection methods leading to poor data quality;
• Disproportionate time spend in data management rather than analysis and decision making;
• Decision-making based on siloed historical data, limiting the capacity for comprehensive or effective action;
• Poor and inefficient information sharing and team collaboration mainly due to several disconnected tools and data storage solutions.

Out of scope in initial stages

Because the industry use of digital tools was limited to legacy microsoft-esque designs, we decided that focussing on the user interface to meet current app trends was not a priority. We would, instead, focus on making sure that the user is able to meet his goals by optimising the interaction and information architecture. This also helped manage my process since I was the only UX designer in the company.

Scenarios and personas

6 functional personas had already been identified for v1 and I built off of those personas to inform feature extensions. To reduce the complexity of design, I focussed on two main personas. The program manager and the monitoring and evaluation (M&E) manager.

Based on the comparison between TolaData’s business goals and user needs, these two personas would cover the bulk of initial scenarios that would make TolaData valuable to both the business and end users at this early stage. This would also reduce scope creep before we even began design feedback cycles.

Structure phase

Based on insights from the research and analysis phase, I was ready to begin mapping the information flow. I worked on high level flowcharts to understand the user journeys and how flows interacted with each other. Based on this high level map, we were able to identify critical areas to the success of user flows as well as feature opportunities.

At this stage, we also relied on the needs of our one potential client to tailor the app to suit them. This, as a valuable lesson learnt, proved to be detrimental because we did not secure the contact. We had to refocus effort back to the generic user. The user journey gave a bird’s eye view to generate a feature map and prioritise the roadmap once more. Just to mention, I did not produce the beautiful colourful journey maps you typically see online. Just used draw.io to produce flowcharts with notes. My documents needed to be easily updated in the spirit of being agile.

As a team, including client representatives, project managers and engineers, we had several discussions to iterate on the user flows, as well as to decide on which features to focus on. Once we agreed on specific use cases for the prioritised scenarios, I proceeded to start work on the actual site design.

Skeleton phase

This section involved flowcharts for selected user stories. I started my process on Draw.io using simple swim lane charts before embarking on any sketching or wireframing. These flows were discussed severally and iterated upon to get everyone in the team on the same page.

Then I did high level rough sketches of the page structure and main elements before working with Balsamiq to work on more details. While hand sketches are useful, I found it better to work on Balsamiq as it saved me time repeating screens and components over several pages. I, actually, work faster digitally. Being an architect in my previous life, I do understand the benefits of hand sketching but only for small portions of work. After sometime you don’t save much time or effort.

I, later, changed to Sketch when I started using Mac. This was encouraged in the team once we hired a UI designer who put together a design system for our company products. Of course, this did not limit any creativity. Whenever required, I proposed new components or UI functionality that would optimise user experience or solve UI specific problems without being limited by the design system.

I also created a clickable prototype for developers to understand the flow of actions. We used these prototypes to do some early user research. These were, however, very limiting because TolaData is a highly data dependent app. But we were able to learn that our first navigation design was pretty confusing to users. I did a couple of iterations before the team settled on the design that was both feasible to implement and improved navigation by a good margin.

Something to note is, because I was alone in the team, I had no time to produce pretty user flows with the wireframes. I depended on the clickable prototype to get the team to understand the routing through the app. I found this a much better discussion tool.

I also took on the role of UX writer. I mentored an intern on UX writing to help with writing microcopy for the app. We ran A/B tests and did research on wording from existing apps. A challenge we had was that this role was introduced very late in the project, so any proposals made were not prioritised by the project manager. But tickets exist that could be referenced when required.

Surface phase

My preferred personal career direction focusses on strategy and prototyping. While I do have intermediate skills in UI design, I find it impractical to give my absolute best to formulating the best value for a product and at the same time produce pixel perfect UI designs. I firmly believe that, if we do not dedicate time and effort in the early stages of product definition to solve real client needs, then no amount of graphical intervention can make the product successful. UX is not a linear, one-off process.

“If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.”

— Albert Einstein

We recently hired a UI designer to handle the interface graphical design and I find it freeing to focus my attention on pointing out areas where we can improve value and experience for the user. To do this, I took to doing heuristic evaluations of what the developers had already done, pointing out areas in the UI design that can be improved to optimise the user experience. I, also, prepared test plans and observe usability testing. Following UT reports, I summarised insights and prioritised them for iteration.

Lessons

From this process, you already notice that the first challenge I had was that v2 was already being worked on by developers. We had a big client deadline within 2 months and so there was quick need to start developing. Testing wireframes with non-biased users out there was not prioritised. In addition, the scope of the product made it tricky to do testing of sections of the app without the whole context. So in these early times, we settled on hypothesis journey mapping. The team decided that we would test our assumptions after development during usability testing.

Being a B2B, product, access to real end users was extremely challenging. I later wrote an article about just this issue. This is even trickier with NGOs because functional roles are numerous and geographically widespread. In addition, if we did get any users, they would be top level management located in major cities. We required lots of input from field staff who were not easily accessible online due to poor internet. For this reason I relied on my own NGO network and cold-calling prospects on LinkedIn to give insights on areas that I was not clear.

TolaData targeted several user personas who required different features at a given time. Designing an interface that would be relevant to a persona at specific time was challenging because their tasks were co-dependent. After several A/B tests and iterations, we settled on a navigation that separated major tasks based on the persona. Then, for a smooth usability testing, I had to create data that one persona would require to do his task but was not something that he typically worked on or even know details about. For instance, most project managers were not very helpful when asked to manage indicators.

The main lessons I learnt, being the only designer on the project for 2 years, are

1. UX projects that have a wide scope are better off handled by a multi-team design setup. This is not because one person cannot handle the tasks, but because views on approach from different designers always promotes the best design direction, saving time. In addition, tasks can be shared to speed up work.
2. If a company decides to settle for a small team, at the very least one of the people should be a UI designer. This is because the thought process when focussing on early UX tasks differs from that of later UI tasks. They both handle user experience but one is thinking more about business and user value while the other more about interface success. As a single UX designer, switching between these two means one of them will suffer.
3. Even though we work in an agile environment, we should always strive to manage UX documents for several reasons. First, when on-boarding new staff members, it is easier for them to quickly know the status of the project as well as its history. Second, it is easier to defend your progressive design decisions without trying to recall what was said. Third, for the designer, it saves time and effort to update their portfolio. This is a definite area of improvement for me.

The process discussed above has outlined what I did during these two years in UX. However, being a small company, I took on other roles most specifically project management.

Before we hired a full time project manager and also in between managers, I was responsible, together with my UAT testing colleague, for backlog grooming, writing tickets with user stories and acceptance criteria in Gherkin, sprint planning including story points estimations with engineers, sprint retros and executive status reports.

This project has made me knowledgable in areas of software development that I would otherwise not have learnt. I used Django admin to help with UAT and client support. I also learnt basics about Docker containers, Kubernetes, Postman, Github and other dev specific tools that has given me much more confidence having conversations with developers and even questioning some decisions they make.

Following this, I was also added to two new products Kupfer Software, a field-force management app and Wallhall, a platform to speed development and deployment for developers. These are discussed in separate case studies.