Beyond The Conversation: Context-Fluid Experiences and Augmented Cognition

Have you ever felt like you were having a one-sided conversation with someone? It feels as if you are exerting much effort with minimal feedback or response in return.

When we use an application, we can think of this experience as a conversation between the user and the technology. Sometimes, it feels as if we are having that same one-sided conversation with the technology we are using. As modern people, we learn the ins and outs of the tech we are interacting with, from the information architecture to the layout of the UI elements. Because of this, we adapt to the technology. Just as we adapt to the technology, the technology should also adapt to us. This conversation should not be one-sided.

The metaphor of a “two-way conversation” isn’t new within the field of human-computer interaction; however, we shouldn’t take the metaphor at face value. Just think, when you are talking with a friend, the conversation you are having is most likely being affected by a specific state of affairs. The conversation is sensitive to a scenario. For example, the language, the cadence of speech, the volume, and other parameters may be more or less appropriate depending on the context of the conversation.

Context is KEY

As UX designers in a world with exponential advancements in sensing technology, we ought to have context at the top of our list of things to consider in any design process—especially if we are designing for a “context-fluid” experience.

A context-fluid experience is achieved when a person uses a product in a variety of scenarios and the actual experience of the product is heavily affected by the context of use. As designers, we are (or should be) aware of the importance of contextual design, such as how a UI might be presented differently to a person who is running compared to a person who is relaxing on a couch.

What if we take the idea of contextual design a few steps further? Context is not only defined by the time of day, activity, or physical location of the user. A very important component of context is the user’s psychological state. The context of taking a relaxing night drive to grab some ice cream is completely different than rushing to the hospital for an emergency in the middle of the night. How can we create truly context-sensitive systems for context-fluid experiences?  

Enter augmented cognition

The field of augmented cognition strives to manifest computer systems that can “sense” and interpret a user’s cognitive and physiological information, enabling the system to present information accordingly.

Just as humans have built machines to overcome our physical limitations, the field of augmented cognition aims to overcome our cognitive limitations within a human-computer environment. Our cognitive limitations lie within our inability to process massive amounts of information received from every direction (Wladawsky-Berger 2013). With consumer-focused augmented reality on the horizon, we can expect to be designing for not only AR but also for augmenting the human-computer experience by utilizing feedback loops and sensing technology.

Current sensing technologies

Cognitive sensing

For a technological system to adapt to a user’s current cognitive and physiological state, the system must be able to gather this information. A few methods of obtaining cognitive information from a user include functional magnetic resonance imaging (fMRI), magnetoencephalography (MEG), and positron emission tomography (PET) (Ayaz et al., 2010).

However, these methods need cumbersome equipment and are very restrictive to the user. These methods are also extremely expensive, making it difficult and impractical for use outside of a laboratory setting. A more practical method of acquiring cognitive information is by means of functional near infrared spectroscopy (fNIR). fNIR can be employed to monitor changes in oxygenated and deoxygenated hemoglobin at the cortex of the brain.

With the implementation of fNIR, it is now possible to create more practical, portable, obtainable, and relatively inexpensive monitoring systems. There are newer systems available such as the Artinis OctaMon, with a headband-like form factor. Artinis also produces an even smaller monitoring device that is simply an electrode, connecting to a small battery pack. Both of these systems can wirelessly transmit data for real-time monitoring. These new developments would make it seem like fNIR is a suitable method for acquiring cognitive data in controlled laboratory settings as well as mobile contexts.

That said, these systems need to become even more affordable and further miniaturized to be adopted outside of their niche market.  For the time being, a more practical means of acquiring psychophysiological data is necessary for use in a consumer setting.  

Physiological sensing

Measuring a user’s physiological state is an easier and less invasive process than measuring cognitive states. There is a plethora of wearables on the market today that collect biometric data such as motion, heart rate, skin temperature, perspiration, and more. The advantage of physiological sensing technologies is that they’ve already been widely adopted—think Fitbit, Apple watches, and even Polar heart rate monitors to use at the gym. Furthermore, these sensing methods can also be used to infer a user’s psychological state. For instance there are products on the market today that measure a user’s rate of breathing to infer mood.  

With that said, biometric data may only result in a high-level inference of context. For example, by utilizing data such as heart rate, perspiration, and rate of breathing, I still may not be able to discern if the user’s psychological state is that of distress or exuberance. With this data, I may only be able to discern between “calm” and “excited” psychological states. This level of granularity may not be fine enough to design truly context-fluid experiences, so further research in this area is warranted.

