Thread by @wickedgeekie

I was asked how I prioritise my work as a #UXdesigner on a product team.
There are 2 levels of prioritisation
1. What needs to be delivered to enable the rest of the team: an insight for decision-making, specs for dev?
2. What needs to be done to get to that delivery
[Thread]

*What* needs to be delivered can only come from discussing with the team and sometimes also with stakeholders, never in isolation.

*Knowing the details of the "what" is half of the "how" done*.

This discussion may take a short chat or a week long workshop, depending on clarity.

*How* I will deliver the *what* is where my technical expertise lies. I learned over the years many tools and techniques, and I'm still learning. As a senior, I have a big toolbox, and a network to ask when I'm unsure. I can plan the tasks, list dependencies and give timelines.

Those timelines feed the prioritisation, which I see as a line-up of dominos: if well done, tasks will flow into the next, completed and without circling back. Of course, reality has a way with such neat plans, which is why prioritisation is never a one-off but a repeated job.

This brings us to resilience and agile. Because initial prioritisation will rapidly fall apart once in contact with reality, the ability to redo it over and over is critical. Until the last domino has fallen, be prepared to re-prioritise. And agile is a framework that knows that.

So there you go. I prioritise my work so it serves the team, and more importantly, I re-prioritise as needed to always stay close to reality. My resilience is borne of my confidence that my work is more valuable when it's relevant, so I welcome opportunities to (re-)prioritise.
/