On the 1st of August we started out our internship at Subvisual. The main goal was developing a new product consisting of a financial app that would deal with the process of organizing and registering all the financial data of their organizations. Our target audience would be early stage enterprises like tech startups and small tech companies. Growing a business healthfully is a huge effort by itself, so why not clear the path of minor tasks that are simultaneously so important? So the problem was identified and our opportunity was here.
Design Sprint
We were introduced to this new methodology that would be used to develop the app, identifying the problem and testing the viability of our solution. It forces the team to work together towards a mutual goal, in a collaborative environment where everyone has something to say and the opportunity to share their ideas about the project. This framework has many advantages over other product development methods, by establishing a well-defined set of “things to do”, while still being highly adaptive.
Also Design Sprints are a considerable undertaking, especially if you are new to them. This is exactly the position that we were put on by our mentors at Subvisual. Truth be told, we were not very fond of the idea in the beginning, yet we could all agree that it would bring value to the process of conception and improvement of a product. So onwards we go, like true explorers, into the deep and wild realm of Design Sprint.
##Through the 5 different phases
###Learning process
On the first days, during the Pre-Sprint and Understand phases, you could feel the awkwardness in the room. We barely knew each other and here we were, trying to develop a product together. At this point interviews were done to several financial managers to test the viability of the product and find which problems they are facing when it’s time to do their accounting. Then we explored how others were solving their user problems and what we could do differently and better than them.
###The Orchestra
During the understanding phase, we started to gather all the existing information like the definition of the business opportunity and who our customers were. Most important, with some assumptions debunked, we started defining our problem statement through potential problems and job stories, reaching our job-to-be-done. This step was in essence our value proposition, which was creating an app where we could offer a “solution that would centralize and automate the process of organizing and record all the financial data”.
With our business model canvas filled out and our job-to-be-done defined, we could now define the critical path, where we design the step-by-step map of the user’s most critical experiences. At this stage we had some issues synchronizing our ideas and tuning our communication but the team soon began working as an orchestra.
###Creativity
The improvement in our communication and our ability to create several paths for our product during the Diverge phase speaks loudly about the virtues and strengths of a design sprint, taking advantage of the synergies between collaboration and creativity. With this exercise completed we were able to start creating our storyboards, where we had the opportunity to discuss and vote on the most important features that our financial app should have.
###Personality
After the creative process, we started to chop our ideas up, shaping them into a single prototype that could fully convey our ideas to the real world. That was downright amazing. In this [Converge] (https://github.com/thoughtbot/design-sprint/tree/master/3-Converge) phase we started by recapping the previous phase, analyzing the best features and their possible conflicts and compiling all the information that would create our final storyboard with all specifications for every step of the our financial app.
###The Cherry
The cherry on top of the cake was the possibility of testing and validating all this work in the final phase of the sprint, with our Prototype testing. Putting our ideas on the line for other people to evaluate them brings this process to a full closure and is a good recall to reality, after the intensity of the design sprint.
##Conclusion
At the end of the sprint team members should agree on a concise idea of what the product should be, not only because they’ve participated in the process of assembling that idea, but also because they’ve listened to and discussed other member’s opinions.
None of us dreamed about accomplishing this much. The time-boxed and structured nature of design sprints really helped us to focus on the objective, while the several exercises we did put our creative flow running wild. Moreover, the process led us from random teammates into a cohesive and functional team. More than any outcome for our product, we think this was the main key result of this design sprint.
- Subvisual's Summer Campers:
João Magalhães, José Gomes, Pedro Araújo, Rui Bogas