Bringing it all together now

Currently, there isn’t a very cost-effective, widely used method of easily discerning a user’s psychophysiological state. That said, as forward-thinking designers and developers, we should be anticipating the ability to acquire and make use of this psychophysiological information.

What we can do currently, however, is think about how to best make use of the available data acquisition methods to create context-sensitive applications for context-fluid experiences.

As designers, it is our job to continue to facilitate and improve the two-way conversation between our technology and its users.  Let’s work toward creating meaningful feedback loops between human and computer, thus optimizing the context-fluid experience.


Ayaz, H., Willems, B., Bunce, S., Shewokis, P. A., Izzetoglu, K., Hah, S., Deshmukh, A., Onaral, B. (2010). Cognitive Workload Assessment of Air Traffic Controllers Using Optical Brain Imaging Sensors. In T. Marek, W. Karwowski & V. Rice (Eds.), Advances in Understanding Human Performance: Neuroergonomics, Human Factors Design, and Special Populations (pp. 21-32): CRC Press, Taylor & Francis Group

Wladawsky-Berger, Irving (2013) “The Era of Cognitive Computing” July 01, 2013. Accessed on May 20, 2014 from

Creating the Persuasive Pattern Card Deck

One of our finest tasks as designers is to filter the abundance of choice into easily digestible bits. Creating great interfaces is as much about motivating, teasing, leading, and guiding users along—so that they experience value, faster—as it is to improve usability by removing friction. This requires an endeavor into product psychology and the art of designing with purpose and intent.

Stakeholders in design

All design has at least two stakeholders. Otherwise it is not design, but art.

  • The user. If we fail to acknowledge usability and user needs, no motivation or guidance can help make a product succeed.
  • The business (or the purpose and intent of the design). If we fail to acknowledge the business, or the change the design was intended to create, the design itself has no meaning. Design without intent will most likely also suffer lack of future sponsorship in the long run.

To cater to both sides of design, I started the journey of mapping and documenting useful psychological insights used by designers. Starting in 2010, the collection has now grown large and mature. Having already documented user interface (UI) design patterns at my site,, catering to usability and user needs, adding persuasive patterns to the site was the perfect addition to also cater to the business side of design.

Removing friction and introducing fun

Having documented useful psychological design principles, I was still struggling to put them to practice with my development teams. Reading up on scores of articles of somewhat complicated psychological concepts was an incomprehensible task for most team members.

I needed to remove friction and introduce fun.

The Persuasive Pattern card deck was created to aid designing with purpose and intent. It is a collection of 54 printed design patterns driven by psychology, presented in a manner easily referenced and used as a brainstorming tool. With a focus on human behavior, each card describes one psychological insight and suggests ways in which you can apply it to your product.

The idea and basic concept is not new. Both Stephen Anderson and Dan Lockton published similar decks back in 2010. Unfortunately, they are now both sold out, nor were they quite the same.

Behind the design

Designing the card decks was a long and winding road that took a little over nine months, ending in a product launch in the spring of 2016.

Although I’m well experienced in web design, I quickly knew my print design skills weren’t going to be enough to create a quality product. I quickly teamed up with a great Copenhagen local print designer, Daniel Prip Pedersen from Voke.

He was intrigued by the idea, but we quickly agreed that we needed to both validate the usefulness of the product and validate the market.

After a few weeks of work, I had transcribed the persuasive patterns documented at that my team and I deemed most useful into bite-size nuggets that would fit on printed playing cards. Daniel had narrowed down the first design style. We printed a small batch that we started using ourselves and sent to friends around Copenhagen, Denmark.

For months, I offered free workshops using the cards to friends, former co-workers, design schools, and universities in Copenhagen. After the first workshop, I wasn’t in doubt that the cards were going to make a useful and even great product. However, the execution of both the product and workshop facilitation needed refinement.

Validating the market

We allowed customers to pre-order the cards via PayPal. Our goal was to validate whether people would actually pay money for the product we had dreamed up.

At that point, we had no clue how much the production costs were going to be, nor a qualified guess of the final price. Once we confirmed demand, we would begin investigating the final production costs. To limit a potential loss, we decided to let the first 100 pre-orders go for $29—a price we later found was lower than our production costs.

