Blockchain for Medical Studies: a Project in a Hackathon
Intro:
The medical study app is a powerful blockchain decentralized application and a unique solution to a real-world use case. The decentralized application or ‘DApp’ acts as a recruitment tool for medical studies. As a bonus, once recruitment is complete; the Dapp additionally fully supports questionnaire-based studies. This DApp is a concrete example of a hackathon project that was based on the planning methods described in my previous blog post.
The medical study’s GitHub repo:https://github.com/godfreyhobbs/hc_study
The Dapps demo video
Overview
The medical study app was created with just two days of structured hacking. Anthony and I used the following simple steps to successfully planning a project during a hackathon:
- Creating the design statement
- Prototyping with storyboards
- Timeboxing tasks
- Checking in at relevant intervals
The above steps helped us focus and effectively coordinate as a team. Larger teams will see even more benefit.
Design Statement
Before we created our design statement Anthony and I did the following:
- We understood the domain of medical research
- We narrowed the domain to a problem subset and agreed on the problem of medical study recruitment
- We deeply understood the problems related to medical study recruitment after some discussion
- We agreed that medical study recruitment is a real problem worth addressing
Screening phone tag was one of the big problems we wanted to fix about medical study recruitment. Traditional medical study recruitment screening requires a phone call but lots of folks seem to never answer their phone. So we wanted to eliminate the need for a screening phone call.
A design statement is a more structured definition of the problem by making the following concrete:
1. What problem are we solving?
2. Who is the user that is suffering real pain from the problem?
3. What will the situation look like for the user when the user’s problem is addressed?
There is NO talk of HOW the technical implementations will be undertaken. At this stage, we are just bounding the problem.
The design statement template is the following:
How might we improve _(problem in the domain)__ for _(user)_ , so that _(user-focused outcome)_?
Expert Tip: Use this template!
For the medical study recruitment project we came up with the following:
How might we improve medical study recruitment for researchers, so that researchers can save time and money while remaining compliant?
Prototyping with storyboards
Next, we created a full storyboard for each step in the user flow. We drew the buttons and the text inputs with markers on big poster size pieces of paper. We wanted to make sure that each screen did not have too many buttons or controls. Finally, we posted the screens in order on an easily visible wall.
Our storyboards were then used to create a list of TODO’s, our project’s backlog. We used sticky notes to come up with a list of tasks and features. Our backlog included all the most critical features needed to make the screens real.
For each card as a team using the design statement ask if:
1) Is this card align with our design statement,
2) Is this card absolutely critical to the functioning of the app
Pro tip: Saying out loud the design statement and then the card helps
Make sure every feature added to the backlog list complies with the design statement. The clock is ticking, any features NOT aligned with the design statement are a big waste.
Next, we refined the backlog removing some tasks that did not really align with the design statement. We also made some sticky notes for stretch goals that would be worked on at the end and only if we had time.
Check-in
We did a few quick check-ins to gauge the progress of our team. Taking breaks was essential.
Focus on getting things working first, then getting things pretty later.
That’s about it!
Good luck with the hacking!
