Prototypes and guerilla testing — how NCVO started exploring unmet user needs
This is the sixth post in my series about NCVO’s technology strategy.
In my last post, I shared some of what we learned through user interviews and data analysis about how our users experienced our large and fragmented portfolio of websites and digital services.
Our next step was to dig deeper, using prototypes and testing.
One of the things we set out to discover though our user research was the key goals our users had when they came to our sites. We learned that there were four high level needs that were driving their actions.
- I need my basic questions answered — information, advice and guidance to answer a specific question or need
- I want to improve or develop my organisation’s practice or quality
After talking to users, we felt confident that these needs were being met reasonably well, although we learned lots that could help do this better.
But then there were these two needs:
- I need to know what’s new and coming up and what the big issues are
- I need to know what NCVO offers that can help me
We felt that there was a huge opportunity to better meet these needs, particularly for users who come to our websites and services proactively, and don’t receive emails or follow us on social media.
The ‘sector briefing’
We wanted to explore how we could help time-pressed site users understand what’s happening in the sector at-a-glance without the need to navigate lots of site sections.
Working with Simon I’Anson (then one of the fab CAST team), we designed a basic prototype which included:
- Editorially controlled latest news and updates from across our various content types and products, including publications, events, blogs…
- Updates on the ’big issues’ with links to latest articles and a subject backgrounder
- Diary dates
We took this to a conference we run for trustees and leaders. Five of us roamed the exhibition area and showed it to delegates. We had some broad questions to help us understand their behaviour:
- How do you keep up to date with the sector currently?
- What are your main sources?
- How do you access them — devices, times of day, channels?
And then some questions to find out how they experienced the prototype — what made sense to them, how they might use it, what they liked and what they didn’t.
At the end of each break we came together, shared what we’d learned and synthesised this together.
It was a great way to quickly learn a lot. Taking what we heard, we developed a second iteration, which we tested in more depth with further users at a later date.
‘Let us help you’
To respond to the user need ‘I need to know what NCVO offers that can help me’, we wanted to test ways of aggregating information and resources in meaningful ways for users.
Again, we tested this with a prototype at our trustee conference.
The first version tried to summarise what NCVO did with six broad statements. We quickly learned that this didn’t work at all. So for the next iteration we changed this to topic areas. These topics had already been developed through card sorting with users, so we were pretty confident that the words were sound, but were less sure about whether the approach was the best way to respond to the user need.
We had good feedback on the approach. But it was a fix for an information architecture that wasn’t making sense for users, so we wondered whether we could be more radical (spoiler alert: more radical is where we ended up…)
What we learned
Perhaps more valuable than the specific feedback on the prototypes was what we learned more generally about how our users interact with our content, and what we need to do.
- We need to create more intuitive, user-centred ways of displaying and surfacing content and materials
- The content needs to ‘come-to-me’
- Silos need to be broken down — content shouldn’t be structured by type but by topic, subject or interest area
- If a user finds information of interest we need to make it apparent whether they are viewing everything or just a subset. If the latter there needs to be clear signposting to the rest.
We may not have developed anything based on these prototypes, but the exercise of producing and testing them helped us to learn things that we wouldn’t have got from interviews or from data analysis.
In my next post we’re getting technical. I’ll share how we started working with an independent technical architect and started discussing some brave and radical plans.