To create a controlled test, we sent out a newsletter to 1,000 site subscribers before promoting the card deck elsewhere. With an open rate of 50%, the newsletter created 25 pre-orders. With a conversion rate of 5%, we considered the market validated.

Announcing the project

Earlier in 2015, Christian Perstl had invited me to speak on persuasive design at the 2015 Push Conference. It was the perfect opportunity to officially announce the project to the world. My talk on persuasive design patterns was accompanied with a full day workshop on how to use the cards.

Close-up photograph of two cards from the sample deck.
The beta deck included an “about” card.

Rigorous testing and continuous improvement of the cards continued throughout the late summer and early fall to make us ready. When time came for the conference, we were confident that we had a useful product as well as a workshop format that showcased the how to use them properly.

To market our cards and gain feedback, I passed around beta decks to conference participants in return for a promise to send back feedback and put the cards to use. Some of the best and most useful feedback came from these people.

Design iterations

While hopeful customers were pre-ordering, we were in full swing perfecting our product. We set up a continuous feedback loop, carrying out a test every 14 days. The test came in many forms: full-day workshops, 2-hour workshops, talks at local meetups, remote testing by universities, and sit downs with good friends.

Detail photo showing differences between beta and final cards.
The final card deck featured much better paper quality and had rounded corners.

We learned much about the usefulness of the concept, what cards worked better, what text worked better, and what exercises were deemed most rewarding. Based on feedback from around 80 people, we made several improvements.

  • Text was shortened, made more precise, and proofread several times.
  • 15 cards from the original persuasive deck were replaced by more suitable alternatives.
  • We created a pamphlet to go along with the final deck, outlining basic exercises and how to use the deck.
  • Paper quality was significantly increased from the beta deck to the final deck.
  • We tried out several coatings and materials, from plastic to paper and from glossy to matte.
  • Corners were rounded even more to make shuffling easier.
  • We added illustrations.
One of the first beta-test decks vs the final product.
One of the first beta-test decks vs the final product.


One point of feedback kept popping up again and again: “You should have an illustration for each card.” At first, we were reluctant, but after a few tests, we could see how a good illustration helped understanding and sparked ideas instantly. We kept the cards without illustrations for a few months, but finally caved in. We would add illustrations.

We quickly realized that crafting good looking and meaningful illustrations for psychological concepts is harder than you think. Daniel and I each kept a notepad to scribble down illustration ideas and met for several brainstorms. Some ideas were clearly better than others.

Sketches of potential illustrations for the cards.
Initial illustration ideas, jotted down in our notebooks

Many bad and some good sketching ideas later, we hired a freelancer to make them come to life. When we got the illustrations back from the first freelancer, it didn’t quite match the style we were looking for. We tried another. And another. We were pouring money down the drain.

Several illustrations of the same idea of scarcity.
It took several iterations of style and form to get the illustrations just right.

We finally decided to change our game plan. Instead of relying on our own illustration ideas, we knew we needed to bring in help of someone more qualified—someone who could challenge our thoughts and whose style could add to our product rather than bring it down. Our answer was a Danish artist, Annesofie Sandal, currently living in New York.

Although more expensive than a freelancer, she put a smile on our faces every time a new illustration ticked in our inboxes. Annesofie’s illustrations lifted the overall expression of the cards dramatically. We couldn’t have been happier with our choice.

UI pattern card deck

Through the testing-workshops, it came clear that applying persuasive patterns often led to the implementation of common UI patterns:

  • The Status-Quo Bias would lead to using the Good Defaults UI pattern
  • Limited Choice would lead to using Progressive Disclosure
  • Completion and Sequencing would lead to use of Wizards or the Steps Left UI pattern
  • Reduction would lead to use of the Forgiving Format UI pattern
  • Intentional Gaps would lead to use of the Fill in the Blanks UI pattern
  • Recognition over Recall would lead to use of Autocomplete and Calendar Pickers.

The list goes on.

To get truly great results readily applicable to web design from using the persuasive patterns card deck, we needed to create yet another deck: the UI pattern card deck. I have been documenting user interface patterns since 2007, so the content was almost ready.

Thankfully, UI patterns are easier to illustrate as they represent concrete functionality rather than complex psychological concepts.

Production of the cards

The production of the cards also turned out to be more complex than Daniel and I first realized. Both card decks have five parts: the card, the box, an instructional folder, a set of stickers to decorate your box, and a shipping container that would take all parts safely to our customers.

