Applying UCD Process to the Cauze app
Cauze is a small Boise startup producing an eponymous mobile app created to make giving to a charity frictionless and rewarding for users. The app functions properly but hasn’t had the adoption expected. Are there flaws in the design and are there missed opportunities as a result of their design process?
I initially engaged with Cauze as a favor to the founder. They had just released a feature, and as with previous releases adoption was very low. After providing design guidance for that issue (below) we formalized a UX consulting contract where I would produce further designs and documentation for producing the app.
Roughly 100 hours
RESEARCH & DISCOVERY
“We just released a feature where people can scan a printed QR code we’ve placed at an event and it takes them directly to the sponsoring charity’s page to donate. We had printed codes last night at the event I emcee’d where I talked about the feature.
“Why didn’t anyone use the feature?”
I spoke casually with a handful people who were at the event to understand why they hadn’t used the QR code feature. Their answers didn’t surprise me. There was a motivation issue: they were at an event and not prepared to make effort and find a charity to give money to, and/or they didn’t want to install another app on their device (especially one they didn’t expect to use often). But there was also a usability issue, and this could and should be addressed more directly.
Upon seeing this user journey the CEO asked for more of my time to produce additional documentation and lead the UX effort. I proposed we focus the engagement on addressing a few core questions:
Are there other sub-optimal flows?
What are the bigger issues?
What is the overall vision, and how is the current feature set tracking to it?
How are features prioritized?
I continued my discovery by mapping out a few of the main flows. The goal was to find patterns and opportunities for improvement.
From this and discussions with the visual designer and the founder I came up with two general conclusions:
Hypothesis 1: Cauze users need an advocate.
Hypothesis 2: The Cauze team needs process improvements and a design strategy.
The first thing I wanted to do was understand how production of features was prioritized, and then suggest some tools to influence that process with the needs of users in mind.
We discussed the need for the app to provide solid utility: the promise is to make charitable giving frictionless with an easy-to-use mobile solution that consolidates all activity in one place. Apps that are primarily utility, for example, include Lyft and various parking apps. There is little reason for a user to spend any time in those apps unless they need a ride-share or to pay for a parking space, which is totally appropriate in those cases.
But in order to become a truly ‘sticky’ app that users interact with more regularly, Cauze needs features that provide personalization and self-expression as well as features focussed on discovery and delight. The former gets users more invested in the app, reflecting their input and activity back to them and their social network and encouraging more interaction. The latter aims to make it easier to find appropriate charities or learn about new ones, and to basically make using the app less work and more play.
We also discussed user motivation in general, the fact that if there is something external motivating them to give they are more likely willing to do difficult tasks. But the less motivated they are the less effort you can expect from them. For example, if a wildfire has affected their hometown they will set up an account in a mobile app when asked. But if they are socializing with friends and receive a call-to-action notification from the Cauze app the task has to be low effort for them to respond.
There is also the reality that times of high motivation are rare and out of our control. Most of the time users will be in a low-motivation state. Therefore, while Cauze needs to be prepared with features to handle the high-motivation spikes they also need to provide ample engagement opportunities for the majority of the time.
Lastly, I set up an example Red Route Analysis to show another way to look at and evaluate features for production. In all, these discussions and documents were intended to give the team tools for prioritizing their work with a focus on giving users what they want and need in the app. They had myriad ideas themselves and were often distracted by ideas suggested by potential investors and advisors as well. With a limited runway to prove a concept there was a need to solidify their direction as efficiently as possible.
Armed with a number of discoveries and ideas from several whiteboard sessions, I began to flesh out some lean concepts for addressing various UX issues. I evaluated the existing index/landing page users first see upon entering the app and proposed additional items to include based on where they are most likely coming from. I proposed a new simplified, sensible, and scalable site architecture I believed would be more intuitive. I included comp’s of several screens and persistent elements that would bring some instances of delight and personalization to the experience.
At this point our engagement was concluding and I handed off the next steps I envisioned for the team:
Prototype and test navigation changes and proposed features.
Commit to a single over-arching concept defining how users interact with the app.
Refine the designs and apply a consistent design system.
Prioritize MVP work and begin production.
My experience enabled us to take a strategic approach to defining where the app eventually needs to be, as well as a very tactical approach to target improvements with large impacts for the user. Ideally this project would have had UX involved at Day 1 and followed a more structured and intentional design process but we were still able to apply several tools and design thinking to effectuate a necessary course correction.