Considering the needs of different types of users is an integral part of any successful design process, regardless of who exactly your end user is: non-profits, for-profits, schools, government agencies, or community service programs.
All products need a basic understanding of their end users and the limitations that they will face when using the product. However, there are alternate design methods that are used sometimes with varying degrees of success. As part of sharing “Design tips for Non-Profits” in this blog post, we will also explore other design methods to help everyone understand what is out there and what is useful.
- “Self-design” or “Designing for yourself” is where the designer uses their own experiences to act as a replacement for real users. This method is convenient and fast, but not always reliable and relevant.
- “Genius design” refers to using your own ‘genius’ or drawing from your own experience. This method is risky as you may exclude many issues that your users may have and you don’t.
- “Activity-focused design” means designing for activities that have been designated as important to the team. This is a very common method for startups but misses users’ unmet needs and therefore misses huge business opportunities.
Clearly, these methods have their pros and cons, but instead of recommending one particular design method, we want to encourage NGOs to really evaluate how to approach their own software development process and find the right method for their unique needs.
People who use software have different needs and different challenges, whether they are due to physical limitations (accessibility issues) or location (developing countries) or even overall ease of use. Designing for everyone is difficult; designing for yourself is easy because it requires one to look no further than your own experiences. Too often we as software people think that designing for ourselves will somehow fulfill everyone else’s needs.
This article will focus specifically on what NGOs can do to benefit more from established user-centered design processes and improve their existing products. Rather than go through all the steps in a typical process, we will focus on specific steps in the process that may be more beneficial for NGOs that are designing technology tools for their community service programs.
Learn about Your Customers – the users of your community service programs
It is important to understand your customers so you can better design for them. Some questions to ask yourself and your team:
- Who are your users? Write a description of each user type including as much detail as you have available. Are they literate? Do they own their own mobile phone and have access to electricity? The more detail you can provide, the better.
- What kind of experience will the users have with technology and products like the one you are building? When constructing your user-type descriptions, add each user’s familiarity and comfort level with technology in their lives. For example, are field workers in your community service programs unfamiliar and uncomfortable with IVR systems or SMS messaging services? Or, are elderly volunteers going to need a phone number to call?
- What are they key goals that users need to accomplish with your product? Make sure these use cases (goals) are documented and prioritized in order of importance.
- What constraints or difficulties will your users have while using the product? For example, will they have consistent internet access? Light? Electricity shortages? Language support? Make a list of the constraints.
Design for 80/20 Rule
It is common to try to design an interface that will accommodate everyone. This is almost impossible and results in an interface that has a little bit for everyone yet meets no one’s needs completely. To build a useful and useable interface, focus on your target customer and their most important use cases in order of priority. Design those well, and then make accommodations for the remaining users and use cases in your community service programs. The 80/20 rule is one designer use to help them make design and functionality tradeoffs. The 80/20 rule tells us that 20% of the functionality and features in any one environment will be responsible for 80% of the results. Therefore it is important to prioritize those tasks that the majority of the users will use most often.
For example, while designing engageSPARK, we prioritized engagement types that will be used most frequently by non-profits for their community service programs. These customers’ needs are important to us because they will need certain functions to help them complete their goals of creating an engagement to reach their clients. After talking to our users we have identified core functionality and made sure it is easily accessible and the most obvious choice. Design decisions such as these can be made easier on the team when trying to decide what goes where on a page.
Iterate before Starting to Build
Another common misstep is to design something and start building right away. This is also a common path for many for-profit startups everywhere. The rush to build something so you can show your clients and customers is overwhelming and sometimes financially necessary. However, iterating on a design will save you time and money later on, as changes are always harder, more time-consuming, and more expensive after something has been built. Testing your designs prior to building with real customers will allow you to make changes before anything has been committed to code and allow you to really refine what functionality you will launch with.
A very popular way to iterate is to build a prototype of your main features and iterate on them before starting development. A popular prototyping tool for designers is Axure. A simple online search also yields many different types of prototyping tools for different purposes.
Test, test and test again. Testing before building, testing while building, and testing after building are all going to decrease bugs, improve usability and help your team understand what your users want and don’t want. There is an entire field of study that is focused just on user research and design research, and testing your product is the best guarantee of success. A common test that non-profits can more easily accomplish without too much hassle: before building anything, take a paper copy (digital copy) of some of the main tasks and have a co-worker, or better yet a real target user, try to walk through what they would do to accomplish one of your main tasks.
For example, if your product’s main task or goal is to be able to send a message, ask the user to try to send a message using the paper or digital prototype and talk through what they would do. Try not to interrupt or tell the user how the product works; just listen to their educated guesses and why they have chosen a particular path. For more on how to do usability testing, check out The Ultimate Usability Testing Guide and some of these books and websites.
Feedback Loops – get meaningful feedback from the users of your community service programs
NGOs may find that they have many ways for their clients or customers to provide feedback: via email, phone calls, social workers, field workers, etc. Many community service programs in Africa already have SMS campaigns that they can reuse for beta testers. However, there is a difference between creating channels for general feedback for anything (which encourages only the worst complaints or compliments to be reported) versus regular, consistent, and measurable feedback loops for your software product.
Soliciting feedback from users in a way that is measurable over time and over product life cycles can ensure that your software is improving with each iteration and with each change. Sending out regular surveys to your users with a set of questions that are targeted toward the most important features on your site with feedback scales can help you determine if your satisfaction levels are improving or decreasing over time.
These are just a few tips for non-profits on how to improve your current design process. There are many articles written on the full design life cycle and countless books on the subject. You also should check out the Ultimate User Experience (UX) Design Presentation for a more thorough analysis of UX design principles and best practices.
But these particular tips are all things that can really make a difference, especially for non-profits:
Learn about your customers
Design with the 80/20 rule in mind
Iterate before building
Test, test, test with users
Create feedback loops prior to launch
Iterating before building is a technique that will really save a non-profit time and money early in the project, as traditionally non-profits may have less money to spend compared to large corporations.
We’d love to hear from you! If you have specific questions about design, please leave us a comment. In the future, we will delve deeper into each of these design tips for non-profits and provide practical use cases for each. Let us know what you’d like to learn about and get your questions answered.