We had to deal with production in China, shipping to Denmark, customs, and initial batches with stained printing—which all helped to postpone the project a bit more.

Figuring out how to use the cards

Through years of practising UX, I’ve found that both persuasive patterns and UI patterns help establish a shared design vocabulary. By distilling complex concepts of both psychology and user interfaces into digestible bits, alternative solutions are easily communicated, help end feature debates, and spark new ideas.

It’s one thing to build upon a shared understanding of design concepts; it’s another to use them effectively. To help our future users get a head start, I set out to methodically test various workshop exercises. With inspiration from innovation powerhouses like IDEO and Frog Design, from various coaching frameworks, and from workshop participants during testing, these exercise tips produced great results again and again:

  • Define the behavioral goals of your desired outcome up front. This will ensure that you truly design with purpose and intent.
  • If you’re stuck, reversing the problem will help you redefine your problem space. If your goal is to get people to spam less, then exploring the question “What if we were to make people spam?” It will help discover alternative solutions, probably closer to the root cause of the actual problem.
  • Too often, the problem we’re trying to solve isn’t the real problem. Try solving the problem from the opposite perspective. If your problem is to get enough users, then consider what you would do if that wasn’t the case—if you truly did have enough users.

The final product

The final product finally shipped in June 2016, a couple of months late. We are stoked about the final result.

Photograph of the persuasive patterns deck stacked to the left of the UI patterns deck.
Photograph of both decks of cards fanned out on a flat surface.

Photograph showing both decks of cards in their storage boxes.

Did you already try them?

If you already got hold of a card deck of your own, we would love to hear how you have used it. We are still discovering new ways to best apply persuasive design and hope to refine our product further in the future. If you have experienced the power of persuasive design, we would love to hear from you to discover new ways to develop our card decks in the future. Drop me a line on twitter.

Here’s What May Sound Like a Crazy Idea

Build a command line option into your next user interface.

Some of you techies may be reading this and thinking, “Yes! I live in a command window all the time on my computer.” Well, I’m not really thinking about you as my target audience. I’m talking more about applications used by everyday people outside the IT industry.

Hear me out.

This concept first hit home for me some years back while working on a content management system. My team had built this shiny, new GUI with a backend database for managing user education content. The GUI was quite extensive, with a main screen plus many dialogs for maintaining the assets in the system. A number of teams across the company used the system quite effectively. But then we needed to on-board a new team habituated to an existing system that used a local source control system, an XML editor, and a command window. Commands were entered to do things like check out a topic, open a topic in the editor, and view source control history.

The new team began trialing our nifty GUI-based system, and we very soon heard complaints that the team’s productivity was going to take a big hit once they adopted the system. And for this team—who were always under the gun to get content updated and published—productivity was a huge concern.

It took me just a few minutes while sitting with a writer from the team to totally understand their concerns.

In the previous system, they could have a topic checked-out and open in the editor in seconds just by typing a single command. Using our GUI, the steps necessary to accomplish the same goal took quite a bit longer: They had to navigate a hierarchy tree to find the topic, followed by separate steps to check-out and open the topic in the editor.

Now you may be thinking that the GUI had to be simpler to use than remembering many sets of command syntax. But remember, we’re talking about folks that worked with their content hour after hour, every day. It was nothing for them to memorize the syntax for a set of commands since repetition leads to memorization.

I ended up getting approval to build a command line interface option to the system run from a Windows DOS command prompt. The set of commands started out small, focusing on core functionality. But the library grew significantly as team members started using it and liking it. They just kept begging for more! The GUI lived on of course, as it did offer the complete set of features for the system. But, it was amazing to see how popular the command line interface became with our users.


Long before GUIs became mainstream, command lines were king. But even after GUIs came along, some command line interfaces survived and are still alive and kicking today. One of the most prominent and heavily used applications that still rely on a robust command line interface is Sabre, the largest systems provider for airline bookings in North America.

If you’ve ever travelled by air in North America, you’ve probably been on the other side of the airline counter from a customer service representative using Sabre. Now think about it—was the person using a mouse and clicking around the screen? No, they were using the keyboard, typing away like crazy and being very productive in getting to the data and information they needed to help get you on your way.

