A marathon project – evolution, pitfalls and lessons learned
Context & Challenge
Some projects take a long time. Often we think we understand something, then the design process reveals that it was far more complex than we expected. Sometimes priorities change and we find ourselves circling back to a project more than once as products evolve. Either way, it requires resilience and a growth mindset to continue moving the ball forward on a marathon project.
Users
- Logic model practitioners
- Program managers
- Program staff
Before & After
Phase 1 – prototyping
Sample calculation
When we started the epic, the stakeholders showed us this sample calculation (word problem), and told us that the user would need to be able to easily construct a similar calculation in their logic model framework.
Initial wireframes
We started by interviewing stakeholders and drawing up Initial wireframes. Pictures helped get everyone on the same page about how we should structure this epic.
Latent requirements
Interacting with and talking about the wireframe caused the stakeholders to recognize latent requirements, identifying the need for sub calculations and sources.
Companion prototyping
We sensed this module might be interaction heavy, and the design process would be better informed if users could “try things out” along the way. Early on we started adding little CodePens that the stakeholders could tinker with and give us feedback.
Testing prototype
Making the cerebral tactile was key to the evolution of this project. We jumped in and built a quick testing prototype so we could see how stakeholders would go about using the mechanisms to structure calculations.
Feedback from sales
After playing around in the prototype stakeholders from sales gave us invaluable feedback that made the system immediately easier to use. Unlike mathematicians and economists, most users cannot hold complex equation parts in their heads. They pointed out that the source of the variables needed to be visible. Otherwise the user would not be able to keep track of what source the variables were connected to.
New product owner hand off
At this juncture we hired a new product owner who jumped in and wrote the initial calculations stories. Unfortunately he left the company just a few months after he started. In handing over the story creation we let go of the details expecting he would mention anything that was not complete. Boy was that a mistake…
Phase 2 – the messy middle
Incomplete stories
We returned to the stories six months later only to discover that he had not articulated the details and the stories were incomplete. In short, an epic in the backlog that I was confident was ready was not remotely ready.
Lesson learned: Make sure *YOU* fully understand the stories in the backlog, especially those that constitute MVP.
You can read about this portion of the project in my post about Deep collaboration. It is an exciting story with wireframes, rapid iterative cycles, lots of design sprints and truth be told it was some of the best and most rewarding work I have ever done.
Phase 3 – the orderly progression to MVP
Incremental builds
When it came time to build MVP in React, I parsed the stories out for the developers so that they could build the table in small manageable chunks. Instead of asking for the whole table to be delivered across multiple sprints, we got individual parts of the UI and behaviors completed iteratively sprint by sprint. This way we broke down the task and made sure that each individual part was completed before we moved on to the next set of parts. Our previous stories for this sprint were too vast and vague and that got us in trouble. This time I wanted to make sure everything was broken down into component parts so that the code could be effectively and efficiently delivered.
Interaction and usability
The developers were able to build the calculation table fairly quickly in React. The portion that took the most time was getting the usability perfected. This included tweaking the UI of the table and getting behaviors and notifications functioning correctly.
The first issue we encountered during testing was that the status of a variable was not immediately evident. 9 out of 10 users could not look at the table and identify what variables were complete or incomplete. Additionally we identified that there was a third state where a variable could be complete, but not be populated with any data. I decided to test out the resolution of these issues by swapping in icons instead of text and the recognition of “variable completeness” skyrocketed. Even the developers chimed in with positive opinions!
The second issue we encountered was around notifications. Calculations can go awry when the smallest link is broken. It was important that the problem and troubleshooting solution be evident to users. We added simple highlight colors to existing UI and employed big obvious sweet alerts so that the notifications would be very obvious.
Real life calculation
The calculations module is an elegant usable solution. The following shows you a real life calculation.
Marathon project learning
Although it was a marathon, we learned a lot along the way. We learned to be resilient as a team and continuously frame setbacks with a growth mindset. We carried this learning through to other projects and incorporated it into our team culture.
