Cut your digital coat according to your financial cloth

SLiDE’s small charity approach to choosing digital products.

Our charity (SLiDE) is a community of around 150 dancers, musicians and creatives of various ages, backgrounds and abilities. The core staff team consists of three part-time staff members. Our annual turnover is roughly £60k and we cannot afford to invest significantly in digital. This blog is about our approach to choosing digital products.

To help you understand our situation here is an analogy. I’ve limited my supermarket shop to weekly and have to really think about what I want to eat over this period so I make a list not just of essentials (coffee, eggs, flour) but meal ingredients for things like roast chicken, and lasagne. I am fortunate that I have the budget to buy these items whether they are on offer or not — in fact if they are on offer all the better! However if I was poor, I wouldn’t make such an extensive list and instead go to the supermarket at 4pm and pick up whatever is yellow ticketed or on discount and make what I can from that. If I was even poorer, I would go to the foodbank and get given a bag with items. The poorer you are, the less choice you have and the less your non-essential needs come into play.

Similarly, we cannot afford bespoke software so we use off-the-shelf digital products with ‘digital duct tape’ (credit Francesca Dortora for the phrase) in an attempt to get it to fit together and not create more work than before!

Here is a brief description of our approach:

Gather requirements

Firstly, we capture our ‘must-have’ user needs. Typically this takes less than 30min and may result in about 3 user stories. Note that we may have more user needs that are not must-haves but we won’t spend time capturing them now.

Our most important requirement is non-functional — it must be free or cheap! This usually eliminates the vast majority of products in the market. There are other non-functional requirements but I’ll come to them later.

Research products

We research the market using our must-have needs to evaluate the products. For those that meet the needs, we make notes about their features in a spreadsheet or document or both. From experience, we will be lucky to find more than one or two products to evaluate further.

We look into these products in the following non-functional ways:

1. Trusted recommendations: Who in our network uses these products and what is their review of them? The views of people we know are more valued than online reviews that can be fake.
2. Product Maturity: How popular is the product? Is it well-known and established or a new product? We would tend to steer clear of niche or new products as we have found them too unstable, unreliable or bugged to use especially for disabled people.
3. Accessibility: How accessible are they? We especially consider accessibility for our community. This is not just functional accessibility but also how frustrating can the product be when it doesn’t work as expected?
4. Security and privacy: If we are storing personal information, this is important. You’d be surprised how many products don’t do such things well.
5. Vendor support: We do not have an IT department to help us when things don’t work as expected or we hit problems so vendor support is essential. Do they provide good documentation? Do they have a person you can talk to for free?
6. Vendor commitment to nonprofits: Is the vendor providing a free product offering because they are altruistic? Or is it because once you have spent effort on its limited features you would prefer to pay for extra rather than change to a different product?

Iterate

If we still have multiple products to choose from, we capture lower priority user needs to evaluate against the products until we have chosen one. We do this iteratively and don’t capture too many requirements to not waste time.

Also, the features of the products feed back into the requirements — in our research, we may find a feature that we never imagined existed but could leverage into our processes.

In our experience, we have never had to do this often but theoretically it is possible when there is such a thing as a free lunch!

Conclusion

In the tech world, user needs are key to understanding what you want but the smaller your budget the less important they become. The important thing is to capture requirements that are ‘good enough’ to perform the initial research and iteratively gather more as and when they are needed.

We are a small charity so it is easier to gain consensus on prioritising requirements as there are fewer views to reconcile. This makes it easier for us to establish the must-have needs quickly and conclusively. This is a ‘lean’ approach as we are not wasting time on capturing requirements that don’t ever get used.

Halfway through the Catalyst definition programme we are really enjoying the learning and collaboration from both Outlandish (our digital partner) and the other charities in the cohort.