We've ran week long sprints inspired by GV for clients who have rough ideas and a smaller budget. We used them to quickly vet an idea and lead into a longer engagement if there was any initial traction. We've had good success but it's a very intense week for everyone involved. If you're in an agency setting, you definitely need a dedicated client who is available and willing to collaborate. I think it's an effective method but could lead to burnout really quickly depending on how often you run them.
Cool Jake! I've been doing the GV sprints for a while, and after two or three in a row we face the burnout that you mentioned. So now we try to have a "week of" to start a new sprint and in some cases we even do two week sprints to have more time to chill.
We've adapted the GV design sprints a bit, basically aligning the design sprints with the two-week development sprints (I'm the sr. designer at a software development company), and we run sprints continuously.
That extra week is spent adding in a fair bit more traditional research, and usually creating prototypes using more-or-less production ready code. Which takes a bit more time up front, but saves us a lot of time if our tests are successful. (Really novel ideas where we have little to no existing code to build on is still done in Sketch and InVision, though.)
Works really well for us. It means all new features and interaction patterns get run through a design sanity check, while keeping design an integral part of the product development cycle.
I've implemented a very similar philosophy of testing the "contact surface" of a product as soon and as quickly as possible. We run a 2 week cadence though which makes it easier to sustain, week after week.
The objective is to be testing some aspect of our product with about 6 people every 2 weeks. That means the team has to develop a hypotheses, iterate on solutions, build a prototype and test every 10 days. But it also leaves time for all the other responsibilities they have like supporting our engineering team.
I've found that the key to keeping this cadence going is for our researchers to schedule tests irrespective of where the designers are at in their process. That forces the designers into a quicker, tighter feedback loop.
Nice Harper Lieblich! At my company we've done the same thing. After two or three sprints in a row we were feeling exhausted, so we decided to change to a 2 week model and having 1 week of rest to start a new sprint.
How about prototyping? At TaqtileBr most of the times we use inVision to test with the users.
My team used Google Design Sprints last year for a month or two. We were launching a brand new iteration of a product and wanted to rapidly design and prototype, so these worked fairly well.
However, the process ended up being a little overkill for smaller features and additions to our products, and my team couldn't maintain every step of the process every single week, so we kind of stopped following it.
Hey Matt, I feel you! At my company after doing 2 or 3 sprints in a row we felt exhausted! We still do design sprints but we've changed for a two week long approach and we have one week without doing sprints after initiating another one
We did something very similar on a project about a month ago, it was productive, even in less than optimal conditions (primarily absentee stakeholders). What do you want to know?
Hey Athur, I was just wondering how everyone is doing at their companies. Where I work we've been doing it for a while, but we're still figuring out how to balance work hours and fatigue. After doing 2 to 3 sprints in a row we felt that it consumes a lot of energy of the team. Now we try to have 2 weeks of work with 1 week without sprints that helped a lot. Another thing that it's really hard here it's to recruit users, since our company is in Brazil Craig's list is not an option :(