A couple of weeks ago the Kin team gathered in Chicago to run its first ever design sprint. We modeled our week after the Google Ventures Design Sprint, which challenges teams to research, design, build, and test a live prototype with customers – in five days.
The product we worked on was an employee reviews and objectives feature which we’re building this spring. Much like time-off management, there are as many flavors of performance reviews as there are birds in the sky. Unlike time-off management however, software is often part of the problem in the review process – existing products have a tendency to get in the way of people improving as individuals and as part of a company. We used the week to envision a tool that facilitates more productive employee reviews, rather than yet another piece of technology that pushes humans farther apart from one another.
Jen the Pen reports for duty as the sprint’s facilitator.
We also wanted to change the way we build things here at Kin. The team we have today is different than the team we started out with two years ago – in body and spirit. The current development team, composed of Brandon, Jes, and Ka Wai, haven’t built what we call a “primary feature” in Kin yet. They’ve been working together for about six months and, while we’ve shipped new features and improvements during that time, we haven’t started from scratch on a new concept. This is the first time we’ve worked together in this capacity – so it made sense to shake things up a bit and ensure everyone climbs on at the ground floor.
How we’ve done things in the past
What precipitated the design sprint wasn’t necessarily the quality of the end-product we’ve shipped in the past, rather the challenges we’ve experienced in the process of delivering the final goods.
In the past, we’ve often had to make very fundamental design decisions after a feature’s first iteration is already built. That’s resulted in significant changes to the product late in the game which, aside from being inefficient, is bad for morale and revenue. So, while we tailored our development cycle to be more accommodating to smaller changes, we also arrived at the Google Ventures Sprint as a way to root out the flaws that created the proverbial mess to begin with.
Change happens, and we embrace that. With design sprints, our aim is to be more responsible about the size of design changes later in the cycle by doing the largest discovery before we write a single line of code.
Build a better product. Build better trust.
The Kin team is composed of seven folks: three engineers, a product designer, two account and support peeps, and myself. This specific approach to design sprints is designed to include every discipline from an organization, and it just so happens that the size of our team was a perfect fit for the sprint. Not too many, not too few.
Given the mutual inclusion of every discipline, it’s natural that the exercises within the sprint are designed to enable everyone, regardless of skill set or role, to contribute to the design, even as low-level as UI. The experience had no bias for visual designers or coders or CEO-types. The playing field was leveled for everyone.
A spirited conclusion to day two. Yeah, I just wrote that.
The fact that everyone at Kin contributed revealed an under-utilized quality in our team: depth in our bench. Every team member scraped together mock-ups, mind maps, concepts, and ideas. Every team member reasoned in favor or against certain ideas. Overall, we had seven approaches to employee reviews which canvased a whole lot more territory than we would’ve otherwise covered in a closed-door session with just one or two team members.
Knowing that everyone on our team can design a feature is a powerful tool. It’s built trust in the team as a whole, and instilled the confidence in each of one of us that we’re capable of it.
How’d it pan out?
We hit Friday in stride. The team succeeded in getting a pretty big concept out the door and tested in front of live customers.
The feature is broad though – a drawback in that we meandered off topic from the feature story at times. But, the silver lining is we have plenty of purview into how the broader feature will be structured.
The interviews themselves went well – Jason and Lindsay each conducted 2 customer interviews, leading the discussions and exploring the viability of the feature. One piece of prescient feedback from Jes after the interviews was that questions from customers exploring details beyond this week’s feature story should be approached as chances to discover customer needs, rather than challenges to the product’s viability. That’s something we’ll need to grow accustomed to in subsequent sprints.
Favoriting sketches and ideas via sticky little dots.
Will we do it again?
We’re not out of the woods yet in understanding the real impact this specific design sprint will have on both the quality of the product and that of our process. There are other facets of this feature that still need design and research (perhaps even design sprints), let alone the remaining work and iteration needed based on customer feedback. So, while we all feel that the first sprint was valuable and productive, we’ve yet to go through the motions of getting its output into production and out the door.
What I can say is that having everyone involved from the get-go means there is very little mystery in what we’re building, and little to no personal hang-ups about it either. That tells me there’s much less baggage heading into feature production for us as a team, and we’ll have a cleaner build, less testing, and less iteration toward the tail end of the experience. If that’s the case, then we’ll consider design sprints to be a fundamental part of the Kin product design process moving forward.