I was recently a part of a strategy group for a service design engagement that lasted for roughly eight weeks. Our agency’s purpose was to define the product we were selling for our client, determine its human and technical resourcing and infrastructure, and articulate how to enter into the current market.
I turned to various popular books on service design to help me shape my approach, but most of these books dealt with documenting and improving upon a service for a well-defined product. In my case, I had no tangible product, just an idea, which vastly changed the types of deliverables I was able to create and what to emphasize within them. For example, instead of delving deeply into a set of functionalities, I honed in on major interactions between actors to reveal business needs and considerations and how decisions between actors impact each other.
My solution was to adapt currently existing deliverables in order to fit what my stakeholders needed. Below you’ll find templates of deliverables I created, which I hope will be useful in strategy projects that deal with artifacts beyond interfaces.
Introducing Actors
I chose not to use personas in this strategy project, due in large part to time constraints, but also because creating thoughtful personas requires an established knowledge base and detailed analysis: resources that weren’t available on this particular engagement. Instead, I looked at what I needed to explain to investors and to our stakeholder, which was: who are the general groups of people involved, how do they make their decisions, and how does that affect their workflow and the future product?
I could address those factors by personifying entities, such as the end-user population, an enterprise client, and our stakeholder’s organization, and use them to act out major workflows, needs, and attitudes. The major difference between actors and personas was how I chose to define actor groups: instead of thinking about end-users of a product, I targeted individuals or entities that would have a hand in developing, selling, and, finally, using the product.
For a B2B, the actors would include someone from the organization selling the product, the enterprise client, and the end-consumer. Using these broad parameters gave me leeway to refer to multiple individuals within an actor group and, most importantly, set the focus on developing an infrastructure for a business as opposed to getting into the business of predicting a consumer’s emotional needs and feature requirements.
Actor example
Articulating the Service Ecosystem
Once the actors were defined, the next step was to identify the service ecosystem. Defining what each actor must provide to the others, and the value of each service, is a way to begin articulating the requirements in order to run a successful business and also provides an internal checkpoint for the strategy team to make sure there is a purpose for each engagement between actors.
I relied heavily on Andy Polaine et al’s book, Service Design and the authors’ description of a service ecosystem. For mature products looking to map out and/or evaluate major players, feedback loops, and well-defined agents (such as interfaces, supporting channels, etc), I would highly recommend looking at their service ecology map. For strategy projects with the main goal of providing boundaries of services offered, that level of specificity may dilute from the most important aspect of an ecology map, which is to emphasize the relationship between actors in an environment. My version of a service ecology map was geared towards a B2B, and therefore has three actors represented: the seller, buyer, and consumer. When the actors have been identified, simply swap out their role (e.g. seller) and replace with the actor name (e.g. John).
Service ecology deliverable
Taking Actors Through a Interaction Workflow
Once I defined the actors and their ecosystem, I needed to articulate in more granular terms what their requirements were in order to support their organization or how the product solved a pain point, where the actors crossed paths with each other, and how they interacted with our product. In order to showcase these qualities, I illustrated a glorified workflow, borrowing elements from other common user experience deliverables, including sequence flows, customer journey maps, and scenarios.
Service workflow
These types of workflows can be easily adapted to reveal information needed to communicate with particular sets of stakeholders. The template above takes the element of “stages” from customer journey maps in order to identify various environments and mindsets. I selected variables on the left side of the workflow to support my original goal of communicating what an actor needs in order to have a successful interaction with our product. The first variable is “Actor Scenario” as a way to briefly narrate what an actor was doing or what his pain point was at a particular stage. Next, I illustrated the steps taken in the “Engagement” variable to successfully enter to the next stage. Finally, I documented the product’s solution to support the actor. The variables, of course, can be switched out or expanded upon depending on the nature of the project and the salient points that need to be communicated.
Adapting Deliverables
Creating actors, modifying a service ecosystem, and generating an enhanced workflow were all done in order to meet the needs for a strategy engagement—I didn’t set out to change currently existing and well-known deliverables. However, when these systems and tools didn’t meet my needs, I had to think of modified ways to communicate with my stakeholder. I iterated on these deliverables quite a bit, trying to understand exactly what I needed to surface, and how.
In the future, I would list out all the topics I need to explain and communicate to a stakeholder and make sure that each deliverable answered a specific set of questions that were critical to understanding the product and the industry it is a part of. I knew that these deliverables were successful when other team members began using them to articulate different dimensions of the project’s goals. The deliverables acted as a catalyst for defining our strategy: seeing my team use them as a basis to create a product roadmap and business plan was how I knew we had set up a thriving service ecosystem.
Image of hummingbird courtesy Shutterstock.
