Manage stakeholders and get Design more agile

Reduce your revisions, time to deployment, and get user value faster

Jon Dobrowolski
3 min readAug 4, 2015
How design & agile development have co-existed previously.

Look at that assembly line for design… right before we get to the sexy Agile machine…

Why are we doing this?

Software is still rooted in the traditional design process. Professional product design of the early internet age was pioneered by agencies applying their classic ‘n revisions to profit’ model. This process unfortunately persists today.

We need to force a new way of working in order to move faster, force maturity, and increase trust within the organization.

Begin differently

Get in the room with your stakeholders and your whole team. Extract business/team goals from the conversation, any learnings / success attributed to current functionality, and move on. Set a goal to show your stakeholders that you’ve heard them with the work you do.

Write User Stories before Design begins

Write your Stories before you design. Discuss, whiteboard, negotiate & write your User Story titles as a team after you’ve met with stakeholders to learn from them. Hold your team to collaboration on stories once roughly detailed for unanimous approval. PDMs & developers should be stubbing out Design/UX just as you do APIs. This will force a tighter communication loop between team members. User needs/goals should be the same no matter the design details.

Accomplish this by tactfully reducing feedback & revisions + write User Stories prior to design

Manage Stakeholders — STOP asking

Presenting stakeholders with options, asking for feedback, etc. — These are not Agile practices because they indicate that you have not been communicating throughout the process.

When its time to push for sign-off, casually send the singular design solution, not the design options. Indicate that you’re moving in the direction outlined and ask for any dependencies (copy, marketing graphics, etc.) that are required for deployment. If you’re asking your stakeholders for feedback, you are putting them in an awkward position.

How? Stakeholders feel that they must provide notes on a solution even if the goals are accomplished, this is simply to illustrate their job function (aka justify themselves). Preempt questions with evidence that you’ve explored every viable option. If there are glaring issues with your solution, you’ll hear about them without asking.

I’ve personally employed these simple tactics for about five years and have seen astonishing results throughout. No regrets.

*These graphics are sized for slides

--

--

Jon Dobrowolski

Multifinality / Concept / Product / Process / Design / Development