Why does a command line interface work so well in the case of airline reservations? The reason is that the airline customer service representative uses a relatively small set of commands over and over again, to the point that they have memorized the syntax for these commands. With the command syntax memorized, it is faster and more efficient for the person to let their fingers fly over the keyboard to interface with the system.

Here is an example. The screen shot below shows the following command:


Screen grab of Sabre's text interface.
Screen grab of Sabre’s text interface.

If you break this down, it is an inquiry command to look for flights on the 12th of November from Cleveland (CLE) to Orlando (MCO). (I’m not positive what the 07A represents but I would venture a guess that it means to look for flights departing around 7AM.)

Now compare this with a GUI (see screen shot below) to accomplish the same inquiry. Think about how you must use the keyboard and mouse to interact with the UI elements presented in this dialog. There is no way you can interact with the GUI faster than typing at a command line.

Flight selection graphical user interface
Flight selection graphical user interface

To be clear, we are talking about how effective a command line is for a frequent system user, not the casual consumer looking for flight schedule information. The GUI is no doubt the best interface option for a consumer to find flights, but for the airline customer service rep that searches for flights hour after hour each day, the command line option is going to be a more efficient interface, hands down.


Another example involves a less technical user group: horse show secretaries. I’ve been involved with horse shows—managing, competing, and judging—for a number of years. Being one of those IT guys, I’m always interested in the software used by the show office. I’ve seen some systems that I thought were very non-intuitive for a novice user, but I attribute that to my critical eye when using any software product.

Here, as with airlines, there are scenarios that would be well-served with a command line option. For instance, one of the most common things a rider will do in the office is to add or drop a class.

A typical situation is that a rider will come into the show office and say something like, “My trainer told me to add class 126, and it starts in 20 minutes!” The show secretary will instruct the rider to fill out an “Add/Scratch” form: The rider writes down their horse’s entry number, the class number, and circles the word “Add.” Similarly, to drop a class they use the same form, supply the same information, but circle the word “Scratch.” The rider drops the form in a basket, heads out of the office, gets on their horse, and hopes the show secretary processes the request before the class starts.

Now, if the show secretary was not busy when the rider came in to add the class, she could have just done the work right away, but it is rarely the case that the secretary at a horse show is just sitting around looking for something to do.

If she is busy doing something else in the system, you can imagine there would be a number of steps to perform to close out the current dialogs in-use, then bring up the screen where a horse can be added to a class. But what if, with a keyboard shortcut, the show secretary could pop into a command line and simply type >add 57 126 and press the Enter key? In this case, the command would result in horse number 57 being added to class 126. A scratch could be just as simple >scr 57 126

Below is a screen sample that shows a command line option built into the GUI of a popular horse show management system (see lower-right section of the screen). Adding and scratching is a very common function executed by the show secretary, so memorizing the syntax for add or scratch would happen very quickly. With a command line option, regardless of where they are in the system, they could quickly drop to the command line and execute any number of common functions.

Screen grab of Windows GUI showing horses, riders, and classes.
Screen grab of Windows GUI showing horses, riders, and classes.

A key tenet of a command line option in an application is that the commands and their syntax must be simple and intuitive. In the above example, you are adding a horse, represented by a number, to a class, also represented by a number. So the syntax is very simple and easy to remember.

You really have to look for the right functionality to offer a command line option. Two basic questions can be asked:

  1. Is it a commonly used function?
  2. Are there a small number of data elements necessary to accomplish the task?

For example, here is a dialog (see below) to add a horse into a system. Clearly, this task would be best accomplished with a GUI since there are far too many data elements involved with getting a horse into the system. Memorizing the command syntax would be impossible.  Also, horses are typically added before a show starts so this function would be classified as non-common, especially once a show has started.

Screen grab of a GUI with many form fields for adding a horse.
Screen grab of a GUI with many form fields for adding a horse.

As I mentioned, I also judge horse shows and I built an application designed to be used by show jumping judges. I hadn’t thought about adding a command line option to my application, but then I really started thinking about some common tasks that would be excellent candidates for a command line. The judge is not only keeping track of results for each horse/rider, but may also be operating the timing equipment and may even be announcing over the PA system. That gives the judge little time to do anything that would distract them from their core responsibilities.

I’ve spent hours tuning the user interface in my application to be very intuitive and easy to use but this means that some functions will be buried on a screen that takes a couple steps to access when needed. So I started thinking. What if I had a command line always visible and quickly accessible where the judge could type in something like:

>view ss 175

