Shape Up Forum

Design, User Research & Shape Up

Hi everyone !

How do you manage to find enough time to conduct user research and user testing on design prototypes before starting to build ?

During shaping there’s only a very high-level UX thinking. When building starts the designer is always urged to produce high-fidelity screens for the devs specs. I can see no time to have a thorough work on UX/UI research in between.

Also, we’re far from the 1:1 ratio on devs vs. designers that is described in the book, so our designers have to work on several projects as they start.

Do you have any clues on how to work this out ?

1 Like

Sequencing UX-R activities is something I’ve been trying to figure out myself, and my view on this has evolved since starting Shape Up.

To protect your time to do effective UX research, two ideas we’ve tried with varying levels of success:

  1. Offer to write pitches for research initiatives. Then you can propose appetite and problem scope. This way, the betting table might better understand trade offs if they skip/compress research. (Make sure your pitches convey the potential downside risk of not doing proper research.)

  2. Take UX research out of the cycle and make it part of the shaping flow to inform pitches. (So once the work is shaped and bet, it shouldn’t need further demand-side research.)

I’ve grown to prefer option 2 over 1, but in either case, try not to make research a blocker to the delivery team, so you avoid that pressure of having to squeeze it in.

FWIW, one of the great benefits of Shape Up is how we’ve eliminated the need to do hi-fi screens for dev specs. We have a style guide and lo-fi sketches/wireframes, and let the delivery team build from there. As for usability testing (for us, that means testing the product once coded), we do that in the cycle itself as a delivery team task.

I know (from painful experience) a high dev-to-designer ratio can be tough, because you have competing priorities for your time. Best of luck!

4 Likes

Thanks a lot for your answer !

I’m more into your second option as well, although it would require a hier dev-to-designer ratio as you said.

We’re still working on having a UI kit & design system that would offer more independency to the devs on building new features. I’m sure this will help as well.

Yeah, I feel the same pain. We are far from solving this issue, but here are my thoughts:

  • If we are in a situation that we know that this feature is the priority for the next cycle, but we feel it’s not shaped yet, I simply prolong the cool-down period for one week. And I may ask developers to do more technical research or proof-of-concept, or we agree to run 4 days Design Sprint.
  • Generally, we are using Design Sprint as a way how to Shape Up project. The good thing about it is that is a well-structured methodology, where you know that it will always take 4 days. Usually, after 2-3 days you know if you’ll get to shaped state or not.
  • If we feel that it’s something bigger, then we prepare a research mini-project that consists usually of 1-2 weeks of UX research, one week of Design Sprint, and one week of follow-up.

As I said, I think we are far from perfect in this area. But this is the approach that we are trying now.

3 Likes