Job title meanings are tricky because every role has 2 buckets:
-Activities the org expects (provides inputs & demands outputs)
-Activities the org tolerates (acquiring inputs & applying outputs costs political capital)
2 titles may do same activities, but in different buckets.
This is the problem at the root of explaining what a Product (or whatever) Designer actually does.
Many orgs expect a designer to accept ideas and produce pictures. We know the strategic user-facing work is necessary, but it goes against this grain of expectations.
And because it's unexpected (the designer has no official mandate), they spend a lot of time on:
-trying to get input data (being in the right meetings, meeting real users)
-convincing others to accept their strategic outputs (beyond mocks attached to Jira tickets)
These orgs usually have someone that (they think) is doing this stuff - Sales talk to customers, PMs do strategy and politics.
No one will notice if a designer doesn't do the "unexpected" work because no one recognizes that work as necessary for the expected output (pictures).
When designers say that a product designer does X, what they mean is that X is integral to the product design process. It does not - unfortunately - mean that every product designer is empowered or even allowed to do X, but only that they must advocate for X in the practice.
This is - fortunately - not the case for all such roles. But it's an important distinction because the design process does not change; regardless of how your org assigns activities to buckets, they are all still necessary to do good work.
The only strategy I can recommend is: make the "unexpected" work visible, and make it make sense. As your colleagues get used to seeing it, you'll get closer to that point of true influence: when someone says "ask $designer, we can't make this decision without them in the room!"
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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)
One of the key functions of a designer is to imagine multiple solutions. But you *need* to have an understanding of the problem & most important benefit before designing ways to deliver that benefit, never mind comparing the effectiveness of those ways against one another.
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.
When you have a goal, you can pick metrics and tools that focus your thinking, and if they're not getting you closer to the goal, you can switch them out.
But when you don't have a goal, all metrics and tools constrain your thinking - and you can't see the lack of progress.
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)
I suspect that it's because design as a practice has a very limited conception of *what it wants*
"Improve the life of the user" is far too abstract. Rather than think about how to scaffold that work, designers skip to drawing pictures of someone else's ideas.
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.🧵
Loop one - the critique feedback loop - works the same way. The designer's internal process has stopped improving the artifact, so it's time to show it to the rest of the team, which requires slightly higher fidelity (think sketches -> wireframes). 🧵
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.
Privileging their aesthetic preference is very convenient for designers: not only does it mean that they don't need to have any range or think about what their work needs to *accomplish*, but it positions them as having some inherent authority as arbiters of taste.
Critique of the implementation does not invalidate the solution. Critique of the solution does not invalidate the shared vision of a problem that needs solving.