Share this page!

Enter URL or ID to Unroll

You can paste full URL like: https://x.com/threadreaderapp/status/1644127596119195649
or just the ID like: 1644127596119195649

How to get URL link on X (Twitter) App

  1. On the Twitter thread, click on or icon on the bottom
  2. Click again on or Share Via icon
  3. Click on Copy Link to Tweet
  4. Paste it above and click "Unroll Thread"!
  5. More info at Twitter Help
@spavel.bsky.social🐀 Profile picture
@PavelASamsonov
Sep 28, 2020 • 7 tweets • 3 min read • Read on X
Scrolly
Whichever way you slice it, "clean" handoffs between stages of the software development process create friction and leave each role frustrated due to lack of influence into neighboring spaces.

The solution is working in parallel, not expanding your "slice" until burnout.

1/ Diagram showing 6 rough stages of software development: busi
The standard "designer does the design" runs into friction on each side: the PM hands down a constricting definition of the problem space, and the designer's great ideas for the solution rarely translate into code the way they expected. Iteration is very difficult as well.

2/ The first column of the original table, pivoted sideways. Ca
What if we split the design role into UX/R and UI/Dev? Problem not quite solved: separating "business knowledge" & "user knowledge" is a recipe for conflict. Separate front-end and back-end teams can lead to resentment over dependencies when cool UI ideas simply do not work.

3/ The second column from the original image. Captions: When PM
It may be better to eliminate handoffs entirely. Involving every role as early as possible (in some capacity) may lead to losing focus somewhat, but being involved in "upstream" conversations and seeing the reasoning behind decisions sets everyone up for success.

4/ The third column from the chart. All the roles are stacked s
Some people think that the best strategy to avoid handoff is to just get one person who does all the work.

This is a bad idea.

5/5 The word "unicorn" stretches over all phases of th
I do not claim to be a final authority on the titles; if you prefer to call some section Interaction Designer/Web Developer/Product Champion, go ahead. But trying to finagle a cool and unique title in order to precisely define ownership is working on the wrong abstraction layer.
The other problem with over-reliance on unicorns is that your unicorns are always going to have blind spots that fully staffed, diverse teams will be able to catch.

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with @spavel.bsky.social🐀

@spavel.bsky.social🐀 Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @PavelASamsonov

@spavel.bsky.social🐀 Profile picture
Mar 21, 2023
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.
Read 5 tweets
@spavel.bsky.social🐀 Profile picture
Feb 1, 2023
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.
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.
Read 5 tweets
@spavel.bsky.social🐀 Profile picture
Jan 1, 2023
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.
Read 5 tweets
@spavel.bsky.social🐀 Profile picture
Dec 27, 2022
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.🧵 DESIGN ACTIVITIES AND ARTIFACTS What is the purpose of the a
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). 🧵
Read 13 tweets
@spavel.bsky.social🐀 Profile picture
Dec 22, 2022
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.
Read 14 tweets
@spavel.bsky.social🐀 Profile picture
Dec 22, 2022
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.
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?
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.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

Send Email!

:(