@david This is something we continue to work through at my company as well. Here’s what our process looks like (not without it’s shortcomings, but it seems to work pretty well):
First-principles
The majority of the shaping and pitching is done by myself and 2 other product strategists. I often involve product designers and engineers in that process by asking for their take on a fat marker sketch or by stepping them through a breadboard to get another perspective.
However, we draw a very bright line between project work and pitching work. On principle, we don’t have product designers bouncing back and forth between shaping activity and execution on their project. Even if they’re not a particularly front-endy designer.
Different designers, different strengths
We have 4 project designers. 3 of them are exceptionally strong UI engineers. 2 of them work The Basecamp Way™, i.e. designing primarily in the browser. The other two prefer to start in Figma.
I personally believe both approaches have merit and that design software is getting pretty damn close to providing the kinds of affordances Ryan talks about needing to get from the browser. So I’m very happy to let our designers use the tools they’re most comfortable with.
Though I absolutely agree with @kevinsmith. Screens want change, so if your designers are creating mostly static mocks, I recommend getting them to at least create interactive prototypes.
Design the first scope
We started Shape Up this past fall and during the first two project cycles our less developery designers were essentially trying to mock-up and prototype the entire solution and we ran into exactly the problem you describe. This last cycle we asked them to try not getting too many scopes ahead of the developers and some really neat things happened.
First, I think our designers understood “scopes” for the first time. Shifting from thinking about the first thing they were going to design to the first thing their team was going to made them much more invested in the development and QA process.
That’s not to say they did a bunch of engineering or QA on their own, but they cared. And because they cared, they paid attention to the details of what was getting produced and made sure each scope that shipped was something they felt proud of.
They were able to do this for a few reasons:
-
There was more time to adjust.
It feels a lot less to chaotic to circle back on a single scope and make it shine when (a) that scope is the only thing you’re looking at and (b) there are 4 or 5 more weeks in front of you to complete the entire project. It also creates an early opportunity for the engineers to paying attention to the kinds of details they missed on the first scope. -
The adjustment opportunities were obvious.
Looking back at an entire 6 week project that wasn’t executed to your standard makes it really hard to prioritize what, if anything, there is time to fix. But if you’re just looking at the execution of the most recent scope, there are much fewer changes (and those improvements compound – meaning the next scope benefits from them). -
There was very little sunk cost.
As an engineer, completing and entire 6 weeks of work and then hearing that it’s kind of janky feels awful – especially if there’s no time left to do anything about it. But hearing the same thing after a week or even a few days of work feels actionable. A mature engineer is actually grateful for that feedback.
Hope that’s helpful. Let me know if I’m off-base on any of this as I definitely feel your pain. This is not the way most of our industry works and so there isn’t a lot of precedent set.