This could quickly open the score sheet report for class 175 in a browser window. After thinking about it some more, I came up with 16 functions that made sense to offer as a command line option. All the functions have very simple syntax and helps the judge execute items quickly. Here is a screen shot of my judging application with the command line at the bottom of the screen.

Screen grab of the GUI for the score sheet for an individual horse.
Screen grab of the GUI for the score sheet for an individual horse.

Seems I’m not alone in my thinking here. For all intents and purposes, a command line has appeared atop the ribbon bar in Office 2016 apps. The Office team has named this the “Tell Me” feature. The feature is described on this blog post:

Tell Me is an entirely new way to find the commands you need. Just type what you want to do in the Tell Me box at the top of Word, PowerPoint, Excel, and Outlook, and you will get a set of results that let you take the desired action directly from within those results.

In any Office 2016 application, you press Alt-Q to get your cursor right in the Tell Me box. Once you use this new feature, you’ll see that it really is a command line on steroids, but it does serve the main purpose of providing quick access to certain functionality.

In conclusion, I hope this gets you thinking about the user interfaces you’ve designed in the past and ones that you’ll design in the future and ask yourself this question—is there some functionality where a command line option would be beneficial to your users?

10 Practical Tips for Increasing the Impact of Your Research Insights

User experience (UX) researchers tasked with improving customer-facing products face many challenges on a daily basis—perhaps none more daunting than translating their research insights into positive change. This article presents 10 tips I have learned over the course of my career to help UX researchers increase the impact of their research insights in applied settings. These tips are intended primarily for in-house research teams, but they may apply to consultancies as well.

1. It’s a long-term relationship, not a speed date.

For research insights to impact a specific product, the researcher must establish a deep connection with the product team. What is the context that the team is operating within? What are their constraints, challenges, and deadlines? What are immediate goals, and what objectives are longer-term? How is success measured by their superiors? Given those circumstances, what can you do to help them without adding to their workload? Above all, you want your product team to perceive you as a benefit rather than a hindrance. This is not to say that you cannot critique their work, but never lose sight of the their ultimate goal: to create products in a timely fashion that will drive business metrics when launched.

For example, suppose your product team is racing to launch the product by a specific deadline, and you discover a problem with the product during testing. In such situations, you should not immediately advocate that the launch be delayed. Instead, think about the best way to raise the issue (and to whom you should raise it) and frame the issue in terms of potential courses of action. Can the team reallocate resources to keep the current launch schedule? Can the problem be corrected in the next dot release of the product? Is the problem serious enough to warrant pushing back the launch schedule? Over the course of working with your team, you will have many opportunities to demonstrate empathy for their challenges. Doing so will build trust and help you become an integral member of the team.

2. Serve ‘ready to bake’ bread.

The best way to ensure that action will be taken to address your research insights is for someone else to take ownership. Researchers often view it as their responsibility to make specific recommendations from their research, but what really matters is that the insights lead to clear potential solutions. The solution doesn’t need to come from the researcher herself.

Instead of a recommendation that does not offer any unique value—for example, “Users were confused by X. My recommendation is to fix X”—a better strategy is to offer specific recommendations when they are not obvious and when you have confidence that they will add unique value to thinking about the problem.

Better still is something else entirely: Offer “ready to bake” bread.

In other words, present the problem in a way that clearly lends itself to a specific solution and let a product team member connect the final dots so that they consider it their idea and take ownership over it. In cooking parlance, give them bread that is basically already made but needs only a few more minutes in the oven. So, instead of giving them raw dough (raw data) or fully-baked bread (a specific solution that you explicitly offered), give them ready to bake bread. People are more likely to follow-through on something when it is their idea and everyone implicitly ascribes ownership of the idea to them.

One way to do this is to frame key research insights as “How might we?” questions to spur discussion. Doing so can effectively portray the researcher as a facilitator of collaboration rather than someone who provides heavy-handed mandates for the team.

For example, suppose users in a research study exhibited difficulty navigating to specific types of offerings. Instead of recommending that the team “Implement more top navigation menu options,” you can instead ask  “How might we convey the breadth of our offerings and provide quick access to different product categories?”

3. Know the whole story before writing the first chapter.

Researchers should strive to present their research insights in a clear, compelling, and elegant way. Instead of proceeding straight from raw notes to a Powerpoint presentation, synthesize the data and create an outline summarizing the main ideas and how best to convey them. Presentations that skip the important synthesis step can seem disjointed or disorganized and can lead to audience fatigue or lack of clarity about the most important points.

