In my first post in this series, I covered why user experience design needs a customer experience strategy. In short, the functionality and design of a user interface is only part of the experience. A customer experience strategy takes into account the rest - the goals, behaviours, feelings, and environment that influences how a person interacts with your system and company.
So, now that we agree it’s important, how do we develop the strategy? I’ll review the parts of the strategy kit that I developed that we use at Tquila, although typically the end product is a mix and match the elements based on the needs of the project and client. And more importantly, I'm constantly evaluating and updating the kit based on what we learn works for different clients, stakeholders, projects, and technologies.
In this post:
- The Vision
- User Personas
- User Journey Map
- Experience Design
- Summary: Applying the strategy
Each project starts with kickoff conversations and workshops to discuss the goals and objectives of the business. Some of the questions I ask in these meetings include:
- Where does your company want to be in the next 1-5 years? Discuss the company’s strategic overview and future state business goals
- What are the measurable goals and objectives to get there?
- What tactics or initiatives have been started or are planned in the near future?
- What is the vision for new system?
- What are the measurable key performance indicators (KPIs), short and long term, that will determine success?
- What are the pain points for the current processes and systems?
- What will a change mean for the business and customers?
These questions are key to any business but are sometimes surprising hard to answer. Some stakeholders have had these discussions before and have a clear strategy, but the addition of certain functional leaders in the room offer a new perspectives and insights.
For this post, I’ll use an example of a fictional company, King’s Sandwiches (from a combination of a recent project I lead for a franchise company and other work with similar partner-based business models).
Here is the first page of the strategy, a high level representation of recommended tactics to achieve their vision and objectives.
Here’s another example from an aged care home strategy project. A high-level goal was to grow the home care side of their business, and here’s how I drilled down into developing specific tactics and opportunities to achieve that goal.
Ideally, they would also have a revenue target for this goal over the next 3-5 years. The questions I asked related to this goal were aimed to get to specific, measurable objectives:
- how do you target and obtain home care clients?
- how do you deliver these services today?
- how do you plan on growing these services?
- what are the pain points you have today in this area?
The measurable objectives in this example came from a combination of the answers they had and some assumptions based on the description of the pain points. For example, they mentioned the turnover of staff in the highly competitive area of home care services, so I probed with questions around it: why do they leave? how could you reduce this? Then, the strategy can include how a customer (or employee) experience strategy or system can help (reducing paper and manual processes so they can focus on providing care).
The next step to understanding the strategy is to understand the customer or user (I use this words interchangeably in this post, but generally a “user” is a customer who is actively engaging with a system or interface I am designing).
A persona is a profile of a fictional user. The profile should focus on behaviors and goals, rather the demographics.
Some questions I ask to start the discussion:
- Who will use the system? Think about roles, behaviors and goals (rather than demographics or specific people)
- What does that persona come to the system to do?
- What do we want them to do?
- What would help them achieve their goals? What would drive them away?
- (If it’s an internal or B2B role) what are the KPIs for this person’s job performance, or what are they getting paid to do? What are they doing on top of this that may be outside their primary role?
In my King’s Sandwich example, one primary persona whose experience is key to the system is the franchise support manager. This persona supports the on-boarding, day-to-day operations, and ultimately the success of the franchise. I gathered the data for this persona second-hand from business and project stakeholders, but depending on their amount of regular interaction with the user, the data would be more reliable direct from the source.
In the “Recommended experience” box, you can see where the persona wants and needs are starting to shape the tangible features of the system. What we want Sarah to do and feel also needs to be a factor, and especially become relevant when starting to craft the headlines, calls to action, and other key site/app copy.
Another example comes from a break/fix field service company we worked with (I’ll call them Speedy Plumbing). The goal of this deliverable was more to create empathy with the user and shift the culture to a customer-first mentality (rather than dive straight into features). The company didn’t have a specific project identified, but was using the strategy created to start the discussions around areas for experience improvement and priorities.
An important feature of this second page is the spider/area graph that shows the contribution that this persona has on the business objectives. The larger the area, the more direct of an impact making this person happy would have on what the business is trying to achieve.
User Journey Maps
A journey map is an outline of a persona’s experience or journey through their interactions with your company to achieve a goal. The purpose of a journey map, like a persona profile, is to create empathy with your user. It is also a tool to identify key interactions, predict and prevent pain points or drop off and think about how and where to talk to your user.
Here is an example of a journey map I created for an internal project here at Tquila, the journey of a customer considering and buying our Salesforce consulting services.
Journey maps are important when designing a new system or transforming an entire experience. They can also be extremely insightful when looking at how mobile and other digital experience integrate with physical products and services. To create a journey map, I would highly recommend starting with researching actual users or customer service employees that speak to users on a daily basis. Product and project managers, while well-intentioned, don’t always have the full picture of users thoughts and feelings.
The purpose of the final part of the strategy kit is to transition from strategy into design. Based on insights from the personas and journey maps, I create high level wireframes of key pages - landing pages, dashboards, task- or action-heavy interactions, product detail page, etc.
In our King’s Sandwich example, which happens to be a Salesforce solution, I proposed a dashboard specific to the needs and wants of Sarah Support Manager.
These wireframes are intentionally high-level, to prevent the conversation from diving into fields or requirements, since much of the experience could be out-of-the-box Salesforce Lightning Experience. The feedback from stakeholders, or even better from users, can be guided around “would you benefit from these types of features?”
In another example, from a different field-service proposal, has slightly more level of detail to validate some of what we heard around the work that the engineers do, and to propose a custom mobile app that would completely rethink how they track their jobs to be more inline with how they told us they’d prefer to work.
Summary: Applying the strategy
How the strategy gets applied always varies and depends on having stakeholders that understand and can champion customer experience within their organisation.
Ideally, a user experience designer takes the high level experience, like the wireframes in the examples above, and continues the design process by brainstorming, reviewing, and revising with the product and project team members. Design down to the appropriate level of detail for the project:
- High level for a business analyst (for custom or complex development) to document detailed functional and technical requirements, for the full project (waterfall methodology) or in sprints based on a group of features (agile methodology)
- More detailed level for functional consultants (like our Salesforce solutions team) or developers
Wireframes with page- and feature-level descriptions are helpful, and clickable prototypes are even more useful for visualising how an experience will work. I use Axure to wireframe, which includes features for prototype rich interactions. My prototypes can actually show how a filter will work on a product category page, for example, instead of me having to write or explain it.
The experience design should also include notes for visual designers, such as example content types, some reasoning as to placement or layout if there is a strict requirement, and insights into the interaction of components (or prototypes, as mentioned above).
User experience designers should always involve whoever they will be handing the project off to, a business analyst or developer, as soon as possible so they can be part of the brainstorming and see first-hand how feature decisions are made.
Without a user experience strategy, new sites and applications can be a mix of business stakeholders personal agendas, opinions, and pieced-together features from how things work today. When you can start with the users, and how their wants and needs contribute to business objectives, the experience feels cohesive, and is naturally adopted.
Comment | |