Our product and design team is seeing a strong growth in both capacity and authority over software projects we get involved with. We are on a quest of finding a framework that will produce the most value for our partners in a consistent manner.
This blog is about our first implementation of Google design sprint for the staffyourself project. You can find more information on the project here.
As it was our first try, we might have veered away from the original process a bit, but the attempt was hugely successful and timesaving. The best part about this process is that it insists that different roles meet in the same room and work together on a product concept and design.
This was the first time that the previously sequential process was done in parallel and the client worked together with the product management team and design team to produce a fully designed and user-tested product prototype. Check out our take on Design Sprint and get inspired to try it out yourself.
The sprint framework contains five stages:
- Understand
- Diverge
- Decide
- Prototype
- Validate
We repeated this process for 3 full sprints and finished with a MVP prototype that was ready for development.
Understand, Diverge and Decide
This process involved client representative, product team and UI/UX designers. Our first step was to interview key stakeholders and find out what they needed. Next, we investigated competitors. Finally, we identified and reviewed core use cases that we had collected in the first two steps.
Once we had the basic information about the project needs, we sat down and talked about user flow maps, client needs and business goals. Each of us took time to understand both cases and explained them to the others. We created simple user flow maps and sketches of how we saw the flows.
We had two cases:
1. Employer
2. Employee/Applicant
After we had collected all the information we needed, we separated. We realized that we each had different ideas and that they could not be displayed in one prototype, so we each developed our own. We also did not want to influence each other’s ideas. So idea was to work together separately and spend a day working on each other prototypes.
After a day, we got together again and showed each other our work. Our prototypes were different in some places, but similar in others. There were many great feature ideas and concepts in all prototypes. We agreed on the best ones and decided on features we wish to see in the product.
Mockup
We offered two mockups to the client to choose the overall design style of the product. One design was more serious with more detail, while the other was playful and vibrant.
After one was chosen, whole design team started working on improving it and implementing client’s feedback before we started validation process.
First mockup
Second mockup
Validate
The client is one of our main users, so reviewing and validating our work with him is a form of usability testing.
In sprint 2, we performed usability testing with other types of users. These results helped us to create an improved third version.
After the third version of the design (sprint 3) all user types (one of which is our client) were both satisfied.
Lessons learned
There is no secret recipe for Design Sprint. You are creating your own rules, and every time you do one you get better at it. Sprint is not made of prescribed steps and methods – it is your own process for solving big problems without a lot of time, effort and money. Someone called it a rocket booster, and we think of it that way too. It may sound crazy – but it really seems to work. You should read about other people’s experiences, but you can never replicate someone else’s work. Risk, try, find your own way and explore new paths. You just need a strong team, an open mind and focus.