These best practices are not limited only to qualitative research, such as user visits or usability studies; they apply to quantitative research, such as surveys, as well. Common practice when presenting survey-based research is to devote one slide to data relevant to each survey question and present detailed information such as charts, graphs, statistical significance across numerous comparisons, and so on. However, a better practice is to first create an outline that summarizes the top 3 or 5 or 10 key points that you wish to convey to your audience based on the survey data as a whole.

4. Don’t lose the forest for the trees.

As difficult as it may be, researchers need to resist the temptation to share every interesting finding from a study. When a researcher presents findings, he is telling a story and needs to be mindful of tangents that detract from the overall message. So if you want to convince the audience of a few key themes, ask yourself if each point you are making ties back to one of those themes. If not, then perhaps another forum would be more appropriate to share it.

I tell researchers that there is a continuum with impact on one end and exhaustiveness on the other, and different researchers operate at different points on the continuum. In my opinion, it is best to land on the side of impact.

If you have one hour to present important insights to senior stakeholders, it is more important that those stakeholders leave the room with the key points to act upon. It is less important that they understand every subtle nuance of the data or that other stakeholders can find such nuances a year from now. I call the one-hour presentation “The Golden Hour.” Once those stakeholders leave the room, you may get another opportunity to convey the key points, but you’ve lost your best opportunity to make a lasting impact.

5. Don’t crawl across the finish line.

After presenting insights, researchers typically send an email that shares the deliverable with the immediate product team as well as with the entire product organization. This may seem like a minor, perfunctory step, but it is a very important factor in determining what happens next.

An effective announcement conveys the key takeaways in a clear and concise manner and serves as a catalyst to action. Frame the email in the context of the team and the project (e.g., If their overall goal is to increase engagement, frame it in that light.)

Or, if the product lead reframed your research in a specific (helpful) way, build on that. Once, in my experience, a project manager concluded from a research project about improving the map view of search results that the research instead underscored the need to improve the list view of search results. I built off of that in the announcement, both because it was provocative but also because everyone else in the room heard the comment as well—and I agreed with it.

And don’t lose sight of the basics. Have a clear and compelling title for your email that draws the reader in. You want to get other people interested in your research who may not have attended the presentation. Ask yourself which email you’d be more likely to open: One with a subject line of “Posted: Redemption Research” vs. “The Life of a Groupon: Eliminating Barriers to Redemption and Increasing Engagement”?

6. The end is only the beginning.

The research presentation is really the beginning of the journey rather than the end. You want to make it easy for your team to track your insights and take action to address them.

I’ve always been amazed at how dependent product managers and engineers are on tracking tools. I recall a time when I said “The one thing you need to remember is to do X” … to which they replied, “Ok, well then submit a ticket for that.”

I thought to myself, “It’s only one issue,” but now I realize that PMs and engineers are constantly flooded with problems to fix and it can be difficult for them to separate small issues from big ones. They’re all bugs—just with different levels of priority and required effort.

I’ve found that a shared Google spreadsheet is an effective way to track such issues. Each issue or insight is given a row in the sheet and is assigned an owner who is responsible for the status of the issue and next steps. That said, work with whatever tools your team uses. The last thing most product managers and engineers want to do is learn how to use another tool.

Another important consideration is to ensure that you have a clear path forward right from the outset for ensuring your research has impact. Establish a plan with the product team before you conduct research that makes explicit how and when product improvements will be made based on the insights. You may find that product teams are enthusiastic about research, only to discover after completing the research that they had not thought about how they would act on the findings. Prior to kicking off the research, establish a timeframe for when you’ll present your findings, when changes will be made, and who will be responsible for making them.

7. Know your allies…and how to find new ones.

Your immediate product team is obviously your best bet for addressing the issues surfaced in your research. That said, product organizations typically have many interdependencies, so there are probably other product teams who have some stake in what happens to your product.

Reach out to those product teams to share your research and determine if your research can be reframed to be more directly relevant to them. For example, one team may be focused on new user acquisition whereas another team may be focused on increasing engagement. Some of your findings may apply to both goals, so reframing a few key points can open up new audiences (and doors) for your insights.

To make this possible, know the product leaders in your organization, who they are, what they do, and what their goals are. You may find that they value your research and might even be willing to evangelize it across the organization.

