Chapter 4
Presenting without contextualizing
Abstract
When we work on a project daily but stakeholders only have periodic reviews, a context imbalance arises. We become intimately involved with addressing their feedback, but they only have passing familiarity with the work that prompted that feedback. True depth of critique requires reviews to be structured to renew that missing context each time, so feedback encompasses more than surface impressions. Keeping the research artifacts and deliverables on hand helps tie your decisions back to real users, and showing work in the context of change from previous, not just new, reminds stakeholders of their motives for the original feedback.
Keywords
context
presenting
feedback
review
agenda
stakeholders
artifacts
personas
maps
“Out of mind as soon as out of sight.”
—Fulke Greville1, Lord Brooke
Talk to anyone whose job is to produce creative solutions and you’ll hear the same story: stakeholders give feedback in one direction at the first session, and then directly contradict it in the next session. One week, they’re musing about how there’s not enough blue, the next week, there’s blue everywhere and it looks terrible – take some of the blue out!
Why are clients and stakeholders so mercurial? There is certainly a subset who micromanage design through the feedback meetings, trying out whims and exploring at the wrong level of fidelity. However, we’d like to believe that these are in the minority and the vast majority of people you’ll present to in your career have the best interests of the product in mind. The problem is really an imbalance of contact time with the design.
Wherever possible, we like to give our clients and stakeholders as much involvement in the design game as possible. That can mean pairing, active exploration of design during requirements sessions, and getting the work up on the wall for maximum visibility. But it’s not always possible – for example, if you work in an agency environment, it’s unlikely that the client will be constantly present and you may have to fall back on periodic review sessions. Similarly, if you have a large and/or busy group of stakeholders involved in the product, you may only be able to bring some of them into the process and will still have to present to the others.
Put yourself in the shoes of these attendees. They may not have seen the work for a week or two. In the meantime, their focus has been on other aspects of their jobs. You’ll talk them through the current state of the work and ask for feedback, with only a minimum of contact time. No wonder the resulting feedback is often superficial and doesn’t take into account the full context in which the design solution was prepared. Equally, having given off-the-cuff feedback, it should be no surprise that the feedback doesn’t stick in their minds for the next session or that, if it does, it doesn’t match the exact form of the solution they originally proposed.
This contact gap can be very dangerous to your design aims. It can rob your work of depth by focusing only on the immediate impressions. The more complex the product you’re building, the more risk shallow feedback poses. The missing ingredient in providing that depth is design context – the set of user insight, feedback, reasoning, and assumptions that led to the solution being presented.
Resolving this context imbalance means more than just walking through your solution. It means explicitly telling the story of the background insight that led to the solution, and making the evolution and original feedback response clear. It means telling the what and why of the paths that weren’t taken – because these will inevitably come up as suggestions if you don’t. To do this effectively, you must prepare more than just the design collateral for feedback sessions: you need to work out the story you’re telling, and also prepare the assets that allow you to tell that story visually.
Common assets for providing context
We produce a lot of artifacts during the UX discovery and design process, but often these fall into disuse once created. Remember that stakeholders have fallible human memories and may forget the detail of assets that have been signed off or are not being used. Keep these up on the wall and visible, to act as a reminder and reference.
Personas are probably the device used most often to provide design context in UX. They’re an encapsulation of the research, a reminder of contradictions within various aspects of the audience, and a reminder of the service boundaries the product will live within. We attach all of these purposes to a realistic-seeming face and name – the persona – so they stick in the memory of everyone working on the project. This helps us keep stakeholders focused on the needs and abilities of the end user when prioritizing features.
Maps of various kinds are vitally important in providing the underlying requirements for our design solutions.
Process maps explain why there may be more or fewer steps to a given journey, highlight external dependencies that force design solutions, and demonstrate how confusing situations have been avoided.
Figure 4.1 Persona Example. (Photo by: Martina Hodges-Schell.)
Experience maps help lay out stages in a user’s engagement with a product and the user’s needs and goals at each stage. They also show how each service touchpoint is integrated into the customer experience. On a larger scale, these evolve into Service maps, giving context of bigger systems.
Empathy maps capture snapshots of a persona’s experience and help teams better understand their context and identify goals of their users. This insight is used to design products and workflows that help users achieve their goals more effectively.
Story maps act as an interim step in developing an information architecture. A story map is an affinity-grouped set of user actions (for example, one affinity group would be the actions around registering, logging in, logging out, and managing a profile). These are a fantastic way to show the range of abilities a user will have on a site without committing to a fixed structure or initial scope. Story mapping is also a great way to help development teams break down work into bite-size chunks. When the information architecture is formalized, the story map evolves into a Site map.
Figure 4.2 Process Map. (Photo by: Martina Hodges-Schell.)
Figure 4.3 Experience Map. (Photo by: James O’Brien.)
Figure 4.4 Empathy Map. (Photo by: Martina Hodges-Schell.)
Figure 4.5 Story Map. (Photo by: Martina Hodges-Schell.)
Along with these maps, here are some other useful artifacts that help expose the insights driving our decisions.
The Customer Life cycle maps the entire journey that a user goes on over the course of engagement with the product. Beginning with initial awareness of the service, the life cycle follows through discovery and understanding, to repeat use, habituation, and advocacy. For a service that has a defined end-of-engagement, the life cycle also defines how a customer will disengage in a positive way.
Experience principles act in a complementary fashion to personas: they assert the personality of the product being developed. By acting as an agreed-upon frame of reference to guide design decisions, they give us permission to pursue quality and a benchmark for UX success.
Once design reviews have begun, the sign-off from the previous review provides a vital line in the sand for decisions that have already been made and therefore are likely to incur a higher cost to change. It also shows the framework within which the current round of work needs to operate, and helps direct feedback expressed in the form of solutions to be coherent with the existing work.
Figure 4.6 Customer Experience Life Cycle. (Photo by: James O’Brien.)
Figure 4.7 Experience Principles. (Photo by: James O’Brien.)
Telling the story of UX
In the authors’ careers, we’ve sometimes found ourselves starting in new workplaces and being treated like celebrities whose mere presence will solve a host of entrenched problems. However, this “rockstar,” “ninja,” or “wizard” status often goes hand-in-hand with a lack of understanding about how UX has to integrate with product development and company culture. It places us in an outsider role, where our deliverables are seen as having a magical ability to make people understand experience design, without needing to see, understand, or adopt any of our process.
There’s nothing magical about what we do – we use research, heuristics, and exposed assumptions to make decisions and document them. This can only feel like magic if the research insight and heuristic basis are hidden and the assumptions aren’t exposed. An organization like this is not a bad place to be, but you need to make it your mission that the people you’ll be working with begin to understand your processes in the context of more than just the end result.
The most powerful rule of thumb we have discovered in our UX careers is “when in doubt, tell a story.” As social animals with powerful memories, humans are innately primed to respond to the structure of a story. Indeed, in The Science of Discworld II: The Globe, Terry Pratchett, Ian Stewart, and Jack Cohen make the argument that, far from being Homo sapiens, the wise man, our social structures and biology make us more suited to be Pan narrans, the storytelling chimp.2 Further, they argue that we were only able as a species to build civilization because of our ability to share a vision by creating and telling stories. If stories can manage that, they can definitely get you through the next review.
A narrative must have several features to become a story. First, every good story has a beginning, a middle, and an end. To apply this to an experience, think about the story that a signup form, or a progress indicator tells: here’s where you started; here’s where you are; here’s where you should be going next.
Stories need a focus – a character or event that everything else flows from. We often speak about making a piece of content “the hero” of a layout, or a key feature that defines the whole product.
Finally, stories need to live in a setting that makes them feel real. Think of the personal details we add to personas to make them seem more plausible, in exactly the way that a novelist or screenwriter will bleed backstory into a character.
From these parallels, it emerges that, consciously or unconsciously, we tell stories all the time in our work. However, all too often, we expect stakeholders to jump into the middle of the narrative – here’s where you are – when it’s been awhile since they read the previous chapter, and they’re a bit fuzzy on what the ending is supposed to be.
It’s also vital to do the hard work of editing your story – showing only the aspects of the work that move the narrative forward. Low-fidelity wireframes are a great example of this editing; by not including visual design, they prevent stakeholders from feeding back on an aspect that is not intended to be included in the discussion. Use editing to guide your stakeholders to give the right level of feedback at the right time. Match the fidelity of your review deliverables to the level and subjects of feedback you expect to receive. For example, when you’re looking for feedback on a user flow, show a zoomed-out view of the flow, not fully designed concepts of each individual page. Be careful not to show solutions when you’re still defining which problem you’re solving.
Don’t allow stakeholders to break out of context, either. Eager (or combative) stakeholders will often jump ahead on the boards or in the handout to ask questions about something that hasn’t been presented yet, or ask flow-breaking questions that require unpacking before your narrative can continue. Structure your presentation so those present can only see the currently contextual deliverable, and respond to questions that jump the gun with “I’d like to do a complete run-through to tell the whole story first. Make a note of any questions or suggestions you think of, and we’ll do a second pass, step-by-step, to address them in depth.” It’s even better to establish this at the start of the session (or with an agenda in the invitation) so the expectation is set within the group, and anyone breaking it is crossing a social boundary. Ensure that each deliverable has a recognizable title or reference that stakeholders can make notes against.
Another powerful method for focusing feedback is to ask stakeholders to capture their thoughts in writing during the first pass. Run the pass so they have enough context to follow the flow, but do not explain every aspect of the design. Go relatively slowly so they have a chance to view the design and capture any thoughts. These can then be used as a springboard for subjects that need further expansion on the second pass. Capturing feedback in this way not only focuses the topics and volume of feedback, but also avoids groupthink by preventing all the stakeholders present from jumping onto the back of the first spoken comment.
Getting good feedback
Good feedback is vital to developing successful products. We as UX designers rely on the experience of specialists in the business area of the product, just as those specialists rely on us to provide the UX domain experience they lack. But poor or nonactionable feedback is triply damaging. First, it crowds out useful, actionable feedback that we could use to angle our work closer to the goal. Second, it erodes the trust relationship between us and our stakeholders. Third, when it’s not actionable, it leaves us staring at a round of work with no direction to follow. Feedback is so vital to the process, failing to provide the environment in which everyone’s feedback can be of optimum quality is a dereliction of our duty as UX designers.
The “work” aspect of UX often feels like the production of deliverables, with presenting them being no more than an interim or endcap activity, or possibly even a chore or distraction. An extra hour spent on the production of deliverables, rather than the preparation of how they’ll be presented, feels more like legitimate work. But this is a close-horizon view of the process. At its best, feedback should improve the quality of the experience for the user, but if you present your work poorly, you invite feedback on the quality of your explanation instead. Responding to feedback of this type means compromising the experience in favor of making it more obvious to the stakeholder, not necessarily better for the user.
The user is better served by getting quality feedback on concepts that are well-understood by those reviewing them; quality feedback is something that does not arise of its own accord. Switching that hour to preparation instead of production may not produce a tangible document, but it may result in a better experience in production. And that, however it is achieved, is our real job.
Summary
While the product needs to speak for itself in front of end users, the interim assets we create can’t be expected to do so in front of stakeholders with different concerns and targets. The solution itself needs to be the central character in a story that explains the wider context of its history, the evolution of the solution, and the end goal. Without this, stakeholders will respond to superficial aspects of the design, with little investment leading them to remember their motivations at the next round of reviews.
The “Presenting Without Contextualizing” anti-pattern
Our work competes for attention and priority in our stakeholders’ minds. We can’t expect them to have perfect recall to retain all the detail from review to review. A context imbalance arises when we spend a lot of time with the work, but only show it to stakeholders periodically at design reviews. If we present carefully reasoned detail without refreshing our stakeholders’ view of that context, we invite feedback that serves stakeholders’ need for better explanations, rather than the users’ best interests.
You know you’re in it when…
• Stakeholders give contradicting feedback in successive rounds of review.
• Stakeholders give feedback only on a superficial reading of the deliverables.
• Much of your work seems to be tweaking or fiddling on a minor level, but there are unresolved major issues.
• You follow feedback suggestions to the letter, but the stakeholders making those suggestions aren’t happy with the results.
• You spend more time in review sessions correcting misconceptions about the design intent than presenting the work.
• Stakeholders take the work and present it themselves, leading to nonactionable feedback from the people to whom it was presented.
How to break the anti-pattern
The realization that you’re in this anti-pattern tends to come right in the middle of a design review. However, this can also be the most dangerous point to try and fix it. The realization usually comes as part of an emotionally draining process and, while it can be tempting to identify the context imbalance to the group, that can all too easily come across as belittling their present concerns.
If you do choose to deal with this head-on in the review itself, several patterns in Chapter 11 can help you choose the right wording and tone.
If it’s early enough in the review, you can take a step back and use some of the patterns below to recontextualize the attendees – for example, Setting the topic and The half-silvered mirror can be used in-flight to bring stakeholders up to speed, especially if they’re introduced with “OK, let’s take another run at this...”
However, the best way to break out of this anti-pattern is to be in control of the review from the start. Get to the end of the present review, and use the full arsenal of these patterns to start out right the next time around.
Patterns
Prepare for presentation
Tell them what you’re going to tell them; tell it to them; tell them what you told them.
Go into every presentation knowing what story you’ll tell, and with your deliverables in the right order and with the right support – annotations, alternate views, Post-it notes – to follow the narrative. Ensure that the story is told end-to-end before collecting feedback; explain upfront that the session will be structured as a noninteractive run-through, followed by a step-through for in-depth assessment. Don’t structure your presentation in such a way that stakeholders can jump ahead of you. Have on hand (or preferably on the walls) the artifacts that give context to your decisions – personas, maps, principles, and so on. Have a capsule explanation of the story to date for any new arrivals who haven’t been involved in the process yet. When preparing your presentation, always remember the context imbalance and err on the side of letting the stakeholders dismiss excessive context.
Be present to present
Some organizations have the explicit habit of sending the presentation deck to all stakeholders before the meeting so they can look through the content at their leisure. This can be useful if the audience is of subject-matter experts who know how to read the content. However, design reviews with out-of-domain stakeholders, especially the challenging ones, have to be handled differently. We must be able to set the context, tell the story, and guide the team through the feedback process to shape the product successfully. We recommend circulating an agenda with what you are going to cover, but no artifacts that could pre-empt a contextualized review of your work.
This happens after the presentation, too – often stakeholders or clients will request the design artifacts so they can present them onward or circulate them to their teams. This is a tricky request; ideally, we’d prefer not to have the work presented with such a risk of context imbalance. However, an agency (for example) can hardly tell the client that they can’t take away the work they’ve paid for! In cases like this, try to offer an annotated deck, offer to be available for explanations or to resolve misunderstandings, accompany the deck with the already-captured feedback so duplicates are avoided, and request that the product owner pre-rationalize any feedback that results so the aims remain consistent.
Casting feedback
Remember that context imbalance means stakeholders give feedback that isn’t deeply considered or clearly held. Unpack the underlying concerns that the feedback embodies – for example, if their feedback is that the logo needs to be bigger, unpack their concerns with them to discover that, perhaps, they’re concerned about brand visibility. Then capture this feedback (with their agreement), rather than the original feedback that has been resolved. In this case, rather than “make the logo bigger,” you’d capture “we’re worried that the brand needs more visibility,” which gives you more scope to explore solutions that suit both the brand and the user better.
Importantly, once you capture feedback in this form, you must stop discussing it. The root cause has been identified and anything else becomes unhelpful attempts at solving the problem that will not only color your approach to the solution, but also set expectations among the stakeholders for how it will be fixed, limiting your ability to design freely. State the feedback, say that you’ll look at it for the next review, and encourage the group to discuss the next item on the agenda. If a stakeholder tries to return to that individual piece of feedback, reassure them that the action is on your slate and the group is using its limited time to focus on the next item.
When you play back the results at the next review, always show feedback in the context of the previous stage. “Here’s what we showed last time. The feedback we took from this was that the brand needed more visibility; here’s” – and only now do you show the new version – “how we addressed that.” Casting or positioning feedback like this has several major benefits: it ensures that the historical context of your new decision is correctly communicated; it prevents flip-flop feedback because the nonworking solution is clearly presented and discarded; and it makes stakeholders feel smarter for raising it that way.
Set scope expectations
Know before starting which aspects of the work are ready for feedback and which aren’t. Where possible, edit out the ones that aren’t ready. Begin your presentation by introducing the areas that are up for discussion this time around: “Our focus this week has been on the sign-in and registration form, so that’s what we’re seeking feedback on today. You’ll also see some changes to the navigation and the footer, but we’re still tweaking those, so please consider them as not part of the feedback target today.” If someone tries to lead feedback into an irrelevant area, then suggest that, “as it’s not quite ready and we only have limited time in this session, we should probably park it until the next round.”
Actively confirm understanding
When presenting particularly complex solutions, or when understanding relies upon a particular set of knowledge that you assume everyone present has, it’s OK to ask whether you’ve been clear on everything you presented. “Have I filled in all the gaps here?” “Is everyone comfortable that we’ve captured that process properly?” “Would anyone like me to unpack that a bit more?” It’s important to phrase this in such a way that stakeholders can admit to needing more explanation without it seeming like a failing on their part. Many stakeholders feel that they need to maintain face, and will feign understanding rather than admit to ignorance.
The Half-Silvered Mirror
Remember that our deliverables generally only show the user’s side of interactions, so it’s often important to remind stakeholders that what appears to be one thing to a user can have a very different meaning and motivation for the business. For example, surprise-and-delight elements can be seen purely from the point of view of the user as “a nice touch that makes me smile.” Stakeholders who only have the user view of a delighter can easily write it off as an unwarranted cost, unless they understand the business view that this acts as the key to positive emotion, generating increased user engagement and making the user more likely to share the experience of the product with friends. Doing this preemptively the first time you introduce a particular element serves to remind stakeholders that you have business goals in mind.
Tell them what you told them
Finish each review with a capsule of what you showed and what you learned in terms of feedback, so that everyone leaves with the same understanding of the actions to be taken. You can also send an e-mail message that sums up the review, along with your cast feedback, along with any other action items and their owners, which then forms the skeleton of the agenda for the next meeting.
If others inflict this anti-pattern on you
Always be aware of potential context imbalances when reviewing the work of others, and be prepared to chase down understanding before submitting your own feedback. Always test to see if you can tell the story of what’s been told to you – if you can’t, you’re missing something vital to your ability to respond.
One way this anti-pattern tends to play out is when stakeholders themselves are subject to shifting contexts. This often means the project is subject to incomplete requirements or is being governed by a divided set of owners who are changing direction with the wind. Resolving this is more normally the job of a project manager or product owner, but you can raise it to them if they’re not aware of its effect on you.
Always be sure that you’re being provided with the background you need to be able to do your job well, whether this is research, insight, business knowledge, or product vision. You can’t communicate context if you don’t know it yourself.
Terminology explained
Context imbalance
Design context
Casting feedback
Active confirmation
Pan narrans
Empathy map
Experience map
Feature map
Service map
Personas
Case study
Chris Downs, founder of live|work studio
Figure 4.8 Chris Downs. (Photo by: Chris Downs.)
At Live|Work, the service design agency I founded in 2001, it occurred to us that, when pitching new service concepts to clients, no matter how strong or compelling the idea was, clients would often respond by finding reasons not to take it on. We would often be briefed to deliver a disruptive service innovation, however, and we began to see a pattern. The more disruptive an idea, the more reasons a client would find not to invest in it.
We had a client that was in the widgets business. It was a truly global, family-owned business that had been established for well over 100 years. Over that time, it had amassed a huge product library of widgets designed to suit every known instance in every market. Their brief was typical for us. They needed radical, disruptive innovation because their business had become commoditized and they could no longer compete with their traditional widget sales business model.
Our team of design researchers spent a considerable amount of time on observing their customers and end users in markets around the world. What we came back with was remarkable. The vast product catalog that our client was so proud of was largely unnecessary. What customers wanted was less choice and much faster delivery. This, we thought, would be great news for our client. We could save them millions through rationalizing their products, which would also simplify their stock and supply chain management, which would enable them to deliver the widgets to their customers much more quickly. Fantastic.
The idea was simple and very compelling, but we were concerned. We were at their global board meeting and we were about to tell them to slash line after line of products their customers didn’t really want or need. We knew that the executives would resist. We were preparing ourselves to hear of all the reasons why each and every product was necessary, how each market’s needs had to be met, and how having a dramatically smaller product catalog would hand the advantage to their competitors, so we decided not to pitch this idea to them.
Instead, we “faked” the idea. We quickly “forged” artifacts that made it look as though the idea already existed. And what’s more, we made it seem to be an idea owned by a competitor. We borrowed the design language of Easyjet and mocked up an extremely convincing website that we called EasyWidget. The EasyWidget website had just three widgets on it (dramatically fewer than the many hundreds in their existing line-up) and promised next-day delivery. That was it. For extra dramatic effect, we fabricated Google pages and sequenced them, so that, in the presentation, we could pretend to search for this “competitor” and then happen across their website. This was all very carefully stage managed.
When the time came to present our findings and our ideas, we told our client of the problem we encountered. We made up a story about some of their customers telling us about a new competitor. We opened up a browser for them to see and typed our search Easy Widgets into our fake Google page. When the EasyWidget page that we had faked appeared to load, the whole of our client’s global executive team stood in stunned silence, mouths wide open. The chief executive simply said, “That’s it. We’re finished. We can’t compete with these guys. They are going to wipe us out.”
We, of course, were thrilled. This was the response we wanted. He had validated the strength of the idea for us. However, as we were about to reveal the fact that it was all fabricated and that the idea, in fact, belonged to them, the marketing director stood up. Pointing to the EasyWidget website we had forged, he said, “I know these guys. There’s really nothing to worry about. I met them at a trade show, and they’re no real threat. They’re all show and no substance.” We were stunned. He obviously didn’t know them and had never met them, since we had faked the whole thing. In his effort to protect his professional pride, he couldn’t let his superiors believe that this was happening without his knowledge, so he lied.
We managed to recover gracefully, but we learned a valuable lesson about being in control of a meeting like this. You can shape the course of the meeting – but you can never truly control it.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.