The best way I've been able to explain "primary user benefit" to colleagues: after articulating the problem, look at how you describe the solution and ask "*how* does it help?"

Often, they realize that their problem definition is not actually crisp enough to answer that question 2 most common patterns:
- the problem is that customers don't have this feature, but now they will (not a real problem)
- the solution is that customers will no longer have the problem because AI/ML (not a real solution)

Don't confuse metrics with goals. The worst mistake in this genre is picking metrics before you've identified your goals. It's a similar mistake to picking your tools before you know what you want to do with them.

Why is it that "design should work more closely with X function" narratives are always about conceding to X's limits rather than improving X's ability to support design? Product, eng, sales, etc "requirements" are not laws of physics. And yet rather than help these people create better "requirements" the discourse always turns back to how to satisfy them (usually at the detriment of design's own incentives)

People broadly understand that designers "make designs"

But a "design" is just an artifact documenting design decisions for some purpose. Most stakeholders request (and many designers make) artifacts without understanding *what the artifact will be used for*—making it useless.🧵 btw this is why I call Figma et al "documentation tools" - they don't help you *make* design decisions, only to visually document decisions you have made. "Loop zero" for designers is looking at that documentation, realizing you don't like it, and changing the decision.🧵

Conversations about taste in the context of design are always fun because some designers are all too happy to call something out as "bad taste" without having any idea of what taste is *for* and the ways in which an object can be good or bad at achieving that purpose. Taste is a signal of belonging; a design can only be "good taste" or "bad taste" within the context of its milieu.

Positioning all objects on the spectrum of a single "taste" - as designers like Schiff and Schneider *love* to do - is an attempt to universalize their milieu.

Yet another reminder that the first step to doing anything is identifying the problem you are solving.

Critique of specific solutions or implementation challenges is not meaningful critique of the vision's desirability.

https://twitter.com/JuliusGoat/status/1097119860834926592

Start in the 3rd loop: is the thing we want to do desirable? Do we agree to work towards this outcome?

Then move on to the 2nd loop: Is this course of action going to get us to that outcome?

And only then the 1st loop: is the implementation working?

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

the annual ritual of checking whether the dry yeast has expired it's not lookin good

Storyboarding is a highly underrated design tool in the age of "well you can just use design system components to output a hi-fi mockup"

But storyboards serve a completely different purpose to mockups/wires - they focus the discussion on the desired *experience* and not just UI. My latest storyboard covers interactions between 4 different user roles, spans several hours of intermittent usage, and most importantly *doesn't have a single app screen* as the whole scenario takes place via SMS or retail interactions.

I bonk people who say "feature X makes it easier to..." on the head with my design stick.

Use absolute, not relative, descriptions to emphasize the specific things you'll be able to do today that you could not do yesterday. If you can't articulate this, you don't have a product. "makes it easier to X" is one of these four (the customer benefit)

It implies that there is a problem (it is too hard to X today) but that is a useless observation without understanding the *ways* in which it is hard to X which is necessary for a solution

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

Good design isn't "user centered" - it doesn't cater to individual user needs, and certainly not user wants.

Design decisions that prioritize these above the good of the community at-large, and then the user community, are the worst kind of design. It's not enough to "build empathy" for those affected by your decisions - that centers your authority over the community's experience.

Build a model of what people want by *asking them* and then keep asking them to make sure serving your users isn't harming non-users.

Most teams create metrics based on the logic of "try and guess why execs told us to build this"

Management picking solutions and teams selecting metrics is the exact backwards way to make a product.

Mgmt role = set business targets
Team role = find the best path to their target Targets created bottom-up have no executive buy-in, so they are meaningless outside of vanity purposes. You achieved X? So what?

It's management's job to build the hypothesis "if we achieve X, it will be good because..." and ensure that the important people agree with that.

It's difficult for me to reconcile that the same people who say they practice "design thinking" will tell you that design is when you draw pictures. Both approaches are just a mangled implementation of one half of a holistic design cadence:
decision-making🔁decision documenting

Design thinking is a bad way to make decisions, and design pixeling is a bad way to document them, *because* they are separated from one another.

Don't start with "we need a user story" or "we need a wireframe."

Start with understanding the conversation you need to have. Then select the correct artifact format to document the decisions made in the conversation.

Without the conversation, ALL artifact formats are wrong. The artifact is in a conversation with its audience. They need to read it, understand it, and *integrate what it documents into their mental model.* The power of the artifact is that it makes the outcomes of conversations consumable and actionable.

But it needs the conversation.

The fidelity of our artifacts should never exceed the fidelity of our thinking.

Documenting low-fidelity thinking in a high-fidelity artifact lends that thinking credibility that it doesn't deserve, and discourages further thinking. "We have the mockups, it's ready to build." Then when the build inevitably breaks down (either the product didn't satisfy the user, or there was too much unresolved ambiguity to ship) the burden falls on design: clearly *we* gave you enough input into your process for you to make the artifacts, past here it's your fault.

The design discourse always wraps back around to argument over "good taste".

The issue isn't that it doesn't exist, but that it develops over years of watching the industry evolve and rich with context-based nuance, but seen as universal truth by juniors who lack this context. "Good taste" is the tip of an iceberg, an amalgamation of many heuristics at an unconscious level - but balanced with the expert's conscious self-awareness; "is my instinct appropriate here?"

You can't plug someone else's taste into your work and automatically hit home runs.

On the topic of design tools, I would love one that captures the full design process:
-Finding and closing gaps in our inputs
-Sizing our effort to the required outputs
-Making the design decisions
-Documenting the decisions
-Propagating the mental model behind the decisions Inputs are very simple but usually glossed over in low-maturity orgs:
- Do we have a clear problem scope & success criteria, not just "pixel up X"?
- Do we have all the information we need, or barring that, the mandate to gather this information?

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

One fundamental mistake software design teams make is behaving like they are the main character in their user's life story, and not the other way around.

Design as if your user
-didn't want to use your product or develop expertise
-hasn't thought about your product for months I guarantee you that, with the exception of perhaps the iPhone's UX team, the role your product plays in your customer's life is a low-level antagonist

Fun question to ask hiring managers: how do requirements differ between this role's level and the role one level above it, and what work does this role get to do that demonstrates those requirements?

If they cannot answer to your satisfaction, the role lacks a Definition of Good Without a satisfying Definition of Good, good luck getting raises or promotions. Everything you do will be "doing your job" - and what's worse, every new responsibility added to the role will be "high priority."

Only a Definition of Good lets you focus on the high-impact work.

In output-first planning, present is clearer than future: we only know roughly what features we will build in Q4 but here are our Q1 user stories

In outcome-first planning, future is clearer than present: our Q4 goals are set, in Q1 we will look for the right paths to reach them It might seem like the output-driven team is more agile - after all, they don't plan too far ahead, right?

But because they commit to features over impacts, they actually sabotage their own ability to learn from what they release and pivot appropriately.

The conversation around shipping "low-hanging fruit" is self-defeating. If you prioritize low-effort, low-impact work, the team will optimize for low-effort, low-impact work.

Instead of starting with "what is easiest for us?" start with "how can we make high-impact work easier?" PMs have a massive fear of "unused dev capacity" - but if the choice is between delivering low-impact work and reorganizing to ship high-impact work in the near future, then having "unused capacity" is FAR more valuable than using that capacity.

This is a question asked in good faith but from the wrong direction.

"Customer satisfaction" is not a real metric. Designers must understand what satisfies their customers, and then measure that. Do not ask "how can we measure..." before you've answered "what should we measure."

https://twitter.com/marcorighetto/status/1569002750628741124

Orgs latch onto "customer satisfaction" because they lack the courage to say "customers care about this" and expose themselves to the risk of being wrong - or even the intellectual hassle of developing their own metrics.

No one got fired for measuring NPS.