During the first sprint, we both validated and invalidated some of the assumptions we made about the solution to the Merck Developer Portal. Several problems and insights arose that we hadn’t initially anticipated. We spent a few hours reviewing aspects that we learned, as well as others that we felt we could expand upon. We felt that another sprint would be the best course of action to collect our thoughts and implement some of the new learning.
Since we already had context from our Understand Phase from the last sprint and had already reviewed the findings from previous tests we conducted, we felt that we could shorten this sprint to three days.
Day One – Diverge, Converge
We placed the challenge statement back on the whiteboard, along with the list of major problems that we found from conducting the user research / product viability tests.
- How do we quantify time savings?
- How do we discern the difference between post types?
- How do we enhance connecting people?
- How do we show content relevant to each user?
- How do we handle versioning / interacting with / updating code and assets?
We first ensured that these questions related directly to our main challenge statement. We then conducted a quick sorting exercise to prioritize these problems. My initial gut feeling was that some of the questions wouldn’t be as relevant to our challenge statement. We each ranked the questions on a scale of one to five on post-it notes by placing the appropriate number with what we felt was the proper order. Interestingly enough, quantifying time savings fell to the bottom of everyone’s list, which allowed us to drop it altogether. Similarly, we all felt that handling versioning assets shouldn’t be something to worry much about.
We then spent most of our time working through discerning post types, connecting people together, and showing relevant content. For each of those issues, we dove back into mind maps, crazy 8s, and storyboards. The user research seemed to help us all get on the same page because we converged quite quickly for each one of the problems we listed. We ended up whiteboarding the wireframe together with the specific pieces of the app that we wanted to have interact in order to test our assumptions.
Day Two – Prototype
Many of the solutions we wanted to test pertained to interacting with forms. Since the last sprint with Invision left me wanting more interactivity for users working through the forms, I decided to build this with HTML & CSS. I was able to work through the prototype quickly using Jekyll and GitHub Pages with Bourbon, Neat, Bitters and Refills.
Day Three - Test
We put the new revised prototype through another round of viability testing with four more developers. We had them run through the new prototype and answer some of the same questions we had from the first sprint.
This time, we felt that we validated many more of our assumptions, and it seemed as though we were headed in the right direction. Though we felt confident enough to start development on the project, we wanted to make sure that we were continually validating these ideas while building the application. We implemented a plan to begin usability testing as we built upon it every two weeks. This would help us ensure that we were staying on track with the development of the product.
