Good afternoon and welcome back everyone. I'm Neil Young with the Human Center Design Center of Excellence.
I hope you had an excellent lunch break in feel energized and excited about this afternoon sessions with us. I'm thrilled to introduce this afternoon plenaries the 2 afternoon plenary speakers Sarah They're presentation how collaboration between policy experts and service designers reshapes product development is sure to resonate with so many of us today.
Meet Sarah fromasio and multidisciplinary designer and researcher. With a focus on public services.
Science and Climate Projects. She's a senior service designer at Excel, currently part of an enterprise design team with CMCS.
Joining Sarah is Rebecca Bruno, a healthcare policy and operations expert specializing in Medicaid.
And underserved populations. She is principal. She's a principal policy strategist at A one M solutions bending policy expertise with human-centered design principles.
Together they will provide valuable insights into the transformative power of collaboration between policy experts and service designers and product development.
Please join me in welcoming Sarah and Rebecca.
Hi everyone. Kinda share my screen.
There we go. So good afternoon everyone. So nice to be here. So excited.
To talk about this topic with my colleague Rebecca. First we'll kind of introduce ourselves.
So my name is Seda. I'm kind of, I'm the service designer and the duo.
I currently work at Excel as a. I currently work at Excel as a senior service designer.
I started my work, kind of in design consulting, I currently work at Excel as a senior service designer.
I started my work, kind of in design consulting, And also I'm very passionate about climate projects.
I also wanted to kind of touch on what is service design and what does a service designer do.
So service design is the discipline of designing services end-to-end and specifically using human-centered design approaches.
And keeping both end users and organizational needs in mind. And I always like to save in those services design kind of has the word design in it, very little of, service design work as you really spend designing things.
Most of what service designer do really is creating the conditions for service design to happen. So that's building relationships, defining approaches.
Understanding and mapping constraints, getting buy-in, and you'll hear sort of all about this in our in our talk today.
I'll let. Rebecca introduced herself.
Hi, I'm Rebecca Bruno with A and M Solutions. Welcome to our talk.
And welcome to our talk. So most of my career before moving to the private sector was to our talk.
And I'm really passionate about promoting integrated product teams and HDD and government. So welcome and nice to meet you all.
So today we'll kinda make the case for why it's so powerful for subject matter experts and service designers to collaborate.
So we'll talk through a project where we work together, earlier this year, on helping a group of stakeholders from policy and product.
To align on the future vision of a product. And so what you'll kind of get out today is some really practical examples of design exercises and messaging tools.
That you could use to help build trust with business and product partners. Some strategies for service design to engage with policy staff.
And I would say design in general. And then some tips for, successful collaboration between service designers and Sneeze.
And I would say, just as a disclaimer that the images and the artifacts that we're going to show have been scrubbed up specific content in order to keep the project.
Anonymized, but you'll still get the gist of what the content was and we'll explain it.
So we structured our talk around 3 design challenges we face throughout the project and sort of how we approach them with examples.
So we'll start by sharing context about the overall project. Sort of the history, the effort, our rules.
And then we'll go challenge by challenge. Introducing some context at first that's specific to that challenge.
Then we'll talk about, what the problem statement was. And finally, we'll share, examples of our approach.
We'll wrap up by sharing some reflections and lessons learned. And tips that we want to pass on to you.
And at the end, you'll have a chance to ask questions. Live, but also feel free to share questions and comments in the chat throughout.
We'll then make sure the moderator will make sure to capture those. For the end.
So I'll pass it off to Rebecca.
Great. Thanks, Sanna. So I'm gonna start with giving you some context around the project.
Before we jump into some of our, specific use cases.
Starting at a high level, the ask of our team was to help. The agency leadership we're working with to define a future vision for an enterprise, system of products that are currently very fragmented and in many cases still rely heavily on manual processes.
We were charged with taking a service design approach to what a future integrated system would be that was user centric and would help staff do their daily work more efficiently and effectively.
This started with analyzing. Years of previous research and conducting some of our own to inform the vision.
Then after developing the vision, we needed to get stakeholder approval from policy and operation staff. And then ultimately translate that vision into a specific features for a product roadmap.
And I think we're in gas. Next slide. So this visual gives you an idea of the current fragmentation and the complexity of the challenge before us to create a streamlined.
But future vision. As you can imagine, the current experience is very burdensome for government staff involved in various day-to-day processes.
Cause they have to navigate so many different tools and systems and some of which have been around for decades and lack automation.
So this visual may seem a little bit crazy, but that's actually not that far off from what they actually are experiencing.
So this visual may seem a little bit crazy, but that's actually not that far off from what they actually are experiencing in real life not to mention there are a number of processes that are still paper based and rely heavily on email.
So the future system had to be able to support both web-based and paper-based processes. It's important to note that the policy stakeholders are extremely busy, so we had to be mindful and asking for research time.
And in order to minimize that, we reviewed previous research done over the years. Mostly by other product teams to make sure we only focus on knowledge gaps and bring new and useful insights to light.
So. Next slide. Our next image.
Sorry. Thanks. So this shows you the concept we developed for the future. So you can see we kind of the idea is to unwind all that kind of chaos, right, and have a little bit more of a streamlined process.
So we developed this for the future state as a place to start the conversation with policy stakeholders and the product team who had to execute the vision.
So how do we go about the tactical work of getting the right people at the table to align on this vision and also the validate the vision we're putting forward.
Our government, partners convened a cross functional group that would be charged with aligning on the future of vision.
Defining specific features and then informing the development of a product roadmap. So the group was made up of product managers and business and policy staff representing some of the user groups.
They were designated decision makers and the members of the product team that were responsible for development. They observe the meetings to keep informed.
And then finally, and I kind of saw at the top as advisors and we were responsible for sharing artifacts, which we're gonna show you, and conducting facilitation.
So why were the 2 of us from very diverse backgrounds needed to meet the needs of this project?
So for my part as this me, I helped integrate policy requirements. I was able to provide real content for our designs.
Help my team understand government processes and provide insight into the users and stakeholders as someone who had been in their shoes in the past.
And in addition, my experience in the space allowed me to develop communication engagement strategies when dealing with policy stakeholders.
So I'll let Sada talk about her valuable contribution.
Yeah, on my end. Service design was really helpful. In translating complex policy concepts and processes into clear user needs and product features.
So really bringing the product and policy pieces together and doing so in a language that was easy at to understand by the business and by policy folks.
Also pushing a user centered approach to product development so ensuring that the work was being framed. With the users goals in mind, in this case, the users being CMS staff.
And then also this is kind of the designing part. There was a story to tell.
So helping visualize and tell that compelling story and actually creating materials to support it. And finally facilitating alignment with this really large group of stakeholders that had a lot of overlapping needs and priorities but also a lot of competing needs and priorities.
Yeah, so the collaborative approach really helped us build trust with our policy stakeholders and allow the, product leadership to successfully begin work on a roadmap.
So now we're gonna walk through 3 challenges that we were presented with. And how we tackled them as a team.
And our first challenge leads to the introductory context that I just provided. The challenge was how can we create a project vision for a complex decades old ecosystem of tools that resonates with policy staff.
A little context of the landscape we were facing. So to start with. Policy state part of the policy cycle that we're engaging with have been dealing with the future development of this.
Products for many years. So there was some sense of fatigue about being engaged again to provide more feedback.
In addition, these folks, as we mentioned, are extremely busy. And overburdened.
So asking for their time has to be done very delicately. And that's not to say they didn't want to engage because they definitely did.
We just had to be very respectful with how we use their time. In policy stakeholders, are concerned with precision and often live in the weeds.
So keeping them at a vision level takes a lot of work and repetition. And we had a balance a lot of users with different priorities because we had different policy groups that handled different subject areas and had different processes.
So we needed a group of decision makers that could move us forward. And that's not to say that they can represent or speak for all users.
We definitely we're gonna have to do more user testing to represent all of voices and needs. We were just using this group to make some key decisions to keep us on track.
Our mission was to articulate a product vision. From research findings and create a compelling story that resonated with policy stakeholders.
And get approval to move forward. And the research findings were based on generative research. We did at the beginning of the project to understand pain points with current systems and processes.
Because most everything in government is grounded in policy, that is where we started. So I began by mapping the various phases of different policy processes our stakeholders take part in.
And as you can see from this messy mural board, why it's so important for me to work with designers.
This was really actually just used mostly for internal purposes and we use this to help. Populate content later.
And some of our designs. Along the side, I have the policy processes. And across the top are the stages in the process.
So for example, a submission or approval or disapproval workflows or data outputs. And the various color stickies represented required documentation, processes, pain points.
Data needs and then opportunities for automation. This exercise allowed us to build a solid policy knowledge base and created a share understanding between the 2 of us.
Hey, based on the review of agency stakeholders with me, Is that I actually develop this collaborate your stack?
And the purpose was to be very transparent about whose voice would contribute to the vision that we were developing. And we identified who from each of the groups and divisions would be involved in the user research and at the different levels and phases of involvement in which they would be engaged.
And we felt it was important to place ourselves on the map so that they understood our role. I'm gonna let Sawdust and she created it talk about the value of the map.
Yeah, so sharing this. Visual early, allowed us to kind of build trust and transparency.
About the process and the voices that we're gonna go into making the vision with stakeholders that we didn't really have a relationship with just yet.
So it's a really good quote design practice or participatory design practice, to share something like this early on and to also to ask for feedback on it, from stakeholders.
So what we can get created next is something that I really, really wanted to present to the stakeholders as a way to show.
We understood their challenges and daily work burden and Sada was able to take the experience that I described based on what some of my workload looked like when I was an agency employee and turn it into this storytelling visual that we call a day in the life.
And at the top, we provided context of what this visual is meant to depict. And we showed the various tasks that could be on a person's plate on any given day.
And, just how many tools and systems and really authentication so you can see with the little, blocks that means they had to log in each time.
They had to go through and it just shows how fragmented and inefficient is for someone to get through their work day really.
The next visual and the day in life shows what the experience will hopefully look like in the future once the system vision is implemented.
And this shows how the mental model of the work. Would change and be centralized and simplified. And on the right, we show their tasks how their tests will map to the new systems and data flows.
And this helped us empathize with the users and allow us to communicate to policy and operations staff with the current versus future experience would not just look like that how it would feel for them.
And finally, we created a process story. Visualizing all the potential future features and parts of the experience.
So policy stakeholders could see how their day-to-day work would potentially change. We create a subway map that appears at the top of each page to orient people to which up in the story they are on and then we use simple illustrations or wire frames to show the story moment And we included story points to illustrate a step by step.
Scenario. For the work and then we showed which proposed feature would be applicable to that particular phase.
Laying out the entire possible future workflow and features and a visual allowed us to gather early feedback and concerns from policy stakeholders.
And product partners. We really wanted to make sure we addressed any non-starters early on. And again, though we are showing you wireframes of what we did, the actual artifact had real content based on policy and official operating procedures, which is important when communicating with policy staff.
So I'm gonna hand it back over to Sata to talk through 2 more challenges.
Thanks, Rebecca. So moving on with kind of the story of the project. Now that we had this vision articulated into all these visuals.
The second challenge we faced is how do we get product managers and product leadership to absorb this future vision materials?
And make sure also they are able to build. What users expressed they need, which was articulated in this vision.
And so some context on this phase, is that even though we were the ones who kind of spearheaded creating the materials.
For the vision that you saw. We are not the product team who is building it. So our focus now was really to work with.
Product managers to figure out how can we translate. This process story, these features, into features and epics that make sense to you.
And also while doing that, we needed to continue doing validation of the features with policy stakeholders to ensure they represented their needs.
To make sure that we weren't missing any pain points or functionality, or that any of the functionality wasn't redundant or not needed.
And the language part here. Was really key. So continuing to ensure that as things got turned into more technical.
And sort of, practical materials and product features and epics. They were still understandable by the policy staff.
And they still felt like they could, provide feedback. So a big part of, big part of this phase was focused on coaching.
Product managers and kind of facilitating sessions. With both policy and product.
So our mission was to coach. The product team to absorb our team's artifacts and turn it into a roadmap.
That or start to turn into a roadmap that was kind of digestible and understandable by policy staff.
So Rebecca and I collaborated on this artifact. We created what we called future features spreadsheet.
Which was essentially all the features that we outline in that story turned into a format that product could use.
So I kind of set the structure up and Rebecca really helped firm up the language and the specificity.
To ensure that the content was accurate. And the way that the product managers use it was they kind of created a draft roadmap in their own materials after we shared this document with them.
They shared the roadmap with us and we started to kind of use the spreadsheet to track how that translation work was going.
So as you can see at the top we have features and sub features and then we captured whether the feature existed in the old system of products or whether it was going to be completely new to stakeholders.
We also captured any relevant research notes from our own research. Things that we thought would, we should call out because they would inform additional discovery or testing by the product team.
Later on. And then we tracked whether features on this list were on that roadmap file that I mentioned that the product manager was keeping so that we could keep track of that translation.
And finally where was this feature in that roadmap? And so figuring out the right format to translate the story.
For the product team, not just handing off the materials that we created. Really allowed us to ensure that, product vision was implementable and actionable and that collaboration between our team and product.
Was really kicking off on the right foot.
This next artifact is very simple. Is something I created. It's really a facilitation aid.
And this is again kind of that. Role of that service designer to keep an ear out for like.
Context and sort of navigating stakeholders and helping make sure the conditions for the work are right.
So I was noticing that policy stuff was starting to get really confused in these meetings around all the different product work that was happening and where this vision works sit in all of that.
They were asking, well, wait a minute, you're missing all this functionality. Is it coming later?
Did you talk to so and so? I just had a meeting where I was asked about this feature and a different context.
Which was all very kind of reasonable. So we created this to help product managers explain how all the work fit together.
And contextualize that vision work that we were doing and the larger picture. So as you can see, we kind of outlined.
The activities that we had completed already together and marked them as done. And then showing what we were currently doing and what was coming up.
To ease that anxiety about things that might have been missing. And also showing parallel streams of work that the policy stakeholders we're gonna be asked to participate in and contextualizing all of them.
So creating this transparency again about our overall process and rationale and providing context about product efforts really continue to help build trust with stakeholders.
And clear up confusion so that they could be present for the activities that we were asking them to participate in.
This one, is really exciting personally. Something that, we created. Because it would help kind of more future work.
But also in the context of this work. So we noticed a lot of policy staff were asking.
Well, I see all this future process vision, but has anyone captured the current process in a similar way in that kind of storytelling?
Visual format. Also the developers on the product team brought up that it would be helpful not only for them to have that future process outlined, but also how are things done currently.
And so the main way to reference the current process at that time was SOPs, which are very detailed and technical.
And they kind of needed something a little bit more visual. So we created this template that we called program operations mapping template.
And as you can see, it has kind of the overall phases at the top that has the same visual language as the process story that you saw.
This is to try and unify. The service experience by standardizing language across the organization. And then we organized this map through different swim lanes, for representing different, groups of policy staff.
And the map itself, is kind of really showing the each step of a happy path. An exception paths, of actions required to complete a policy process.
And so this hopefully will help standardize language and service experience across the organization and will also give the product team a tool to be able to compare future versus current experience and to be able to build that future experience.
This is just some showing a close up of, the template. With some tips that we added in there.
This was done in pig jam, but we also created a mural version. And a PowerPoint version.
To ensure that the most amount of people could use it and access it.
So moving on to the last challenge. After all this work was done. Product kind of started to absorb the work.
This was really a moment of we need to get sign off. So how do we get a group of policy staff to understand?
Provide feedback and then ideally sign off on a future system. With features so that product could continue to move on and building that roadmap.
And this is really to me about building trust and kind of engaging. In deep collaboration with policy. So some context about where we were at this point.
So. First of all, kind of historically product roadmaps are not very business friendly.
They're sort of technical, they're not very descriptive. We really needed to make sure that this roadmap was gonna be user friendly so that the approval and prioritization by policy stakeholders could happen.
Another bit of context that added to the complexity is that The business and policy group we were working with represented a really wide range of needs and priorities.
They were from different parts of of the government and it was going to be really hard to align them all.
And a lot of the features that we proposed, although where they were future-facing, they were necessary features.
They were not nice to have the work kind of critical part of the everyday workflow. So how do you prioritize when everything's important was something that we needed to navigate?
And on top of all of this, HCD and agile is some, some of you all know, I'm sure on this call, they're not processes that are very familiar to everybody and to policy stakeholders.
So we need to, we need to make sure that we were taking them along the way and kind of explaining.
Why we were choosing this approach and. The rationale behind these activities.
So our mission, was now that we. Have this, product team, help them absorb and translate the feature vision into product features and epics.
How do we get policy stakeholders to validate and provide input on priority level levels for these future features?
So the first visual we collaborated on this phase was called feature cards. This is one of my favorite things.
We created because they It's the gift that keeps on giving. For other projects that we're doing.
This is really, so each feature cards was representing each of the features that we mentioned in the process story.
So this is really to start to turn the spotlight. Into specific functionality to ensure that it was clear to stakeholders that we actually captured and address pain points and that we heard and noted their concerns.
And the way we kind of visually laid these feature cards out, we show again which phase of the policy process would this feature come in?
We then had simple illustrations for each feature kind of giving us sense for functionality. And then again, featured names were in plain language.
And described detailed functionality in the bullet points that you don't see here but the the most important thing is that they stayed away from the weeds of requirements.
And that's one of kind of the biggest challenge of this. Whole process, is that there was a tendency to kind of go into requirements.
And as a service designer, I think that's a scale that we have to use in these moments to really be able to pull people out of the weeds.
And remind them of the overall goal of this phase, which wasn't feature requirement and testing. It was validation, kind of initial validation.
And so the way we use these cards is we presented them to the. Cross-functional group of policy folks, gave them a chance to ask clarifying questions, provide feedback.
Add details. And so kind of figuring out again the right format for sharing product functionality into an easy to understand format.
Enabled us to gather early feedback with policy staff.
And so after validating each of those cards individually, we brought the features back to the group for larger privatization exercise.
We refine the features based on that initial feedback and wanted to bring them back. Because product managers at that point really needed priority data.
So we created a. Exercise. Where we numbered all of the features. And we provided kind of a high level overview of all the features again and we shared a definition for highest impact.
We gave each person stickers for votes. And then we numbered each feature. So it would be easy to reference in future conversations and in the roadback.
And we also created a PDF version that we send stakeholders ahead of time so they could look at it on their screen while they were voting.
Most folks don't know fig jam or didn't know fig jam or we're familiar with it.
So we wanted to give them multiple ways of engaging with the content. And so after this facilitated. How the before and after.
As you can see, there's kind of clear. Top loaded features emerged which denoted high priority items for the roadmap.
The stakeholders were really engaged in the conversation. I was capturing notes, and questions and pain points that policy stakeholders brought up.
To ensure that they felt heard. And these annotations were going to be taken by product managers to add to the backlog and the roadmap for feature, feature refinement testing.
And so the outcome of this exercise is that engaging policy stakeholders in early decision making is a really important co design practice.
That again continues to build that trust. And respect and also most importantly reduces risk in the long run because you're gathering Feedback long before you're developing the feature and testing.
So those are the 3 challenges. I'll hand it off to Rebecca. To kind of close us out with some lessons and final thoughts.
Yeah, great. Thanks a lot. So we showed you a lot about how we work together. So what have we learned to take away from this experience?
So for me, as this me, what did I get out of partnering with service designers?
So I can't tell you how much value I got out of working with Sata and other teammates who I have to shout out because we definitely had other people and other teammates who I have to shout out because we definitely had other people and they're I think some of them are in the audience so I have to shout out because we definitely had other people and they're I think some of them are in the audience so, definitely
a but I got a lot both, personally professionally out of this. And here's just a couple of examples of how great it was to work with the experienced service designer.
So first, and I had a lot of thoughts on my and ideas in my head, but I struggle with how to translate that and to tell the story and ideas in my head, but I struggle with how to translate that and to tell the story.
And not to mention a lot of the content we're dealing with can be very wonky and dry for us non policy nerds.
And Sada had a great way of translating what was in my head as well as the dry policy processes.
And turned them into storytelling materials that would resonate with our stakeholders. And the day in the life of storytelling materials that would resonate with our stakeholders.
And the day in the life, visuals. And the day in the life visual I showed earlier was a great example of her being able to abstract this idea ahead of my head and create a storytelling visual.
Secondly, Sonnet is a master facilitator. She was able to use her design tools and the artifacts we created together and run expert facilitation sessions with highly passionate and often opinionated policy groups in very time limited sessions.
So I really learned a lot from watching her about how to do facilitation. And Santa was able to wade through the policy leads and, bring and get us to the right, bring the message to the right level.
And she really had no problem embracing and translating the complexity of policy and rigid. Requirements and it was really nice for me as a me to work with the service center who really could pick that up quickly.
I haven't seen that a lot. It's really impressive. And then finally, I think one of the biggest values was that we respected each other.
And what we each brought to the table and we really knew that we needed each other to be successful. And we really knew that we needed each other to be successful. And we really knew that we needed each other to be successful.
And just one other small thing, working with her. And just one other small thing, working with her.
I was forced to get comfortable with Digla and. And just one other small thing. We knew that we needed each other to be successful. And just one other small thing, working with her.
Okay.
I was forced to get comfortable with And so based on what I learned. This process I have for any, for some tips for any SMEs in this virtual room.
One is be be precise, but don't start in the weeds. It's important to have precision and accurate language, but try to stay a bit of a higher level to depict the vision at the beginning.
The weeds are important when working on government projects because as I mentioned most government processes are based on policy but they will come later when you get to the requirements phase.
So. My advice is just be patient and try to embrace this process. Also, policy folks will hone in on content and words right away.
So make sure to review designs to make sure there isn't anything in there that will raise potential policy or political red flags.
And make sure there's nothing blatantly inaccurate because they definitely will spot it. Third, I would encourage designers.
And researchers, HD practitioners, to have a general understanding of the government agency or program you're working on.
I can't tell you how many times I hear people refer to Medicare when they're talking about Medicaid.
So this is a sure way to lose trust with your stakeholders. It's so it's the responsibility of everyone on the team to do a little homework.
But SMEs can really help this. I can help the team by doing some presentations, learning sessions and pointing to resources.
Next, this one can be a little bit delicate, but it's important to help designers and researchers understand why some things just aren't going to work in a particular situation or based on the current environment.
And this can be frustrating for designers and researchers who are dedicated to a proven HCD process, but sometimes flexibility is needed.
Depending on the political or just whatever kind of priority is happening at the agency. At the time. And finally, I really encouraged needs to be champions for service design.
It's a huge cultural change for policy people in particular. Cause it can initially seem contrary to how they work.
So it's important for us that come from that space to continue to show the value and encourage people in government to embrace the process.
And this will require persistence and ongoing coaching. So Saddam, would you like to talk about what you learned?
I took away.
Yes. So similarly, this, process and this, collaboration was incredibly valuable for me as a service designer.
I actually never worked with this me this closely. So, just grew so much as the designer overall.
But some of the things I got out of it, I would say the, there's a huge amount of value when it comes to trust building with policy folks because of Rebecca's knowledge and experience and relationship that she has built over the years, it was just so much easier to build trust with policy staff and policy leadership at the beginning of this project.
We didn't really know. Each other. The policy folks and us and we had to quickly go into like decision making and sign-offs so it that was really key to be able to continue to move forward at a much faster speed.
And speaking of speed. When you're working with us, me, I've just noticed how much faster things are.
There's, for example, a need to do way less desk research and pre research because a lot of that knowledge is just living in your collaborator.
And also in interviews, there's more time to ask. More important than deeper questions rather than foundational questions.
And also we could create things so much faster because I had the visualization skills and she had the content.
So we have created some of these artifacts. In one sprint, multiple, multiple artifacts per sprint, which is, I think, pretty fast for this work.
And then. The politics Intel. So as I said, the huge part of this work is creating the conditions.
For design to happen for HDD and service design to happen. This work is very political and it was essential for me to have that Intel around what will raise red flags.
What will, will will resonate. What's the history of something like this? What are the cultural conditions?
So I could really have. Adjust my approach as needed. And language was a huge part of this, you know, knowing what language to stay away from.
Collaborating made us very a very nibble team. For example, in validation sessions or workshop we could answer very technical policy questions on the spot.
Or we could push back on the fly instead of having to go back. Do research and come back and do another session.
So super valuable in that sense. I kind of keep talking about this, but we have a very complementary, expertise, you know, service design kind of creates containers and structures.
And SMEs has all the skills to or almost all this goes to kind of help with the content and most importantly strategically socialize the work.
And it's super fun. I feel like I've grown so much as a designer. I learned so much from Rebecca.
Not only in kind of when to zoom in, when to zoom out, really questioning the rationale between my approach and decisions instead of just following an approach I might have followed many times.
And also just getting a chance to experiment a lot based on her ideas. A lot of the artifacts were things that I had never created before as a service designer and kind of came from her ideas.
So. Yeah, huge opportunity for growth. So some tips for, service designer or HCD folks in the audience.
For how to collaborate with policy SMEEs. So as the service designer, you'll be driving what approach the project takes, for the most part.
So what activities and formats are used? And I would say make sure you communicate the rationale behind why you're doing it and not do it just because you're following a process so that there can be true collaboration between you and your SME partner.
And then the weeds will be a challenge. You'll be the one that will have to pull everyone back.
Most of the time and remember the zoom out. So make sure. Kind of you and your stakeholder group don't get lost and lose sight.
But sometimes it's also important to get into those weeds because policy work is nuanced and sometimes that new ones cannot be missed.
So developing kind of a trained ear and eye for when to get into. Details and when not to, is really key.
And Sneeze are an incredible resource. Of knowledge. So it's tempting to kind of go ask.
Here's me. For answers to everything, but you need to make sure you're not over burdening it.
Over burdening them and respecting their time. So Rebecca, for example, would share a lot of folders with me.
I'm just with me of information or documents she put together. Summaries and I would always make sure to look at those.
Before asking her questions most of the time. Definitely. Sometimes she's called me out. It happens.
The best of us. And then, design jargon. It will not serve you.
I don't think there's a situation where it serves you. Personally, may be a super specific design conference, but some people are kind of triggered by certain design words and processes because of people that came before you.
So just state things in plain language. State what activity you're trying to do. For example, there was a moment in the project where we wanted to, I was using the word storyboard.
And I realize it didn't make any sense to most people. So instead we decided to call it process story.
Cause it was a story of the process. And this one is a really great tip that I learned particularly in this collaboration.
Really lane on visual note taking. I'm not talking about doodling live as you're talking to somebody.
I'm talking about kind of sharing your screen. In meetings in like mural or fig jam.
And take notes as your policy SNEE is talking or as the policy stakeholders are working with with our talking.
It really helped me build trust and also shows that you're kind of listening, you're hearing out where your partner's saying, and it helps ensure that you are building a shared understanding.
They're on the same page. And it kind of also helps you show the HTTP process, as you go.
So those are those were our tips and our lessons. Thank you. So much, for tuning in and listening to this talk.