Matt Lambert

Check out my blog, or sign up to receive articles by email.

Do Design Sprints Work?

By admin on September 4th, 2014 in Agile

I’ve recently been trying to really polish my process for visual design and UX in agile. Although I feel like my process is getting better, as I covered in my post Agile Design, I still feel like there is room for improvement.

Are design sprints the answer?

I recently came across a couple of blog posts on design sprints. This looks like it might be the right direction to head. However, these posts kind of deal with the issue from a start up perspective. Although that is useful, I’m more interested in learning about using an approach like this on Enterprise software. Have you done something similar on an Enterprise web application project? If so, please leave a comment explaining your process.

The developers role

One of the biggest challenges I regularly face is to avoid being a bottleneck for other developers or the agile team as a whole. I was recently talking with another developer who followed a process similar to design sprints but he/she elaborated on it further.

When planning your UX, requirements, use cases, personas, etc… it definitely makes sense to involved some developers at this point. An approach to a feature you have in mind may make zero sense from an implementation stand point, so it can be really useful to involve the developers in the design process.

This will not totally keep them busy while you are working on design though. Another approach was to have developers work on designing back end services in parallel to your design efforts. At that point of the project, it shouldn’t really relate to the UI. That way you can all be moving forward, with no bottlenecks, without as much risk of work needing to be refactored down the road. Once your design sprints are done, there will be some back end architecture setup and you can get to the stories that integrate these two pieces together.

In the future, I definitely plan to try and use this process. What do you think of this model? Have you done something similar? If so, did it work for you team?


Like what you read? Check out my store over at Creative Market to support the blog and help keep the lights on. Files starting from only $2.
  • I have a quick thought regarding the avoidance of being a bottleneck.

    Even if you are temporarily a bottleneck to development, isn’t the idea that you are saving the team time, in the future, by thoroughly evaluating and assessing how to move forward?

    I appreciate that doesn’t help the fact that a bottleneck may exist.

    • I see your point but I think you will have a hard time convincing your PM that the bottleneck is worth the future time savings. It may be true but it’s hard get that point across in my experience. What’s better is if you can buy yourself time while not holding up others.

      • Yep – you’re totally right.

        It seems like the model you proposed is as close as you can get. They key is just trust between the developer and designer and flexibility if someone’s work needs to change by the time you’re putting the pieces together.

        Sorry I don’t have suggestions to offer : / but I enjoyed the article! The role of maintaining and building on to larger pieces of software isn’t always glamorous but I think it’s an underserved area in design conversations right now. Glad you brought up the topic!

        • Thanks Carolann, I thought the same about this subject matter so thought I’d start to do some blogging about it. You’re exactly right about trust between the designer and developer. That’s a historic problem. The best way I’ve found to address it is to learn a bit about development so you can relate to the developer. You need to meet them half way and vice versa

  • Chris Abad

    Hey Matt. I’ve run a few design sprints at Salesforce and wrote up the process here. Hope you find it helpful:

    • Thanks Chris, I will definitely give that a read

  • We use Jira and do a sprint at 9Lenses with the design team. We’re building enterprise software. I’ve attached an image. Happy to discuss more.

    • Thanks for that diagram, it’s really useful. I’m going to share it with our team’s product owner

  • adyus

    I think you hit the nail on the head with the idea of working in parallel. A future-proof design these days calls for API-first development. With periodic check-ins on some of the features that design would like implemented, developers can proceed while designers work out the kinks. Then, all sorts of front-ends can be created, whether mobile, web or native desktop.