Jen, a UX researcher at BECU, walks through a real case study in which she used a multi-method research approach, including heuristic evaluation, customer interviews, and contextual inquiry, to build a service design blueprint for an enterprise security reporting process. The blueprint mapped a deeply manual, multi-system workflow and surfaced both improvement opportunities and the limits of automation. The talk also demonstrates how the service design blueprint framework can be adapted beyond its standard template to fit the specific questions a team needs to answer.
Key Takeaways
- Modify the service design blueprint framework to fit your team's actual questions. The swim lanes do not need to match any standard template. Drop rows that do not add value and add rows that surface what matters.
- Start physical or at low resolution. Paper stickies and a whiteboard make it easy to catch errors early and invite conversation. Move to a digital format, such as a digital whiteboard or spreadsheet, only once the flow is confirmed.
- Contextual inquiry reveals what interviews cannot. Observing a practitioner build a report in real time surfaces steps, errors, and workarounds the person themselves is not aware of and would never report in a post-event interview.
- A service design blueprint is a tool for organizational alignment, not just documentation. Making the process visible, especially at large physical scale, brought developers and managers into the conversation and broke down silos that had persisted for years.
- Full automation is rarely a simple fix. The blueprint showed managers that the reporting process involved too many systems and manual decision points to automate with a switch flip, recalibrating expectations before resources were committed.
- Meet stakeholders where they are with deliverables. Translating the blueprint into a spreadsheet rather than a design tool made the artifact accessible to the entire team and reduced questions directed at the researcher.
Questions & Answers
- Do you always recommend starting with a physical representation first, or can you get the same benefits starting in a spreadsheet?
- Given the choice today, the speaker would use a digital whiteboard rather than paper stickies or a spreadsheet. A digital whiteboard is as flexible as physical stickies for moving things around, allows screenshots to be embedded cleanly alongside the steps, and produces an artifact that can be cleaned up into a polished deliverable. Most teams now have access to some form of digital whiteboard tool.
- Did you have any issues building trust with Bro Sales so that he would share his real process with you?
- Trust built quickly because the researcher adopted an explicit apprentice posture. She told Bro Sales to treat her as someone who knew nothing and to walk her through everything. Asking questions without defensiveness, sitting alongside him for extended periods, and being clear that she was there to learn rather than evaluate his work made the dynamic comfortable. The researcher noted that most people respond well to being positioned as the expert in the room.
- What format were the customer interviews conducted in, and what would you recommend?
- The interviews in this project were conducted by phone. In retrospect, the speaker would recommend video calls such as Zoom, because they allow both parties to pull up the report document on screen at the same time and because seeing a participant's facial reactions provides richer data than voice alone.
- What was your favorite part of the research process?
- Contextual inquiry. Sitting with Bro Sales and watching him work in real time surfaced errors and intermediate steps he was not even aware he was taking. For example, he described his next step as going to one system but then navigated to a different one first. That kind of observation is impossible to capture in a post-event interview.
Session Notes
What Is Enterprise Software
Enterprise software serves the needs of an organization rather than an individual user. Its defining characteristics create specific UX challenges.
- Users are often in the system for long stretches, sometimes all day.
- Functionality is frequently tied to legacy systems, making the experience feel dated.
- The person who purchases the software is rarely the person who uses it daily. Procurement or technology leadership typically makes the buying decision.
- Enterprise software rarely receives focused UX investment because organizations simply need the solution to exist.
Common examples include Jira, Salesforce, Zoho, and WordPress, covering functions such as HR, payroll, CRM, and marketing.
What Is Service Design, and Why Does It Apply Here
Service design is the practice of organizing people, resources, and processes to improve the employee experience and, indirectly, the customer experience. This maps closely onto the logic of enterprise software: in both cases, improving the experience of the person doing the work has downstream effects on the customer they serve.
The Service Design Blueprint
A service design blueprint uses horizontal swim lanes to represent different layers of an experience, such as customer actions, staff actions, and supporting systems, and vertical columns to represent steps in a process. The framework from Adaptive Path was used as a starting point, but the speaker adapted it significantly for this project.
The Case Study: Security Reporting at a Managed Security Company
The Business Problem
The company monitored internet traffic for corporate clients and delivered monthly or quarterly reports summarizing network activity and security threats. The business ask was to automate the creation of those reports. Before designing a solution, the researcher needed to understand what was wrong with the current report and how it was actually built.
Problems with the Existing Reports
- Building a single report took nearly two hours of manual work and did not scale.
- Data came from multiple separate sources.
- Clients were not consulted when the reports were designed.
- Visual presentation was inconsistent across the document.
- Charts used 3D bar graphs with wide number scales, making comparisons difficult.
- A table of IP addresses provided no context or interpretation.
- One chart tracked the count of tickets sent per month, which clients said they did not care about.
- A chart showing ticket resolution time used seconds on the x-axis (with a maximum of 28,619 seconds) and included half-number increments on the y-axis, even though a fractional ticket cannot exist.
The Multi-Method Research Plan
The researcher designed a four-part plan to investigate the problem before making any recommendations.
- Heuristic evaluation of the existing reports to identify design and usability problems.
- One-on-one customer interviews to learn what clients actually needed from the reports.
- Contextual inquiry with the person who built the reports to understand the production process step by step.
- Service design blueprint to synthesize all findings, map the end-to-end process, and surface gaps and opportunities.
Heuristic Evaluation
The evaluation was not tied to a formal heuristic set. The goal was a quick examination of the status quo, looking for inconsistencies and anything that would confuse a non-expert reader. The reports were built by technically skilled security analysts who were not trained in communication design. The evaluation confirmed the charts described above were problematic and set the agenda for later interview questions.
Customer Interviews
Clients who received the reports were interviewed one on one. Their core feedback was consistent.
- Reports needed to provide actionable items they could bring to their leadership.
- Clients wanted interpretation, not just status. They wanted to know what to do about a problem, not only that a problem existed.
- Reports should reflect current industry trends and threats happening in the world.
- Content should be personalized to their company and industry. Generic articles included in the reports were not useful.
- Simply put: the reports did not contain the information clients needed.
"If we are in trouble, I don't want to know that there is a problem. I want to know what to do about it."
Contextual Inquiry
The researcher sat with the primary report builder, referred to throughout as "Bro Sales," and observed him building a report from start to finish while asking questions along the way. Key findings from the observation included the following.
- The process required a large number of separate systems, websites, scripts, and manual calculations.
- Bro Sales was not fully aware of how many systems he was using until the process was mapped out.
- The method surfaced errors in real time, including instances where numbers entered into scripts did not match what he had described as his intended next step.
- Observation revealed workarounds and intermediate steps that would never have been reported in a post-event interview.
After the observation sessions, the researcher sketched a rough map of the steps and associated systems on a small physical whiteboard. Keeping this artifact low-resolution made it easy to revise before investing time in a polished format.
Building the Service Design Blueprint
Physical Format First
Without access to a digital whiteboard, the researcher built the blueprint at large physical scale using flip-chart paper and sticky notes. The final version wrapped around five cubicles in the office. The swim lanes were customized for this project.
- Yellow stickies: the discrete actions or steps in building the report.
- Orange stickies: additional observations noted during contextual inquiry that were not formal steps.
- Pink stickies: the researcher's editorial comments, gap flags, and "how might we" ideas, kept visually separate from observed behaviors.
- Screenshots: printed and attached to show exactly what was on screen at each step.
- Colored dots: indicated which software or system was involved at each step.
Benefits of Going Large and Physical
- Created visibility into a process that had previously been invisible to the broader organization.
- Allowed Bro Sales to review and confirm the flow, which surfaced sequencing errors that were easy to correct with stickies.
- Attracted developers and managers who were not part of the original project, drawing them into the conversation.
- Surfaced the complexity of automation to managers who had assumed it would be straightforward.
- For the first time, managers could see how many steps and systems were involved in producing a single report.
Translating to a Spreadsheet
Once the physical blueprint was confirmed as accurate, the researcher transferred it into a spreadsheet, using cell colors that matched the sticky note colors from the physical version. The choice of a spreadsheet over design software was intentional: it matched the tools stakeholders were already comfortable with, kept the file size small, and made the document accessible to anyone on the team without requiring the researcher to field questions in person.
"Form follows function, my dear friends."
Outcome
The blueprint and accompanying research led to a clear decision: full automation of the report was not feasible given the number of systems, manual steps, and judgment calls involved. However, there were targeted opportunities to streamline parts of the process. Recommendations also covered visual consistency improvements to the report itself and new content approaches based on what clients said they needed.
Adapting the Blueprint Framework: A Theme Park Example
To illustrate the flexibility of the service design blueprint, the speaker walked through a hypothetical theme park design scenario. Using a persona of a group that includes an elderly person with mobility issues, the team could map each attraction with custom swim lanes.
- Customer touch points at each attraction.
- Services provided at that attraction.
- Direct employee interactions relevant to the persona.
- Positive aspects of the attraction for this persona.
- Negative or problematic aspects for this persona.
- "How might we" brainstorming row for improvement opportunities.
This example shows that the standard swim lane labels from the framework can be replaced entirely. The blueprint's value comes from the structure of mapping steps against dimensions of experience, not from using any fixed set of rows.
Broader Lessons and Recommendations
- Service design blueprints can be built solo or with a cross-functional team. Bringing in developers, product colleagues, or even clients adds perspectives and builds shared ownership of the findings.
- No special tools are required. Paper, stickies, and screenshots are sufficient. A digital whiteboard is a good modern equivalent.
- You do not need to understand all the underlying systems to build a blueprint. Enough context to name the system and understand why it is used is sufficient.
- Talk to both internal experts and external users. Internal subject matter experts may understand why certain information is included; external users can tell you whether it is landing and what they actually need.
- Surface low-hanging fruit. Even when full automation is off the table, reducing time on task, simplifying steps, and improving data presentation are concrete wins worth recommending.
Transcript
Read the full transcript
take it away Jen great thank you so much hello everyone just want to make sure you can see my screen I'm assuming so uh thank you for joining me I hope you are ready to hear and talk about service design and how ux research and can be applied to Enterprise software and services so let's go ahead and get started very briefly I'll tell you about me I'm a user experience researcher at BECU which is one of the largest credit unions in the United States I've worked in a number of industries from Finance to cloud computing and medical field I'm also one of the co-founders of ux research and strategy so if that group interests you either connect with the group or myself in on LinkedIn and I have a little bit of a warning I have a lot of doggos in my presentation so I hope you're a fan of dogs all right so let's start with the basics what is enterprise software and no it's not this spaceship for all you Star Trek fans out here uh enterprise software is used to satisfy the needs of an organization or company rather than individual users so what makes enterprise systems interesting is yeah they're not super sexy or delightful to work on for the most part they are here to help you get a job done so people tend to be on them for really long periods of time so think about someone who is managing uh content for a website and using some sort of content management system they're likely in that system all day long and also this type of software it feels a little old-fashioned and dated and a lot of times its functionality is tied to Legacy systems which also makes it feel old and ancient so the tough part about enterprise software is the users often don't have much say in the purchase of these products so the person who bought the software is likely not going to be the same person using it on a daily basis so the person who bought it is probably in procurement or technology and they made the decision and so sometimes their hands are tied when we have to use enterprise software and to be honest this kind of software rarely gets a lot of ux love simply put companies just they need these Solutions and a great user experience that the person desires when they're working and it's often neglected when it comes to Enterprise so traditional enterprise software is often like I said used internally by company by a specific user or group and generally not consumer facing so some examples of enterprise software you might be familiar with maybe you work in these too jira sales force Soho WordPress and they can manage a number of functionality like human resources payroll customer relationship management marketing software as a service it's all kinds of Industries and all kinds of solutions so now that we know what some examples of enterprise software are let me share some enterprise software that I was working on so I was trying to bring this Security application that I'm going to show you into this century now I have a word of caution this next thing I want to show you it might hurt your eyes a little bit so you have been warned here is some of the lovely enterprise software I was working on while a ux designer and researcher at a security company don't you just love the way that this looks I'm a big fan of the red and blue text juxtaposition here overall looks like it was created in what 1993 so here's an another example of that security operations center the software that analysts used every day when creating and reviewing security tickets the company I work for monitored internet traffic for other corporations they looked for bad things on that company's system like malware viruses security threats oh imagine looking at these small fonts in this dated design for hours on end pretty brutal and see all of these buttons at the top left these gray long boxes well through my research I found out that only half of them are even functional and most of them weren't even usable in the flow or the context of the screen that they were on this is a classic example of adding more items without removing the items that are not useful or required anymore I'm sure some of you have seen this okay it's the last time I'm going to scare you with that data dated enterprise software and you know it's kind of funny I've been at the company for a while and I talked to one of my former co-workers recently a few months ago and they said still using that same old school design um so that brings us to the other half of this talk service design so maybe some of you are familiar with service design and maybe you're even practicing it in your organization so for those who are little maybe less familiar with it let's define it service design is a way of organizing resources people and processes in order to improve the employees experience and then indirectly the customers experience so to me it's taking a deep look at the experience your user or your customers going through each step of the way then determining if there are ways to improve that experience even more so let's look at some similarities between service design and enterprise software so I just stated service design is a way of organizing a business process to improve the employees experience and then and directly the customers experience well enterprise software also has that secondary user helping the businesses needs and not necessarily helping the individual who's using the software directly so enterprise software is often purchased by those like I said holding the purse drains but not necessarily using it all the time so there's some interesting parallel between service design and enterprise software they both indirectly affect another person or aspect be that company or a customer so that means there's a lot of opportunity to improve the customer experience by examining how software enterprise software is used in companies so how is this done well one way is through a service design blueprint so not sure if anybody here is familiar with the service design blueprint but let me explain it so the rows going across horizontally the swim Lanes as they're known are what we can examine or examine a customer's interaction with the product of service so that's what we're looking at now the columns the vertical columns are the steps in a process so we can look at a customer's Journey through their touch points with our company by going through the different rows so this is a service design blueprint framework from adaptive path and I just want to show you the concept we're going to go a little bit more into it later just wanted you to see what it looks like so let's dive into the case study a little bit what problem was I trying to solve so the business ask was to automate making reports again this project was at a company that monitors another corporation's internet traffic and warns them of issues and threats happening on their Network so like if there is a virus on their Network or if an employee is downloading something illegally so as part of that service the security company I work for would deliver a summary or report of their network activity and the problems that they had either on a monthly basis or a quarterly basis so we built these reports and again the ask was by my company was to automate making these reports okay so before I go into that look at some of the flashy uh Graphics that were in this report super fancy uh I'll talk about this a little bit more I just wanted to give you a little taste so what's wrong with these reports well it is a very manual process to make these reports hence why they wanted to automate it it takes a person nearly two hours to make just one report and building reports like this manually it just doesn't scale also the information to build these reports came from multiple sources and based on the interviews that I conducted with clients who view the reports these reports didn't provide information that the client really wants and needs what's the design and the presentation oh it's all over the place it was not visually consistent at all so I asked myself what methods can I use to investigate how to build a better Rapport for our clients and that's when I decided to let service design come to the rescue so the first thing I did was come up with a plan of attack which was my research plan first I wanted to conduct a heuristic evaluation and that was to look at the reports to see what design and usability problems the report has you know you can conduct a heuristic evaluation on things that are not digital too you don't just have to do a monitor interface or an app then I had to get the customer's point of view part of the problem of this report was that they were building out is they never asked the customers what they needed in these reports that's a big No-No we want to meet customers needs right we want to have a user centered approach to problem solving so I interviewed customers to better understand what they wanted and needed from reports then I needed to figure out how these reports were actually put together so I used the classic anthropology approach of contextual inquiry sometimes it's called ethnographic Observation sometimes it's called side by sides I'll go into that a bit more and then I decided I was going to use a service design blueprint we a little bit of a Twist to do a deep dive examination of how these reports were put together and finally through the research I was conducting I hope that I would discover gaps and opportunities which would lead to my recommendations for improvement so that was my overall plan of attack my research plan now I want to take a deeper dive into each step I did for conducting the research to build out a service design blueprint for Enterprise systems so in this example remember service design is the process of improving an employee's experience and then indirectly improving the customer's experience so in order to satisfy the customer I had to take a multi-method approach to better understand the problem I was trying to solve which was build better reports for clients so first I need to understand the report itself what's going on in this report so I conducted a heuristic evaluation second I need to know how the report was built and conducted a contextual inquiry to understand that and then third know what customers wanted and needed from a report and that was user interviews so as I mentioned before these are all part of my plan my research plan my plan of attack and bringing all the knowledge from these different approaches and methodologies I would come up with recommendations to improve the report and hopefully that would lead to happy customers so first I had to understand what was going on in this report so I started with like I said a heuristic evaluation to examine what's going on in the report now I wasn't pulling up Nielsen's 10 heuristics or some of the other heuristics I was just doing a quick and dirty examination of the status quo looking for inconsistencies what could be confusing what's going on here and I'm going to be honest the developers in the security operations center these people are really technical they know their stuff and these were the people who were building out the reports and you know what they may not be the most empathetic designers yes subject matter experts for sure communicating things in a simple and easy way not so much so I had to look at these reports to see if a dumb person like myself could understand what was going on guess what the verdict was no I could not ah so back to those lovely Graphics I showed you earlier let's take a closer look at these charts and talk about some opportunities for improvement first the top left the chart that's titled top alert categories oh look at the red and the black and the yellow 3D charts they're so hard to read really they're so far away from the number scale so the number scales anywhere from zero to thirty thousand well that's a huge difference another problem with this 3D chart is what if the pillars in the front are higher than the ones in the back it may not be the case on this chart really but it could happen and then you might not be able to see the the things in the back so not a good approach now let's look at the top right this lovely gray and and white table so this table shows IP addresses without any context any reference just a list of IP addresses okay it does have some device names but it would take a real expert to know the differences in these devices because they all have really similar names so when I talk to a client about this chart they felt like it wasn't really useful it's it just reported the status quo they wanted to know about the devices they wanted to know is there a problem if there's a problem what is the problem so showing the status quo and not in-depth problems wasn't really useful so this chart wasn't helpful for our clients now let's go down to the bottom left so this chart shows how many incidents problems how many tickets basically the emails that we sent to that client a month who cares the clients don't care how many emails we sent them a month they're not concerned about this they want to know the content of those emails were there problems that were being reported were there Trends or themes more important than how many we sent them now the bottom right this blue chart this is my favorite this chart shows how long it took to resolve or close a ticket so the y-axis going up and down the side shows the number of tickets it goes from zero to three and it includes half numbers well I trust me when I say it is not possible to have a half of a ticket either have a ticket or you don't so there's no need for half increments and the x-axis along the bottom shows how long the ticket was open in seconds seconds not hours or minutes so look here at this chart the maximum is 28 619 seconds um let's translate that into something people might actually understand 2 000 or 28 619 seconds is 477 minutes and it's nearly eight hours well that makes a little more sense no one that wants to have to translate seconds into hours just not a good experience So based on my heuristic evaluation and later from interviews with customers who viewed these charts I found all kinds of goodies that needed to be fixed so I also talked with the people who received the reports through one-on-one interviews I asked them simply what do you need and I learned that these reports were not delivering what the clients needed they told me about how basically they needed actionable items to take to their boss one person said if we are in trouble I don't want to know that there it just that there is a problem I want to know what to do about it they want the report to be reflective of Industry Trends and concerns too are there things happening in the world right now are there current problems that I should be aware of or keep an eye out for give them the context or interpretation don't just again don't just tell them there is a problem tell them why it's happening and what to do about it they also wanted things to be personalized there are sections of the report that show generic stories and Industry related articles these reports had zero info that was used for helpful to the company or industry and the clients didn't like these generic reports at all so finally they wanted info that was useful and simply put these reports did not have it okay so now we have a better understanding of what users want but remember the original ask from the company of me was to streamline and automate making this report well in order to do that I have to understand how these reports are made but that is why I just I did a contextual inquiry basically I'm sitting with someone and observing what they're doing and asking them questions and the person I sat with there was mainly one person who built reports and his nickname was bro sales so I'll call Bros sales he walked me through every step of the process and he answered all of my questions and this is why I love this method because you get to observe people who do things that don't even realize what they're doing sometimes trust me people do things and their actions are so routine they don't even realize that they're doing them But If You observe them doing things then you can notice the actions that they take that they might not tell you plus you get to see their cheat sheets their notes their hacks the things that guide them to help them get their work done you can also ask ask questions along the way so what I learned through observation was it surfaced that the process is super manual and therefore that can introduce human error it helped me to understand the user flow I learned how long it took the software websites and systems that were involved and again the errors that could occur by interacting with all those why is that with bro sales I watched him build out a report I could also have him take screenshots of what he was working on so I could see what he was doing and he can explain everything that he did step by step and by having this information it would help me later in creating that service design blueprint so the first thing I noticed during this contextual inquiry is there were a lot of systems required to build out this report multiple websites and touch points not to mention the calculations and the scripts that bro sales had to run to determine the data that goes into the reports it was a lot and bro sales you know the person I sat with he didn't even realize he had to use so many systems again that's the real value of sitting with someone and watching them do their work you see them things they're barely aware of doing themselves so after seeing all these systems I realized that automating the reports it was going to be a bit of a challenge so after my observations I went back to my desk and I roughly mapped out the steps in the process and the applications associated with that step now you see I had this like tiny little white boards like really like this big and that's it I had very limited space I did not have a digital whiteboard to to map this out so I just wanted to get this out of my head and onto paper in a sense right helpful not to go digital and high res too quickly because I can make edits in this whiteboard face really easy just erase and fix so this little sketch in a sense um indicated the major steps and the system or the software involved in that step and this this was a great rough draft as in a reference point for when I was going to build out this service design blueprint so let's talk about that service design blueprint for a second like I said on the previous slide I had this little tiny whiteboard so I wasn't able to build this on a whiteboard it was just too much to go into detail so I went big and when I say I went big I mean it this service design blueprint wrapped around five cubicles in the office I had those flip charts you know the big Post-it paper and then Post-it notes on that and then I took screenshots and put them on there too let me tell you going Big like this I had a few advantages it provided visibility into the process now everyone could see what that ux researcher had been up to all this time it also gave me the opportunity to review this with bro sales I can confirm that the flow is accurate and it really brought to life all the jumps and steps that are involved in creating a report and it surfaced the areas of improvement having a large format like this it actually created some visual interest in the project people who weren't even involved were like oh hey what's going on over there and it started to bring others into the conversation and created some excitement so remember that service on blueprint I showed you earlier each long box across the top is in our an interaction or step within the flow that's the gold boxes here and so this is what a traditional service design blueprint looks like they have these swim Lanes customer actions the touch points the staff actions those are the points that the user or the customer interacts with and then you have this below the line and what's happening under there is what the user doesn't see there are systems that's usually the technology that are processing things at these steps and there might even be people who are involved in uh processing that step as well and so for this project though I'll admit I took a little bit of a different approach I didn't use this exact framework with these exact swim Lane uh labels and I think the beauty of this framework is that it is flexible and it can be adjusted so I want to walk through a non-enterprise example where a service design blueprint model could be used let's say you're designing a theme park how cool would that be huh and you want to create the best experience possible so you can modify a service design blueprint to map out what an experience would be for a user of the theme park and you can do so through a persona so let's do that so let's look at this through the lens of this specific Persona so we have a group of people who have an elderly family member with them who have mobility issues and they're coming to the theme park so some criteria for this is they may not write all the rights they may need more frequent breaks because they're elderly they may have different needs like accommodations for wheelchairs or special dietary needs so for this example I created some new swim Lanes we still have the customer touch point but it's in a theme park it's the attraction rather than the steps of going through something like say digital so the the orange Lane the second one down are the services provided at that attraction and then the cyan color or the direct employee interactions how that user 's Persona would interact with an employee and then I thought it was really good for the team to explore the pros or the positive or the good aspects of that attraction and then the flip side of that what are the cons or maybe the negative aspects of that attraction for this persona and then wrap it up with how might we a brainstorming row where we could come up with opportunities to improve this experience at this attraction and thinking about what does this Persona need at each of these places so for this example this is sci-fi land this is one aspect in sci-fi land has uh different things they have rides they have a restroom they have restaurants they have a gift shop and these are the gold boxes these are the different attractions that are within sci-fi land and I want to walk through an example of what this might look like with this persona again so the Persona is an a group of people who have an elderly person who might have some mobility issues and normally you would do this for all the touch points but for the sake of time we're going to keep it simple and just talk about one touch point which is the Extraterrestrial burger stand so this is a restaurant what are some of the aspects we should think about when we're designing a theme park for this Persona at this attraction so again the Persona is an elder a group of people with an elderly person who has some mobility issues so let's think about the needs of this person this persona in this attraction which is a restaurant so the how this could uh cater to this Persona so the services that we could offer well elderly person their eyesight might not be as strong as it once was so maybe large print menus might be helpful for them also glow low glycemic foods or other foods that have special dietary needs and restrictions so for the employee interaction what might an employee do at an attraction like this for this Persona well it might be helpful for them to know how to do CPR and other emergency services in case somebody has a heart attack it might be helpful for them to have upper body strength in case they need to pick somebody up who's fallen down let's talk about some of the good things that could be happening at this attraction we could offer free water rather than charging four dollars for a bottle of water we could offer free water so that in case somebody needs to take some medication throughout the day we could also offer seating in case they need to cool down because they've been out of the theme park all day a lot of times it's hot you come inside to get some air conditioning and you just need to rest so maybe it's offer seating that isn't tied to specifically to eating at a table and what are some bad things or negative aspects that can be happening at this uh at this attraction well if you have tall seats you know those bar height seats those would be really challenging for someone with mobility issues to get into also if the tables and chairs were very close together that could be very difficult for someone with a wheelchair to maneuver their way through the restaurant so then our team could brainstorm some opportunities and somehow might we statements on how we could improve this attraction so this is something I want to emphasize again when it comes to a service design blueprint it is okay to modify the swim Lanes or the rows to examine these things that are really important for your team to solve for my theme park example it wasn't important for us to explore those below behind the scenes technical aspects we were focusing on the customer experience we didn't need to know the support systems involved and so that's what's really great about this service design blueprint you can modify it to focus on what's important for your team and that is exactly what I did when it came to building a report and using a service design blueprint so let's switch gears and go back to that yeah so modifying the service design blueprint and the process let's take a look at the swim Lanes I created for this service design blueprint when it comes to building out a report so the top row the yellow boxes are the actions these are the steps that are part of building the report the orange stickies were my observations so these are the things I wanted to capture but they may not be the exact steps just some additional things I noted during the contextual inquiry now the pink ones are my notes and my comments so these are my editorial kind of comments I'm noting um gaps opportunities things I I want them to be separate because this is in my opinion and my me kind of thinking my how might we and I want those to be different than actual observed behaviors and activities these are things like maybe I want to fix and then I also had the screenshot so that everybody could see exactly what was shown on the screen during these steps and it's a little difficult to see but there's a little square on a lot of them a little colored box that is the software or the system that was involved in each of those steps so this is how I kind of modified the surface design blueprint to examine what was really important to building out this report for the team so once I got this all mapped remember I said it had it around five cubicles in the office no joke then it was time to review it with the team so first I I showed it to Bro sales you know he was the person that built most the reports and I wanted to confirm that the flow was accurate so it was what was really astounding was mapping it out like this really brought to life just how many steps and jumps are involved in building this report and and notice it's still not high resolution and that's because it's easier to fix errors early in the stage and I had to do that a bit I had some things kind of mixed up and out of order and bro sales like put me in the right direction and it's really easy to do that when you have stickies you just have to move things around also having it low res um is it's a great way to have start conversations having it big like this I have the developers coming around we they were starting to understand the process because in theory the developers are going to have to help automate this process so they needed to know what was going on so having this big like presentation was great to surface the gaps and opportunities start having those conversations thinking about what technical improvements could be made and honestly this was the first time managers had any visibility into this process and it was really critical for them to understand the complexity involved in making this report if they had not seen how many steps were involved and how many systems were involved they probably would still think it was just like easy to automate flip a switch and you're done but once they saw how complicated this process was kind of put a hold on that automation process so once the process and the stickies were all confirmed and accurate I then got a little bit higher resolution and put it into a spreadsheet now I know what you're thinking oh Jen spreadsheet ill you could have put in some fancy design software like figma made it look really nice and created this really cool digital version that could knock their socks off I could have but I decided to make this spreadsheet to meet the team where they are I made a spreadsheet because that's what stakeholders in the team are comfortable with the good old-fashioned Excel document or Google spreadsheets um it's not pretty but it's functional the file size is really small and it's easy to share so form follows function my dear friends I just want to know here that the colors correspond to the original service design blueprints so the yellow stickies became yellow cells on the spreadsheet so it was pretty easy to translate the stickies into this digital format and you know that was a little bit heartbreaking to take down that paper version of the service design blueprint that work of art that was spanning all those cubicles is this digital version was much more accessible anybody could open it on their computer and take a look at it at their desk at any time and you know what it also kept people from coming over and bugging me and asking me questions about it they could look at theirs look at it anytime on their own computer it was great so this was the final deliverable and this was the document that managers used to make decisions about the project and how they were going to automate making reports and in the end they decided they could not fully automate them making this report but there were just you know there were some opportunities to streamline and approve some things but there were just too many systems and steps and data points involved to just flip a switch in and be done with it but it was a huge win for the team especially for bro sales who's building these reports to surface just how many steps it took and to see where improvements could be made so I want to revisit my plan of attack or my research plan and talk about how the different research efforts I conducted help the team come to a decision so I created a heuristic evaluation again we looked at the report to see what design and usability problems the report has I uncovered customer needs through one-on-one interviews I conducted a contextual inquiry with bro sales by observing him building a report and asking him questions and this helped me to understand how the reports were built and finally all the data I collected along the way laid out to build out that service design blueprint through the research I discovered gaps and opportunities which did lead to my recommendations for improvement so as you can see a mixed method approach can be a really terrific way ultimately to construct a service design blueprint so after examining the process it was then time to share my recommendations we discussed where things could be automated and consolidated and based on the heuristic evaluation I did I suggested ways to improve the report visually and make it consistent and from the interviews and learning what users wanted from the report I gave suggestions on different and new content opportunities and how to present data in helpful ways that in actionable ways that our customers could use and My Hope was that we would be iterating on this report we would revise it get continuous customer feedback and uh figure out how we could continue to make this better for them so the beauty of a service design blueprint is you get that holistic view of the process to surface gaps and opportunities it showed the challenges of automation it was not going to be an easy fix like just flipping a switch like managers thought it was going to be it also included the cross-functional team that had had never been worked together before so get this uh this organization was very siled and very segregated so the security operations center the analysts they were the security analysts who built this report they were literally behind a door a locked door that you needed a special pass to get into and the developers who worked on the software didn't even have access to them so after learning about that and understanding that I need to get the people who understand the reports who build the reports connected with the people the developers who were going to improve processes we need to break down these silos so that was a big part of this too this transparency of bringing these teams together and working together and so there's the transparency of the teams working together but there's also the transparency into the process of what it takes to build out a report that the service design blueprint I feel like surface like nothing else could so is this something that you can do I would say heck yes it's very insightful to go into the steps of what a customer is trying to do and do a deep dive into each of those steps now you can do it solo by yourself like I did I was the only ux person working on this or you could have multiple people working on a service design blueprint and I actually like that idea better bringing in collaborators is a great way to get others to own this Services I blueprint with you own this process own the improvements so you could bring in developers product folks you could even bring users and clients in to help you construct a services on blueprint the more perspective you have the better it will be at exploring all the angles of a problem now you don't need any special tools as you can see I use paper stickies and markers and some screenshots maybe a whiteboard uh maybe a spreadsheet now I would if I were doing this today I would do this on a digital whiteboard I just did not have one at the time but the point is you don't need any special tools to build this out you also don't need any Tech parties and what I mean by techcratis is you don't have to know all the systems in and out for the developer for for you to build a service design blueprint you don't need to be a tech expert believe me I knew nothing about the systems that bro sales was using to build the report but he explained enough to me to know what the system was and why he was using it and that was enough so for this I not only talked to also the uh I told you I interviewed customers but I also talked to our internal Security Experts because I thought it was important to get both both perspectives there were things that Security Experts felt that customers needed to know and so I needed that perspective too to understand why they were putting this information into reports and it was an opportunity to maybe teach the value of this information to our customers which they didn't see so I think that uncovering some of the low-hanging fruit the automation we're not going to automate the whole thing but automating small bits and pieces this low hanging fruit is a great way to recommend improvements you can do things like reduce time on task reduce complexity and suggest better processes and so yes folks the question can is a service design blueprint for you I would say a big fat yes now I know we talked about a lot but hopefully you can see the value of applying a different research methods and how you can create a service design blueprint for something that you might be working on so my major takeaway for you today is it is okay to modify and involve that traditional template of a service design blueprint do so to meet the needs that you have your team's needs as with all the work that we do you know nothing is set in stone we often hear in user experience oh it depends right so feel free to adapt this excellent tool for your research needs thank you very much does anybody have any questions foreign thank you Jen um it doesn't look like there's anything in the chat yet so if anyone watching has any questions please put them in the zoom chat but just to get the conversation started I liked how you started with the stickiness then translated into a spreadsheet which you always recommend doing it that way or like having a physical representation first or do you think you can still get the same benefits starting and maybe a spreadsheet and moving around cells or is there a difference you think uh I would like I mentioned if given the choice to do it today I would um I would do it in a digital whiteboard because that is as accessible and it gives an opportunity to put the visuals the screenshots right in there as well so it um which was a little bit challenging in an Excel because it it's hard to really get that in there in a nice clean modular way so I would say um and a digital whiteboard is as flexible as moving paper stickies around so that would be my suggestion is that um you could use a digital whiteboard there's a lot of great tools I'm sure most companies are using some form of a digital whiteboard these days and so that yeah that's where I would suggest that you you uh you can and you can clean it up to look like a pretty fine deliverable in the end good thank you did um when you were interviewing gross sales did you have any like issues getting him to like take on your trust like you are someone who's not typically working with watching his processes was there any kind of like collaboration or friendship building that you had to kind of doing from the start for you to get the Real Results that you needed sure uh that's a good question yes I was not I was a ux researcher I was not uh working in the security world I didn't know what he was talking about but as with any good researcher right you build a rapport and I was sitting right next to him hours on end multiple days we built a report pretty quickly I was lucky that he was a very friendly person very accommodating and very patient and so I was asking a lot of questions what are you doing why are you doing that and not and he was not defensive about it I'm like look I'm dumb treat me like I'm five talk to me that way I'm just here to learn and take screenshots of everything that you do along the way and it was it was it was great we we still even though we're no longer working at the same company I still call him bro sales we're still friends and uh like I said as with any good researcher you do that's a key critical skill is to build that Rapport and build that safe environment and and treat them as they are the expert that apprentice and a printy relationship that's what we had I am here to learn from you I don't know anything and that usually kind of um dissolves most like egos or you know awkward Dynamics it's like I don't know help me out and a lot of people are really uh welcoming and open to working that way wonderful also with your um your interviews for the customer's point of view was that on the phone Zoom Skype is there a method that you recommend being the most effective in getting the best client feedback that those happen to be over the phone uh but I would say Zoom um would have been effective because then one of us could have brought up the document and actually been looking at it at the same time um it was a PDF that we sent them and so bringing up that document saying oh on this page uh and what I could do that I was on the phone and I bring up my computer we were sharing it you know but I think a rapport would have been a bit uh a bit stronger had they seen me and I could see their reactions rather than just hearing it through the voice on the phone right and did you have a favorite part of this research process favorite part um I am a huge fan of contextual inquiry so sitting with bro sales and actually seeing things seeing mistakes that he made like he Mis put in numbers and when he was writing scripts and being like Oh hey you said you wait you said you were doing this but that number wasn't the same you know and and observing those hacks and those shortcuts and the things that they don't even realize that they're doing you're like wait you you said your next step was normally to go here but you popped over here instead is this a unique case and he's like oh no yeah I guess I do this too and I didn't realize that you know you're never gonna see that you're never going to hear that in a post-event interview right so the goal there is to really see um what they're doing and and how and because they might say oh I just copy this from word but what they're doing is They're copying it from we're putting it into Excel and writing the script and coming out and then putting it back into a different plate and you're like oh wait there were other things in between that you didn't mention that you did that I just saw you do what's happening here so seeing that firsthand is is really gold okay all righty I am not seeing any other questions popping up unless I'm missing a double check or I'm not seeing it all right well thank you so much for your presentation today and for everyone attending today's events um this was our last presentation of the day so I hope everyone has a wonderful evening thank you thank you thank you thank you bye