8. Don’t give them what they want.

Teams often don’t know what they need, so they may say they want you to conduct a specific research methodology or present the data in a specific way.

Rather than reactively giving them what they want, think about what they need. Echo back your interpretation of what they’re asking for or what they’re trying to accomplish. For example, “So what I’m hearing you say is that you want to investigate whether users understand how to filter search results and whether we’re offering the right set of filters. Is that correct?” This will enable you to focus on the right methodologies to get the answers they need.

While your initial resistance to carrying out their demands may create friction in the short-term, it will establish your credibility and influence with the team in the long-term.

9. It’s not about the VP.

A researcher working at another company once contacted me looking for advice. She had recently completed a research project but she was having difficulty getting the product team to take action. She asked me for any tips about how she could get the research in front of the vice president leading the product area. As she put it, “If we can just get it in front of the VP, things will happen.”

In most corporate environments, executives don’t want to hear about problems; they want choices. It is up to the researcher to convince the PM and cross-functional team of the issues at hand and lead the charge to create potential solutions. If there are alternative solutions that the team cannot agree on, then the VP can make that decision.

If the cross-functional team is not interested in working with you to create solutions, then you need to re-evaluate if the problem you are trying to solve warrants team resources relative to other team priorities and/or if you have clearly and convincingly presented the problem.

Does the team even agree that it is a problem? Have you leveraged other data sources to make a more convincing argument?

10. Be your brand.

Your work is your brand. You want audiences to know that when you conduct research it will be high quality, and that when you present, your presentations will be engaging. As one PM told me recently, “You put a lot of love into that presentation.” He wasn’t talking about fancy graphics or illustrations but rather that I had clearly given a lot of thought as to the important insights and how I should best present them so that they were clear, concise, and well-substantiated.

Of course, there are situations where you cannot make a masterpiece of a presentation, and you shouldn’t always try. But remember that your brand stays with you, even when you leave your current company.

Beyond the quality of your work, you want to be thought of as someone who helps product teams progress toward their goals. You are someone who is there to help the team succeed, not slow them down, and you’re mindful of the teams’ constraints, deadlines, and challenges. You’re not just there to point out problems but to create and drive solutions.


Turning research insights into positive action is a combination of what you do but also what you are able to empower others to do. Knowing your audience and bringing the right mindset to the table can go a long way to making an impact in your organization.

Book in Brief: Designing Interface Animation

Editors’ note: We’re introducing a “Book in Brief” feature here on Boxes and Arrows. We’ll publish an excerpt, up to 500 words, of your book. The catch is that we’ll only publicize one book a month; first come, first serve. Other rules will certainly occur to us over time. Hit us up at idea at

Val Head kicks off August with an excerpt from chapter four of Rosenfeld Media’s newest, Designing Interface Animation: Meaningful Motion for User Experience.

Using Animation to Orient and Give Context

Book cover art

Animation has the power to suggest space and movement in ways that none of your other design tools really can. This makes it especially useful for helping to communicate the lay of the land in your screen-based interfaces through visual hints and special suggestions. It also has the power to suggest depth and space, two things we encounter regularly in the physical world but are often difficult to replicate on-screen.

Motion can be used to suggest boundaries, layers, and hint at what lies beyond the edges of what’s visible on-screen. Even a small visual clue can make understanding the landscape of an interface easier to understand at a glance, saving time and effort to explain which objects are located where. Think of it like a mime drawing the outline of an invisible door. With one gesture, the entire audi­ence knows exactly where the imaginary door is and why the mime can’t walk through it, even though none of them can see it. A shared understanding has been created between the audience and the mime. Motion in an interface can accomplish the same results.

Create a mental model of what’s out of view

When you’re trying to fit a large amount of content into a small amount of space, it gets really hard to fit everything on-screen. Actu­ally, it’s impossible. If you’ve ever worked on a responsive design or anything that considers the smallest viewport sizes, you know that fact well. Even when you can fit everything on-screen at once, it’s rarely an ideal solution for the design for the experience.

Patterns like off-screen navigation or interfaces that exist in layers—some stacked behind or in front of what’s currently in view—have emerged to help fit a lot of information into a small space in a mean­ingful way. Using animation to transition between layers or bring off-screen elements into view helps reinforce the spatial relationships of the interface for your users.

Designing Interface Animation: Meaningful Motion for User Experience