The role of design(ers) within a cycle

[david]

We’ve run 3 full cycles so far and something that we’ve yet to nail is the question of how to integrate designers and design work into these cycles. I’m looking to compare notes with others who might have experienced similar struggles:

In Shape Up, Ryan explains how Basecamp usually staffs two programmers and one designer on a project. The thing is that their designers aren’t what the industry typically refers to as a designer, at least in my understanding.

When a designer at Basecamp gets started on a project, they start stubbing a UI in un-styled HTML to figure out the affordances so that a programmer knows what endpoints will be needed and in which format, for example. As the project progresses, they then start structuring and styling the UI in its final form.

When a designer on our team gets started on a project, they start converting fat marker sketches or wireframes into high-fidelity design files in Figma. These Figma designs are then input to a frontend developer on the team, who takes them and starts building the final UI. It is our intention that the designer creates those designs with technical feasibility in mind, so that we don’t end up in a position where we have fixed time and fixed scope. At the same time, frontend developers are encouraged to give early feedback on designs and work with the designer to iterate over the Figma files.

The goal is for the designer to come up with a design that fits within the scope of the cycle and can be picked up by a frontend developer without the need to change many things. At the same time, we’ve always still made trade-offs and changes on designs in the coding phase, like deciding not to build a new dropdown-button component which would look better but take too much time and instead going for a simpler version of two buttons side-by-side.

So far, we’re very happy with the user interfaces we’ve shipped. But the final product almost never resembled the design files 1:1, to the dismay of the UI designers. And the back-and-forth between designers that own the UI look-and-feel and frontend developers that have to build it all was always stressful. Not to mention product managers who act as copywriters.

My best guess for what’s still broken in this process is that we’re piling on too many integration problems:

• Product managers, who come up with the fat marker sketch or breadboard, have to integrate with
• designers, who come up with the designed UI and have to integrate with
• frontend developers, who finally have to integrate with
• backend developers.

When changes to the shaping document are made as a cycle is ongoing, for example through scope cuts or refinements, there is a ripple effect throughout the chain outlined above. Depending on how far the cycle has progressed, the designer won’t have time to reflect the scope cuts in the design files. Then programmers working on the frontend don’t have a source of truth anymore for where specs are coming from: the pitch document or the design file? This has been an issue in every cycle we’ve done so far.

That said, there are some benefits to the design role as we have it and that I’d be hesitant to give up. Our designers do not just work on the delivery track, but also join PMs in discovery projects (when they are currently not on another project). They can sit in on customer interviews, help facilitate workshops and then be sparring partners to the PMs when it comes to shaping an idea. They can also create interactive hi-fi prototypes to help validate an idea in discovery (something I believe Basecamp does not see any value in). Those hi-fi prototypes are also a great tool for PMs to get stakeholders and other teams inside the company excited about an upcoming development project. For us, they have proven to be a useful tool this way.

I’d love to hear of people who’ve had similar experiences and found ways to improve the situation!

[kevinsmith]

I’m very interested to hear what others have to say, but I wanted to highlight something that stuck out to me. It almost sounds like your designers are approaching this as if it were a project in a static medium rather than an interactive one. So much so that you’ve actually got 3 layers in your team’s version of the model presented in chapter 10: design, frontend, and backend.

Having such a bright line between design and frontend may or may not work (that’s something you’ll have to work with your team to determine), but the big trouble here is that your designers are completing their whole slice before anyone else gets started, which as you’ve noted results in a lot of wasted work and blocks everyone else until the designers are done. You want shorter integration loops within your teams.

Just like you don’t want to go too deep in planning a project before actually putting those plans into action (since the facts on the ground will inevitable turn out to be quite different than expected), I’d argue you also don’t want to go too deep with a visual design before you put it into interactive action. As Ryan recommends in the book, integrate a whole slice at a time. When it comes to work that must be done to unblock others, do only as much work as is necessary for the others to do their part in that slice. Anything more isn’t valuable. The frustration of your designers when they see the end product actually tells you how much wasted work is there.

[mattdonovan]

@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:

1. 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.

2. 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).

3. 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.

[david]

@mattdonovan this helps a lot, thank you for taking the time and explaining how your team is conquering this. I’m seeing a few ideas that I’d like to try for our next cycle. Especially getting designers to focus on one scope at a time, alongside the engineers, feels very much like common sense. I’m thinking: “Why haven’t I thought of this?” :o)

You were spot on with your recommendations and I’ll share how things go.