Working On Pro-Bono Projects with NGOs: Success, Mistakes and Learnings
Choose good clients, treat projects seriously, expect some difficulties and never sell yourself short
Intro
I have been engaging with various NGOs for design projects since my junior year in undergrad. I do the pro-bono work for a variety of reasons:
- I believe in their work and mission
- I want to give back to community
- I want to level up my design skills
In the past 4 years, I have both GREAT and BAD experience working with NGO clients. I have learned quite a lot from my successes and failures. I want to write down my learnings to —
- Share my learnings with aspiring UX designers who want to use pro-bono work to get into the field
- “Own my mistakes” so I can grow to be a better person
First, treat your pro-bono work as serious as your other paying gigs, this means —
Designer needs to create project brief for pro-bono projects (especially when the client does not come with one)
What: Project brief is “something you both agree on doing”. It should contain *specific* project goals and scope, timline, deliverables and success criteria. And make sure you get it in writing!
Why: Pro-bono work usually doesn’t come with a budget or a strict timeline. And it is easy to be trapped in scope creep when nothing is at stake. If there’s no document writteen upfront about the scope, you might be asked to iterate on a feature for the 100th time under the disguise of “perfecting the product”. Also, writing something down is a great way to build trust, to let you client knows that you understand their needs.
✅ My success: In one project, I created a design debrief deck. It is simple and outlining my understanding of the project goals. Even though the project goals shifted due to pandemic, me and the client were able to refer back and update the goals.
❎ My mistake: In another project, I didn’t write down a project brief. I thought the goals are clear, but it turned out that the client wanted something else. It created so many frustrations for both parties when we couldn’t use a common ground to evaluate if an idea or a feature is out of scope.
Designers need to set clear expectation on the roles and responsibilities on both parties
What: Set expectations of what you will be doing and not doing with the client, in writing. Communicate and make sure your stakeholderes understand where your expertise lies, so they are not asking you to do something uncomfortable and you end up in a bad relationship.
Why: If the client doesn’t know what to expect from you, it is possible that they assume you can do anything design-related. And if that comes, you can’t really say “no” gracefully. On the other hand, if the client knows what you need, when you make the request, they won’t be surprised.
Also, if you realized later that you and the client couldn’t really align on roles and responsibilities, it is a signal that this isn’t the best project for you. In that case, leaving the project and/or referring your client to other designers who might help might be the most responsible thing you can do for both parties.
✅ My success: In one project, I communicated with the client upfront about request to research. The client connected me with actual users and other stakeholders, which turned out to be quite helpful.
❎ My mistake: In one project, I had miscommunication with a client on the fidelity of the prototypes required. Based on the sample they showed, I *assumed* (mistake!) that an *adequent* (mistake!) amount of real data is needed. So when the client expects me to replace every single information with real data (tons of work), I said no, and it caused frustrations for both sides.
Bottom line: it is on the designer who creates project brief, set expectation and align with your client at the beginning of the project.
The danger of not doing so is the same as working without a contract.
However, doing pro-bono work for NGO is also different than working on a full-time job in a lot of ways. For instance, it is possible that some NGO stakeholders have less experience in digital product management, so —
A designer should avoid making assumptions that general software development principles are applicable to a NGO pro-bono project.
What: This is more about making assumptions that the client understand and agree with a general product management approach, which includes “designing MVP”, “prioritization”, “start small and validate”, “data and user driven” and many more.
✅ My success: Once for a web design project, a client who wasn’t familar with the development process went directly into the content management system to update the design directly. To manage the situation, I asked the client about the design requirements, and pitched to them that I used my expertise to create wireframes that address the problems. I created mockups and asked the client to review, the process went well after that.
❎ My mistake: Once for a complicated product design project, I repeatedly told the client that I think we should prioritize features to build for MVP, then we can enter phase II, phase III, etc. I thought this was a common approach and did not bother to sell this “MVP” idea. However, when later in the project my client is still requiring all the features into one prototype, I realized I have failed in my communication and the idea never stuck. I also realized for my client, it doesn’t matter how much time it actualy take to develop the prototypes. They just needed it for pitching.
It is a designer’s responsibility to guide client to give helpful feedback.
What: As creatives, we all experienced times when a stakeholder comes to you with comments such as “there’s something missing”, “ this doesn’t work”; or simply tell you “add icons” or “x, y, z features because I need it”. This is a great time to ask client to give you more “why”, direct them to state the problems and stay away from solutions.
Why: Again, I think it is quite common for an NGO client to not have worked with designers before. A designer is just as responsible as your client in giving the right feedback.
✅ My success: Once a client asked me to change the theme color from red-orange to blue. I probed into the request more and found out an accessibility concern.
❎ My mistake: Once a client gave me contradicting feedback on “including x feature” and “excluding x feature”. I admit being irratated (something I need to work on) and directly said “no”.
Choose Good NGO Clients
I understand for a lot of students and people who are transitioning, working on pro-bono project opens door. But this doesn’t mean you should sell yourself short and take every project you can find. Even though the market is hard, working with bad clients, especially when you just started, can crush your confidence.
And I admit I let my ego and emotion takes the best of me at times and let people crushed my confidence. I shouldn’t have.
Truth is, there are good and bad places to work for; and there are good and bad clients. Once in a coffee chat, a mentor told me they ask every client this question at the begining of the project —
Am I designing for your customers, or for you?
I think this is an important question to gauge, maybe especially for an NGO project. After all, we work on pro-bono projects because we believe in the mission and importance of the issues. We believe in the good-ness the product can bring to the world. And in order to do that, we need to design for people (customers), not the client.
Designers need to choose good client, even and especially for pro-bono projects, even and especially when you are just getting started.
Easier said than done, I know, so here’s a good guide on finding good clients.
