Thread by @PavelASamsonov

The business: hey we need you to draw some wireframes for this engagement

Me: Do we have a scope for the problem? How are the user's existing tools failing them? Are we resourced to answer these questions?

The business: nah it's ok they can be low fidelity wireframes

Design artifacts are not the deliverable. They just document the design decisions, and design decisions must be rooted in user research.

If you can't draw a direct line from the artifact to how the decisions it documents will be informed, you won't produce anything of value.

Before someone sets pencil to paper, it's really easy to think you have something while remaining pleasantly vague. Only when you need to render the artifact do you realize that there's no there there. It's up to the designer to say "hang on, I can't do anything with this."

Have these questions answered, or insist on the time and resources to answer them yourself: Who is the user? What is their goal? What blocks them today, and what is the consequence? What capability do they need to overcome that pain?

And: what are we NOT solving?

The business loves to come up with ideas for "a platform" that has dozens of vaguely defined users, workflows, and features. It is impossible to design for this kind of scoping. Set expectations up front: we need time to narrow down to the most important end-to-end slice first.

Most stakeholders don't know anything about design. They think that they can shove you in the vague direction of a problem and get ~*~magic~*~ back. But good design takes a lot of stakeholder time: sitting in on user calls, prioritizing, tightening the feedback loop.

A workshop effectively has a feedback loop of zero. You can even get the "I'll know it when I see it" people to be helpful. But you need to set the expectations for this kind of involvement way in advance - and define the mechanisms that will inject user insights into this space.

The first requirement for user insights is obviously user research. Proxies won't cut it. But you can't just go do it all alone and come back as a genius, because the stakeholders won't believe anything that doesn't confirm their own biases unless they hear it first-hand.

Similar to how the outputs of design are memetic and not visual, the outputs of research are *improved mental models* and not a report uploaded to the Confluence wiki. If stakeholders with outdated mental models don't recognize why your design is good, it won't get executed.

The other part of this puzzle is that when people say "low fidelity wireframes" they are usually thinking about Lorem Ipsum, which means the wireframes are doomed to be completely irrelevant to the solution. The lo-fi stage is when you need to get your content ducks in a row.

The main value of the lo-fi stage is defining the content and the timing of when the user needs to see it for it to be valuable. It's like acting out a script with stand-ins for the props and actors to see if the script makes sense. You can't do all that ahead of the script!

Stakeholders will love the opportunity to review, but resist being involved in the actual work. Getting them to feel the pain of their vague requirements is the only way to kill off the blind hand-off and develop a healthier collaboration process.

https://twitter.com/PavelASamsonov/status/1326612911469551619