Product design

Design driven epic


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.


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.


Nonprofit program staff.

This epic addressed the challenge of too many questions

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.

Google sheet for visualization and requirement definition

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.

Wireframe for 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.

Wireframe for technical design sprint

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.

Wireframe with empathy notes and ideations

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.

Sketch mockups for visual context

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.

Design sprint with stakeholders

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.

Q&A with stakeholders to resolve issues
Demonstration of selection options live in the wireframe facilitated decisions

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.

Intuitive nested measure selection
Measure selections that are easy to read and navigate
A much shorter list of questions
Forms that were generated quickly and easily, and ask the relevant beneficiary questions