Design sprints are a great way to allow a team a shortcut to learning without building and launching an application. Critical business questions are also answered through design during design sprint. I recently concluded a design sprint with our lead engineer and the situation was quite a learning experience. I will share what happened during the sprint and then share my reflections.
The company I work for is currently based in the US specifically in Kansas City. They are a small startup of about 10 people. We had our first kick off on Monday. During this session, we had various introductions from both me and the lead engineer. In addition to this, we added something interesting about ourselves. Keep in mind the lead engineer, Ryan, is also the sole developer on the team. We then had a deep dive into product offered by the company and the problem it was trying to solve. I had a couple of questions that I asked him that allowed me to be on the same page for what we are solving for. It was a lot to take in for day 1.
On day 2, we had another session where we discussed what we were going to build and how it was related to what he had built before. I had a few solutions on how to approach the idea. But then Ryan threw a few bits and pieces of information which had my ideas irrelevant. This led me to have a brainstorm session of understanding the problem. Why this approach? The team did not consist of a designer and Ryan had no working solution of what the system should look like but he knew what it should solve for. This immediately led me to think of a design sprint. I informed him of the same and told him how to best approach the situation to solve for the problem. I gathered a few resources relating to having a design sprint. The best resource I felt was from this link (http://www.gv.com/sprint/)
Day 3 came in and we had already discussed much of the problem. The most bit was to follow the timeline given in the link. This is where we discussed solutions of what we were going to solve for. We used stickies.io to portray ideas for the solutions we had. What was difficult about this day was that Ryan added a few more pieces of information that I had not considered yet. We had to go back to the drawing board and discuss what the problem was. The problem was that we had to cover a wide range of issues he had when developing the system. After this session, we agreed that we were on the same page with the array of issues to be considered before solving the problem. We also allowed ourselves to break off and sketch up our own solutions.
On day 4, we discussed the mockups we had but, Ryan did not have time to sketch the mockups with the tools we had so he drew them on paper. I went through the mockups I sketched and explained what I had in mind when I had drawn them up. He gave me feedback about the different sketches. This was also a hard day as Ryan quickly realized he had not communicated all the issues well. We discussed them again and we moved to a much clearer approach of how to solve the array of issues. There were ideas he wanted to address but he realized that an MVP was more important and we discussed some ideas we could add for later.
On day 5, I had re-sketched the mockups based on the previous day’s discussion. This day’s discussion was much more fruitful but some mockups were still lacking on some issues that were not fully addressed. I suggested that we can iterate on the mockups that were not fully addressed. In addition to this, I also suggested that since there are some that are ready, we can go ahead and add task stories for them to be built rather than waiting for all the mockups. He agreed to this and the idea to iterate on the mockups that were lacking on the concept.
Some Key takeaways
- Get to understand the whole problem first. This allows you to focus your solutions on the whole problem and probably have a combinatorial effort when discussing each other’s mockups
- Allow yourself to be in the mindset of the design sprint. Make sure you all have time to discuss the problem, get solutions, agree on the best solution and move forward.
- Choose your online tools wisely. Ryan uses a different Operating System from mine. Balsamiq cloud is good for quick mockups(wireframes), stickies.io for quickly getting ideas across, having reflections, choosing what works well and what does not work well.
I am curious to know, how have you approached a remote design sprint? Did you have a designer do all the work or did you involve them?
Top comments (0)