A Designer’s Guide to Working with Policy Analysts
4 Tips for Successful Collaboration
Policy has a significant role in the design of a service. It frames, guides, and dictates the interactions a user has with a service.
In a public sector context, designers overlook this ‘material’ because product teams don’t create policy. Drafting policy is outside the scope of a typical design role. However, not engaging with policy can lead to a poor user experience and outcomes. It becomes a necessity then for designers to work closely with the people who make the policy.
Ideally, you can work with a policy team when a new policy is being drafted and there is the greatest flexibility for change. But most delivery teams and designers will be working in a space of established policy. This makes change more difficult as policy hardens over time and becomes entrenched in the system.
Fighting this inertia will take effort. But this change can be the most important work you’ll do as a designer in the public service.
By following these 4 tips you’ll be better equipped to collaborate with a policy team.
1. Establish a relationship around shared problems and outcomes
Start your engagement with a policy team as early as possible and work on establishing a set of shared problems and outcomes. It may be a particular part of a service or an entire transformation.
The longer this dis-engagement occurs, the more difficult it will be to collaborate later in the process and the greater likelihood a turf war will pop up. These battles exist because each team views the other through a lens of encroachment rather than an opportunity for collaboration. They may think collaboration is unnecessary since they work in ‘policy’ and you work in ‘delivery’.
Rightfully so, policy teams don’t want designers showing up telling them they need to change policy, and delivery teams don’t want policy folks telling them what to build.
When you have shared problems and outcomes, your work is no longer about ‘the policy’ or ‘the design’, it’s about that common purpose. Shared problems and outcomes enable both teams to explore the relationship between policy and design. This also becomes a north star for teams to revisit later when disagreements arise.
2. Understand the broader policy landscape
Designers usually aren’t experts in the policy area they’re working in. When a designer comes to the table with their blue-sky vision of an ideal user experience, they usually don’t take into account the history and context of a particular domain or have an appreciation for the larger policy landscape.
Taking a broad systemic view of policy can give you insight into the types of decisions and analyses that policy teams need to make.
Policy is drafted within a broader policy landscape. This landscape includes the people or businesses seeking to access a service but can factor in a variety of forces like inter-governmental laws and regulations, compliance measures, stakeholder relations, environmental regulations, or international trade agreements (just to name a few).
You’ll find that policy analysts have many priorities they need to balance. Analysts try to work in a way that captures all possible use cases so nothing falls through the cracks.
Don’t be surprised when you bring your research findings to a policy analyst and they don’t jump at making changes. Design research may shed light on a problem within your scope, but addressing that problem may create problems for other actors. Policy analysts need to think about balancing conflicting priorities in ways that designers don’t deal with.
Taking a systems view to your problem can feel challenging as a designer (especially working at a product level), but it will help you understand the complex environment policy analysts are immersed in and better appreciate their perspectives.
By zooming out and understanding this larger landscape, you may even find new opportunities that your design can leverage. And by bringing this understanding to the table, you’ll show the policy team that you understand the constraints and considerations they face.
3. Question the intent, not the policy
A sure-fire way to create conflict with a policy team is to call out ‘bad policy’. You may discover a policy that seems ineffective, inefficient, or outdated. If you immediately try to change this policy, analysts will get resistant and defensive.
Every policy statement has a particular reason for its existence. If you discover something weird in policy, start with questioning and understanding the intent.
Ask questions like:
- Why does this policy exist?
- How does it align with the problems and outcomes described earlier?
- What are you hoping to achieve?
- Is it attempting to mitigate a known problem?
- Is it a perceived problem?
- Does this problem still exist?
If a policy team can’t answer these questions, this is a great chance to introduce the role user research can have in a policy making process.
By understanding the intention behind a policy you can work with an analyst from a common starting place. Linking intent with your shared outcomes means you are no longer focused on the policy analyst’s work.
4. Align your work to strategic initiatives
This tip is all about understanding what policy analysts value, and how you can use strategic priorities and initiatives of the government (or department) to your advantage.
I’ll use ‘Red Tape Reduction’ as an illustrative example.
Red tape is anything that citizens and businesses are required to do when interacting with the government and usually doesn’t provide value. Red tape increases time, costs, and frustration when interacting with the government.
You need to provide proof of payment even though we have that payment record? Red tape.
Collect a bunch of information that no one uses? Red tape.
Wait 90 days to receive a benefit? Red tape.
Governments love cutting ‘red tape’. You’ll find red tape reduction initiatives in nearly every province, territory, and federal government.
For some governments, this cutting is a central priority and all departments are mandated to demonstrate how red tape is being reduced by an actual number count. Therefore, policy analysts and their executives really care about it.
This can become a strategic lever in your work.
For example, you may have conducted research with users and found a frustrating step in the process. You’ve figured out a way to omit that step, but it requires a change in policy.
Convincing a policy team to change this policy because it will improve the user’s experience is not always a convincing argument. Framing the change around reducing their red tape reduction count will land much better.
Different governments and departments will have various strategic initiatives. Find these and use them to your advantage.
Conclusion
For designers to be successful in the public service, they need to understand how their work fits within a larger context outside of the delivery team. Until policy becomes an embedded member in digital government delivery, the designer will continue to be a key bridge between these worlds. Knowing how to effectively work with these teams will increase the success of your service design.