Design driven epic
Context:
Program staff use forms to gather data from beneficiaries (the people benefiting from the program). Usually program staff only need beneficiaries to answer a subset of questions, generated from the measures in the logic model. The questions they want to select are those where the data provided by the beneficiary feeds the measures applied to a specific outcome. If you are curious to learn more about what a measure is you can visit the UN Sustainable Development Goals to see common examples.
Challenge:
We gathered feedback from nonprofit staff users deploying a data gathering initiative. The challenge they were facing was an unwieldy question list. There were too many questions to select from, and oftentimes they only needed 3 out of the several hundred options.
Users:
Nonprofit program staff.
1. Definition facilitation
To help the business analyst think through the how measures could be displayed for a user, I created a Google sheet. This way she could visualize the parameters and write clear requirements.
2. Mentoring
We needed to solicit feedback from stakeholders, so I asked our intern to do this task. He wanted to use the Slack channel. However, we had observed that the stakeholders gave much better responses when they were shown problems in prototypes that had software elements. Using this quick wireframe we drew up, the intern got much more relevant and succinct stakeholder feedback.
3. Technical design sprint
Since the user would need a seamless selection of nested measures, we did a design sprint with the developers to ideate on the best technical option for a cascade menu. We used an easy wireframe prototype so we could iterate as we spoke.
4. Design thinking
We had to step back and look at our design through an empathy lens. Measures can be unwieldy long sentences. Trying to view them in the awkward way we had proposed was going to interfere with the user making choices. So we ideated around how we could make the UI more usable, identifying several small changes that would significantly improve the experience.
5. Sketch mockups to re context issues
Our epic was moving along, but we still had issues that needed resolution before we moved to the story writing phase. Presenting a few Sketch mockups brought everyone up to speed and provided visual context for discussion.
6. Stakeholder design sprint
Armed with sketch mockups, and a reference prototype we ran a design sprint with the stakeholders to get feedback. Since we had so much visual material for them to respond to, they were able to effectively help us define the crux of the issues.
7. Stakeholder Q&A
Our design sprint had proved very insightful and led to a Q&A session to resolve the issues. Again we used our reference and wireframe prototypes in conjunction with an explicit Google doc. This allowed us to visually work out resolutions on the fly and codify them for everyone’s approval in real time.
8. Explanatory Mockups
We had arrived at a resolution, and were ready to write the stories for this epic. I did numerous explanatory mockups, because in the case of these stories the pictures were more helpful than the gherkin!
9. Change in wording to meet DoD
We had focused so much on the selection of measures, that we completely missed the fact that what we built was not actually a filter! Using our wireframe we were able to quickly shop around our proposed language changes and make sure that the developers could meet the definition of done and deliver MVP within the duration of their sprint. Lesson learned: don’t get caught in a rabbit hole, wireframe everything!
10. Sprint review of MVP
The MVP the developers delivered at the sprint review was exactly what we asked for. The stakeholders were delighted, and felt the resulting reveal was easy to use, especially given the complexity of the task.
