Ivana Stojanovic, UX/UI Designer at HTEC
Last month, one of our project teams used this methodology to solve a problem they had with a particularly complex feature and were quite enthusiastic to share the process. The entire team joined forces to tackle this problematic feature, and tried to figure out how small adjustments could affect the flow of the platform, and what the ultimate solution could be. The design team assigned to the project was eager to dive into it for this feature and shake up the atmosphere on the project.
In recent years, this methodology, which was launched by Google Ventures, has been trending all over the world as a method of producing better ideas in a new and inventive way, which actually does not take a lot of time. This approach is meant to help build and test prototypes in just a few days, which means that a process of this kind helps teams save time and money during the implementation of the design and also aids the development of new ideas.
Our Design Sprint involved ten people – three designers (two working directly with the team, and one operating from New York), a project manager, a scrum master, three software and two QA engineers. The team was very interested in the idea because they were all involved in the process of creating the flow of the new functionality, and this was a chance for everyone to be creative and look at the problem from the end user’s perspective.
One of our senior designers was the facilitator of the Design Sprint, while another was assisting the process and equally participating with the rest of the team in solving the feature problem. The team was introduced with what the process would look like, what the purpose of a Design Sprint is, and what its steps would be. Here is a summary of the introduction:During the first day of the workshop, a conference room was booked and equipped with sticky notes, colorful markers, and sweets – the setting which helped the team get creative and put their problem-solving hats on.
The first phase was the understanding phase, which included mapping the user’s needs, behavior, purpose, problems, and goals – the key points around which the team would have to work. After they had clearly defined the weak points and described the user’s journey and possible steps, it was time for the next phase – the sketching. The engineers showed concern that they were not talented at drawing, but were encouraged by the designers that this was not an art competition, but a way of brainstorming ideas on paper and coming up with new potential solutions to the problem by sketching. What came as a surprise was their conciseness and precision in the ideation phase, and their ability to come up with rather straightforward solutions. As a result, by the end of the session, the team was satisfied because they got a confirmation that all of them were completely aligned in regards to the requirements, the problems and the weak points, as well as the goals for this particular feature. This method proved to be a good starting point for reducing the time spent on internal meetings and iterations, and showed that building ideas together, as a team, also leads to building up the positive energy and enthusiasm about future work.
The excitement was still there during the second day of the workshop, and the team took out the solutions from the previous day and pasted them onto the board. The conference room was nicknamed HTEC Museum (and given a new hand-drawn logo), because of all the sketches and drawings put up around the room. After a few minutes of silent reviews, the idea was for each of the team members to use sticky notes and write their opinions for the offered solutions and then have a vote for the best three, called Dot Vote. The upside of the entire process was that all the proposed solutions were rather similar, because the team had been working closely for the past couple of months, and they had similar ideas for the concept and the direction in which the functionality should develop. It seemed that the final results were reached effortlessly, and some of the future goals immediately appeared easier to reach. However, the key was in the objectivity of the team when it came to observing the problem and the friendly and humble approach they took from the start – they were keen on learning from each other and accepting any kind of feedback with an open mind. All of this led to a winning solution, and the team felt proud of how quickly they finalized the decision phase.
The next stage was prototyping, and the team focused on the storyboard, the flow, building the UI, and the interactive prototyping. By the end of the day, the feature was ready for testing. InVision served as a prototyping tool, and the facade that would represent the final experience was created. The moment of truth came on the fourth and final day when the new feature was tested with real users. Although some changes had to be introduced to the design after the team had received the user feedback, everything was just about ready for implementation. Validation was definitely completed before the team moved onto the development process, which gave them more certainty that they were on the right track, and confirmed that they had the right solution which corresponded to the user needs, and would further offer a satisfying experience.
At HTEC, we love sticking to trustworthy, proven design principles, which are the pillars of quality design, but we also enjoy being up-to-date with trends and testing out the newest methods and ideas for project organization and development. Moreover, what this Design Sprint helped us realize is that involving the entire team in what may not be their technology or expertise could be a useful perspective into solving a complex problem which affects everyone on the project and furthermore helps engineers have more insight into the UI and UX part of the product.
If you liked this article