Needs assessment for grassroots organizations

Grassroots needs assessments - Getting feedback/input from stakeholders

Information Ecology - Lisa

Why people are interested in this session

• get better at talking with people about their needs
• gather data from beneficiaries and control groups
• curious about challenges and landscape
• How to navigate the back and forth

Frontline user are what are going to make or break the way we use systems.

Who are users?

• staff inside organization that we are working - inputing data, using the tool for information
• volunteers who collect or enter data
• beneficiaries - entering updating data - using the tools
• users of web-faced tools - outsiders looking in
• Users without tech knowledge and limited access
• data collection in the field - volunteers
• publishing staff/researchers
• consumers
• potential investors
• co-workers in different roles - subject matter, tech

Synthesize and reflect - broad range of comfort and knowledge - a lot of different roles.

Shift and talk about stakeholders - people who care about the process and outcomes as opposed to just the people who will touch the system

One participant proposed “use case specialist” as opposed to “user” which sounds parasitic.

Q for group - what is your approach:

• One example provided - one group uses word press and use a common theme and built tools for customizing pages - requires staff to learn how to manipulate this tool. Trying to bridge in help user understand the system better and manipulate it directly so the developer does not have to impose. This gives people access.
• Cabagge Tree methodology (www.cabbagetree.org) - taking facilitation tricks to apply to software. Get all groups represented with one stakeholder or more to design their own software systems. start with broad discussion - what does utopia look like? Show some examples. Start dawning work flows. Take these to developer who work out the UX and background mechanics.
• Starting with subject matter owner - what do they do and what do they want to do - they have a good understanding and have goals. Talk about how they see their user and what they want to accomplish. Draw up behavior personas of the users - what they know, what they like, level of knowledge. User stories. Impt. to do this even if very quickly.
• Using “yes, and?” as a way of moving conversation forward
• If you are comfortable and enjoyable you are going to learn. Divide the group based on where people are? Trainer have a perspective that they are still learning. Start identifying good trainers - engage others to take lead in teaching others. Always recalibrating. Having fun - using games to teach.
• Using documentation and breaking down use in

Common threads -

• cultivating empathy to channel users.
• Finding users who ‘get it’ and engage them to teach

Lisa has an outline of tool kit that she will share: https://ecl.gy/needstoolkit

• Identify and talk to reps. of all stakeholders
• “What is the big-picture outcome you want?”Eg - efficiency, more donors, find things easy
• What are using now - what works
• What is the ideal?
• Needs and requirements memo to circle back with client so you can make sure you have it right. Engagement on that document is import.
• Find the tools and more importantly the processes and practices that can get them what they want.

Lisa doesn’t build because the client can afford it. Helps select from available tools.

Q: Asked to build something but not sure who should be involved in the conversation and assumed others were taking that - approvals were given along the lines - but once building started all this feedback came out of the wood work

• Nonprofit managers don’t often know they need to do this process with the users - one participant suggested that developers give the nonprofit management best practices - need to understand that this is vital for the long-term use of the software.
• Go deep from the beginning on who should be part of the process - set some guidelines on what feedback will be needed and in a timely matter.
• Need to be realistic and up-front about what can and can’t be done.
• Using Agile
• Setting milestones - breaking down project and checking in often
• Billing often
• Make it easy and flexibile
• Start with structure and then be flexible
• Start with goals instead of requirements - make sure goals have a rationality
• Giving trade-offs - what is the cost of these great ideas
• “Software is a conversation” - keep the conversation going and connected
• Need to know what your next step is

On participant referenced: “Agility is deep” video - choose tools that fit the context

It’s all trade-offs.