Tweet

Pavel A. Samsonov

22 Jul, 7 tweets, 2 min read

Adaptive expert: can apply skills to a wide variety of situations
Rote expert: memorized how to do a series of tasks correctly

UX, Product, and related disciplines suffer from the replacement of the former with the latter, but rote expertise isn't suited to design problems.🧵

This is especially clear with something like Scrum, where all problems are solved by applying the same patterns, regardless of whether they are suitable. But it's appealing as a worldview to novice PMs because training in Scrum ceremonies is much easier than learning how to PM.🧵

Rote expertise is what leads these PMs and designers to scorn user research. When all you have is a hammer, there's no reason to evaluate the appropriateness of using a nail. Just draw the Sacred Artifacts (persona, user journey, wireframes) and then go make a Design System.🧵

When trying to improve product/design culture, teaching rote experts tools from your toolbox is not enough - they will do the step you ask for, and then apply 0% of what they learned from that to their everyday work routine. The hard work is integrating into that routine.🧵

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

I've found the hypothesis framework useful for this - if you can explicitly state the assumptions that allow the rote path to flow, and then demolish them through quick user research, it can help to interrupt business-as-usual, at least that one time.🧵

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

But you won't be able to easily sell this, or any other framework, to rote experts. They will see it as a speed bump to Execution, and while you are justifying your research phase and proving your design decisions, PMs are already having the devs building their first idea.🧵

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

This is why the real outputs of design are not the pictures - they are mental models, which must have memetic self-perpetuating properties to "win" against the incumbent mental model that underpins the present state of affairs. The pictures help, though.

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

• • •

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

This Thread may be Removed Anytime!

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

More from @PavelASamsonov

Pavel A. Samsonov

@PavelASamsonov

14 Jun

The fidelity of your design artifacts needs to match the fidelity of your research insights. Getting ahead of your knowledge with beautiful mockups that rest entirely upon assumptions is AT BEST wasted work, and at worst burns design's credibility with stakeholders.
1/🧵

Without research, the value of anything you're drawing is purely speculative. But it doesn't look like it to non-designers - without being immersed in the use case, all they see is "the design is done." They will expect to see that thing built.
2/🧵

When new evidence suggests that this design is not the right solution, it will be a struggle to convince stakeholders that changes need to be made. Even if product hasn't already started cutting tickets and scheduling work - the first design sticks firmly in people's minds.
3/🧵

Read 6 tweets

Pavel A. Samsonov

@PavelASamsonov

13 Jun

Labor market: *realizing that their labor is underpaid*

VCs: Forget about that nonsense and do work for free instead, your boss will definitely appreciate it honest

You know what happens when you work weekends?

Everyone knows that you're the sap who will work weekends. That's it. You don't get ahead by doing more of the same work. You get ahead by making your impacts more visible, and good luck doing that when everyone's living their lives.

Instead of spending more time working, spend more time looking at why you need to work those extra hours, and attack the root cause. You'll cut the chaff and spend 40 hours a week on high-impact work, instead of 56 hours on nonsense other people have saddled you with.

Read 6 tweets

Pavel A. Samsonov

@PavelASamsonov

7 Jun

"Don't worry about edge cases or errors, this is an MVP" is a very dangerous line of thought that I usually hear from people used to designing for stakeholder demos, rather than production releases.

A demo for a stakeholder, especially a "user proxy", is a very different path from normal use. Any scenario has to contrive a path through every single one of the stakeholder's pet features, so usually it's a checklist approach instead. "We added XYZ like you asked, see?"

In reality, the "as a user I want to use X feature" user story doesn't cut the mustard - and without designing for plausible scenarios, the product ends up being entirely unusable.

If you're not designing for recovery from exceptions, you're not designing a viable product.

Read 4 tweets

Pavel A. Samsonov

@PavelASamsonov

26 May

When the PM insists that everything needs to go above the fold

When the ease of completing a task is measured only in the number of clicks required

When the developers insist that the bug is an edge case and doesn't need to be solved before the release

Read 19 tweets

Pavel A. Samsonov

@PavelASamsonov

7 Apr

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."

Read 12 tweets