Thread by @PavelASamsonov

One of the dangers of focusing on the craft aspect of design is that you are distracted from challenging the premise.

This is something I'm trying to change in my own practice - using UI design artifacts to inhabit the problem rather than attempt to solve it.

It's a diametrically different approach than design sprints and similar ideas, because the outcome catalyzed by this work is actually regression from the "doing" back to research. Perhaps it's closer to externalizing my mind's eye for my colleagues' benefit.

It's closest to @jmspool's idea of despicable design, except more naive than bad. When faced with an incumbent system that's hard to compare to the new one, it can help to model the old one as similar to the new one. What are the flaws in a 1:1 adaptation? articles.uie.com/despicable-des…

@jmspool The most important thing here is to stop being afraid of tossing work in the trash. When you don't have hopes that this approach will be the one to go forward, you can pick the (as @round puts it) "wacky" design direction fearlessly.

https://mobile.twitter.com/round/status/892486242721554433

@jmspool @round This is also a good opportunity to practice intentional decision-making. If you ask yourself - how do we know? - then you maintain provenance of your choices and can defend your work against stakeholder criticism.

And if you don't know - go find out.

@jmspool @round In this way, a hi-fi prototype or mockup becomes a low fidelity prototype of a *workflow*. You can enrich your scenarios based on steps that users would be forced to do under your system - and then have the hard conversations about what it might take to get rid of these steps.

@jmspool @round Inhabiting the problem in this way also helps you (re)formulate a content model. The UI and content exist in a symbiosis, and developing one forces you to refractor and enhance the other.

@jmspool @round Approaching the problem in this way can give you a wide variety of north star vision candidates, since they are also not really solutions themselves, but rather exist to bridge the gap between problem and potential solutions.

https://mobile.twitter.com/PavelASamsonov/status/1125874039841599490

@jmspool @round The difference between the north star and this approach is that touching base constantly with stakeholders and developers is crucial, since they can contribute their understanding of the current system. The design catalyzes their thinking in a way few other things can.

@jmspool @round This strategy combines very well with a PM that knows how to support decision-making. By coordinating with this PM, the designer can launch tactical explorations into areas of priority and discover the ambiguity that currently exists there.

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

@jmspool @round If you do not have such a product manager, then you must do it alone. If your product manager insists that you "stay a sprint ahead of the dev team", explain that the development process operates inside the design loop, not vice-versa.