Context matters

Written by: Maciej Płonka

What makes a marketing e-mail or newsletter efficient? One can judge, for instance, by the number of users that opened the message or clicked on a specified element representing primary action, such as a product link or button.

Those indicators measure user engagement precisely; however, they are limited to the last phase of interaction with e-mail or newsletter. The act of clicking certain element in a marketing e-mail is a result of a longer process of identifying, assimilating, and analyzing its content. It is in those three steps that the decision is made to take action or not, and it is those three steps that are not analyzed or included in standard efficiency measurement, such as CTR or open-rate.

Therefore, click-through-rate or open-rate measures only completed processes, not taking into account those interrupted. Moreover, those parameters do not inform us about “why” a certain user decided to click or abandon the message.


One way to understand what is happening in users’ minds is to observe what they really see, which cannot be done using the traditional methods of e-mail research. Instead, we used eye tracking on a desktop computer to record the person’s gaze while looking at the e-mail message, checking which objects they looked at, for how long, and which elements, among the whole field of the vision, attracted their attention the most.

To check what kind of impact some of the characteristics of e-mails have on users, some of the stimuli were transformed by our team. For instance, we modified location of logo and the calls-to-action, changed size of prices, or flopped photos change the direction the person in the photo is facing.

Each of the stimuli used in the study had two versions–an original and a modified one. Each version was seen by 27 participants. All of the heat maps in the report are derived from the averaging of 10 second long scan paths of 27 subjects.

Observations: Testing known principles and their variations

Our different observations confirm some of the generally known design principles, such as users’ deep-rooted dislike of homogenous blocks of text.

At the same time, some of our hypotheses were disproved. For instance, reducing the length of introductory text did not result in an increased number of users reading it. In fact, introductory text was so rarely read that a general recommendation from our research is to remove it all together in favor of items that really matter.

Text and reading

Learning how to read and gaining experience in this activity shapes our perception since early childhood. In our (Western) culture, we read from left to right and from top to bottom. This becomes a strong habit and this strategy of scanning a visual stimulus is executed automatically, even if the viewed stimulus does not contain text.1

What is more, readers on the web are very selective.2 They constantly search for valuable content, but when the required amount of effort increases, their motivation plummets. Below, we describe further and illustrate those phenomena with the examples from our study.

Blocks of text

It may sound like a truism, but it is always good to have in mind that a homogenous block of text is not a good way to communicate with the Internet users.2 One can often observe in eyetracking studies that users tend to skip this kind of content, without making even the slightest attempt to read it.

Fortunately, there are some tips and tricks which can make the text more attractive to the user’s eye. First, formatting which includes clearly distinguishable headlines and leads often results in a phenomenon called F-pattern.

Fig. 1: A heat map showing an F-pattern


Readers have a strong tendency to scan headlines briefly, and they usually start to read from the top of the page. Their motivation to focus their attention on a written content decreases gradually, so you may expect that the first few headlines (counting from the top) will be read, and that the lower the headline is located, the less attention it will get.

Introduction text in an e-mail message

Reading requires time and effort, and the recipients of a newsletter want to quickly get exactly the information they are interested in (which usually means the special offers). It did not surprise us that introductory text in a newsletter would be ignored most of the time.3

But what to include in the marketing message instead of introductory blah-blah text? The answer seems obvious–more valuable content, such as the products we want to present.

Our study confirmed that hypothesis: After cutting most of the introductory text out, the amount of attention focused on it did not change much. On the other hand, the products presented in the message benefited greatly in terms of attracting users’ gaze.

Fig. 2: Scan paths. Left, without introductory text. Right, with introductory text.
Fig. 2: Scan paths. Left, without introductory text. Right, with introductory text

Properties of numbers

The next thing we wanted to focus on was if numbers caught a human’s eye. Nielsen4 suggested that numbers written as numerals are eye-catching, whereas numbers written with letters are not, because they are indistinguishable from an ordinary piece of text.

Fig. 3: Heat maps. Left, the original version with large numbers. Right, the modified version, with downsized prices.
Fig. 3: Heat maps. Left, the original version with large numbers. Right, the modified version, with downsized prices

We studied how long the participants focused their gaze on numbers, depending on their size. The difference between small and large digits turned out to be statistically significant. The average difference between small and large number approximated 200 and 400 ms for both prices depicted in the stimulus. From the psychophysiological perspective, this is a long time. The longer we fixate on an object, the deeper the processing and understanding of the visual information.5

Communication through images

Pictures: What’s worth it, and what’s not

One of the widely known phenomena which can be observed in eyetracking and usability studies is so-called banner blindness. In short, web users tend to act as if they were blind to advertisements or other types of redundant information, which can only distract them from completing the task. This adaptive mechanism applies as well to stock photos and to pictures which do not present the real products or people. Pictures without informational value may even pull the viewers’ attention away from the valuable content because they may be easily classified as an advertisement, which is usually neither informative nor relevant.

Directing users’ attention by faces

Some types of pictorial stimuli are almost always classified as important. One of them is certainly a human face. We are social animals, so we are perfectly wired to automatically read the subtle social cues, for example those connected with decoding where the attention of another human being is directed at the moment.

Fig. 4: Scan path
Fig. 4: Scan path

And example of how this reflexive mechanism works can bee seen on the picture above. The participant automatically followed the gaze of the model right after noticing her face.

In the original version of this newsletter the model looked straight forward. We have created the modified version in which the model is looking at the logo. We tested both versions with our participants, and then we examined whether there is a significant difference in the amount of time the participants fixated on the logo. In the modified version, the average time of focused gaze on the logo was significantly longer.

Fig. 5: Heat maps. Left, the original version. Right, the modified version, with gaze direction diverted
Fig. 5: Heat maps. Left, the original version. Right, the modified version, with gaze direction diverted


Our observations and recommendations are rooted in a number of studies focused on what recipients do really see while looking at advertisements in email campaigns. Some of the effects repeated in our 2011 and 2013 studies; some of them were also confirmed in studies on the perception of the e-mails and newsletters carried out by other teams.

But we should not forget that those are general laws, which, however, in particular creation may be not fulfilled due to various mitigating factors, such as the content of the e-mail, its size, and the level of the audience engagement.


1Ziming Liu, (2005) “Reading behavior in the digital environment: Changes in reading behavior over the past ten years”, Journal of Documentation, Vol. 61 Iss: 6, pp.700 – 712

2 Nielsen, J., (1997), How Users Read on the Web, Retrieved 15 June, 2013, from

3 Nielsen, J., (2007), Blah-Blah Text: Keep, Cut or Kill? Retrieved 15 June, 2013,rom Ros Hodgekiss, (2011),

Email usability: The science of keeping it short and sweet, Retrieved 15 June, 2013, from­-sweet/ ]

4 Nielsen, J., (2007), Show Numbers as Numerals When Writing for Online Readers, Retrieved 15 June, 2013, from

5 Poole, A., and Ball, L. J. Eye tracking in human-computer interaction and usability research., Encyclopedia of human computer interaction. Idea Group, Pennsylvania, 2005, 211-219.

Going Beyond “Yes – and…”

Written by: Amy Marquez

My first experience in improvisational comedy was in 1989. I was a freshman at Texas A&M University. Some of the students in the theater department decided to get an improv troupe started and somehow talked me into joining them.

In the beginning, I was petrified to perform without a script. Looking back now, I can see just how much improv has taught me and how it informs the decisions I make when working with a project team to create a cohesive user experience.

There are a multitude of “rules” to improv. The one most people are familiar with is the rule of “Yes – and.” The principle behind “Yes – and” is that for a story to be successfully crafted, all players involved must agree on the premise. So if a fellow actor points at you and says “your face is green,” you accept that and move the scene forward with a green face.

What we don’t often hear about are all of the other rules of improv that can be pulled into daily work as an experience designer. What happens after you’ve said yes? What comes after the “and”?

I’ve combed through my books and through various improv websites to pull out rules I started taking for granted about 20 years ago and was surprised at just how much the regular practice of these rules has shaped my perspective when creating designs with a team or client.

Add new information

The follow on rule to “Yes – and” is add new information. Have a plan when you say “and.” You can’t move the scene forward without it. And there will be times that saying yes is very difficult. What the team or client wants is not always what you will feel is the best aesthetic, so delicately phrasing your yes’s is important.

So, if a stakeholder is telling you they want a monochromatic blue palette for their website, you answer “That sounds great – and we can use complementary color accents, like yellows or oranges, to highlight important calls to action.”

Don’t negate or deny

The opposite of “Yes – and” is “No – but.” When a project kicks off, don’t start with what the system limitations are, don’t start with the baggage of knowing that the experience needed will break corporate standard rules.

Negating is also referred to as blocking. Take time to think when your first reaction is to deny, negate, or block someone else’s ideas.

If your product owner says “we want to add social media buttons to this,” don’t tell her that’s a dumb idea. That’s a knee jerk reaction, with the operative word being jerk. Explore the idea. Think about what benefits social sharing may bring to the customer and the business.

Always check your impulses

Checking your impulses isn’t limited to cases where you want to negate or deny something. You also have to check your impulses to see if what you’re thinking aligns with the product goals. If you have design principles set out for your project, measure your impulse against them to see if it aligns with those principles.

You may have a fantastic idea, but if it’s not part of the goals of the project and doesn’t align with scenarios, personas or design principles, table that thought. Write it down for a future project where it may be a great asset.

Look beyond the words

If you’re designing experiences, you have either become or are becoming a keen observer of human interactions. Look at physical cues of people you’re meeting with. Is someone uncomfortable or unusually silent? Maybe they aren’t good at speaking out in a group setting, but if you chat with them afterwards they may offer you a wealth of insight you would have otherwise missed out on.

The same goes with usability testing. Don’t just look at how easily or efficiently the participant is getting through your flow, look at their body language. Look at their forehead – is the brow furrowed? Are the eyebrows raised? Are they tapping their feet nervously? Or are their shoulders relaxed?

Aside from just the physical, there may be underlying motivations for the way people are behaving. Try to get to the heart of the meaning behind their words and actions.

Never underestimate or condescend to your audience

Underestimating your audience is a diva move to make. That doesn’t mean you should throw around words like “affordance,” or refer to “Fitt’s law” with people who aren’t design professionals, but it does mean that you need to be careful not to talk down to them. Talking down to someone tells them that you think you’re better than they are. And guess what? You’re not.

We all have roles to play in our daily work, and one is not necessarily more important or more clever than the other. Give your “audience” respect, and you will get respect in return.

Work to the top of your intelligence

This is the flip side of not underestimating your audience. Don’t underestimate yourself. Working to the top of your intelligence means not taking the easy way out. If someone says “but that’s how we’ve always done it,” challenge the status quo.

Push yourself every day to do something better, to learn. Keep up with the blogs and articles about UX practice and theory. Engage your colleagues in meaningful, actionable discussions about the work you’re doing.

Trust your partners

Every project you work on comes with partners: front end developers, project managers, stakeholders, information architects. Trust them to do their jobs. They got where they are for a reason.

In return, you should expect them to trust you to do your job. If they don’t, then that’s an important conversation to have with your partners. Help them understand why they need to trust you.

And most important of all, trust yourself. Your experience and your expertise led you to where you are today. You need to trust in your own talent and skill. Because if you don’t trust in yourself, you can’t possibly expect others to trust you.

Do try this at home (or work)

With every new venture you have to start somewhere. I was petrified as a teenager trying improv for the first time. I can remember it very clearly. But now improv is second nature to me. Public speaking is not an issue. I was never a shy or quiet person, and improv has given me more confidence and tools to work with.

That didn’t happen over night. It happened with repeated practice. Take these rules and try putting them into practice in your daily routine. Three months from now, see what changes this has brought to your projects, clients and project teams. You’ll be pleasantly surprised.

The Shallow Dive

Written by: Mark Richman

At a recent job, my department faced large budget cuts. When the dust had cleared, I found I had become a UX group of one. This didn’t come with a corresponding slowdown in work – in fact, following a major rewrite of our call center application, our department was already struggling to keep pace with a backload of business initiatives. Cuts slashed our BAs, our development group, and our QAs, yet everyone remaining was being asked to speed up.

I needed to find a way to work faster and smarter and decided to address inefficiencies in my design process. As I did so, a couple of key concerns stood out for me:

Get critical design decisions made as early as possible: To go from an exploratory design to a final solution, numerous decisions needed to be made by the client. To elicit those decisions, I needed to give the client wireframes or prototypes that provided a clear context. The earlier these decisions were made, the faster I could complete the detailed design.

Reduce the client’s dependence on high-fidelity wireframes: I had routinely been asked to make painstaking changes to an early set of high-fidelity wireframes, only to discard those pages as we moved towards a final solution. Frustrating? You bet. Instead, I wanted to drive the design in the manner that Bill Buxton described in Sketching User Experiences: The fidelity of a prototype or wireframe should reflect its stage of refinement. This meant introducing low-fidelity items into the process.

Diving In

The concerns above dovetailed nicely, and to address them I formalized an early design stage I call The Shallow Dive.

Instead of attempting to achieve a final design solution, The Shallow Dive is an early UX analysis phase that is solely concerned with identifying design issues. The aim of this phase is to identify key elements and decisions that will influence the detailed design of the project.

Rough draft wireframe
A first, rough draft of wireframes is refined with the development group and then discussed with the client.

To start, the BA and I do a first-wave analysis of all of the screens and workflows that might be affected by the project. Then I create a first, rough draft of wireframes. We then refine these with the development group.  After discussing the wireframes with the client, the resulting decisions are carried forward into the detailed design.

The types of things that we look for might include:

  • What is the optimal hierarchy on each page?
  • What information is required to be carried from step-to-step of a multi-step flow?
  • What options need to be presented immediately, and what can be hidden?
  • Can we remove some non-critical information from the initial display?

Goal #1

The sole goal of The Shallow Dive is to speed the transition into a detailed design phase.

A number of things could slow this transition down. Lack of clarity in requirements may confuse translation into screen designs. Requirements that look good on paper may suffer when visualized. Without proper insight into the context of use, direction and priorities may be unclear.

To this end, within The Shallow Dive we also:

  • Identify and resolve key decision points affecting the detailed design.
  • Resolve any ambiguities encountered when the requirements are translated into screen designs.
  • Identify and document any usability issues that may appear.
  • Identify any user research needs.


This approach has worked well. It gets the client’s project manager into the spirit of iterative design right away. Since the first set of wireframes is deliberately rough and clearly emphasizes one or more design issues, the PM ‘gets it’ and understands the process of chipping away towards an ultimate goal. The PM shows those rough wireframes to their management, who become acclimated to using them to address a few key points, rather than solve all aspects of the project. If suggestions are made about an item that I don’t think is important at the present time, I make a note to ‘fix it in the mix’ and address it in the final design phase.

The Shallow Dive has some key advantages. Critical decisions are made earlier in the project, reducing the need for multiple iterations of detailed wireframes. This eliminates wasted time and shortens the design effort. Targeting the entire project allows us to present a comprehensive list of questions to the client at once, allowing for more effective use of the valuable face time with management. As well, the client gets experience in evaluating rough designs, making it easier to share ideas.

But most of all, the client accepts that design takes place in stages and doesn’t demand a comprehensive solution from the get-go. And that, my friends, is a little slice of heaven.

Site Speed and Usability

Written by: Toby Biddle

Did you know usability tests have shown that the maximum number of seconds a user is willing to wait, on average, before abandoning a web page, is 8.6?

If that number surprises you, it should. The study took place in 1994.

The bar is exponentially higher now for people involved in website user experience design and development when it comes to load speed. Here’s a quick look at the state of affairs.

Slow speeds are a real usability challenge. According to software and monitoring experts at Gomez and Akamai, most users (up to 73%) have encountered a site that was too slow, crashed, froze or otherwise didn’t perform.

Your visitors’ expectations are high. A sizeable 47% of consumers expect a page to load in 2 seconds or less, and 40% of people will abandon a page that takes more than 3 seconds to load.

Slow load speed can be a costly challenge. These sources estimate that a 1-second delay can lead to a 7% drop in conversions, meaning that an e-commerce site doing $100k daily would experience a $2.5M loss in sales on an annual basis tied to 1 second in load speed.

If you’re curious about the impact of load speed on conversions, and want to learn about users’ expectations for mobile browsing vs. desktop browsing, KISSmetrics has built a stellar infographic on the topic.

Mozilla ran a study to test a similar concept: what happens if the development team combines files and rearranges the source to make the Firefox home page load 2.2 seconds faster? You guessed it. Conversions increased dramatically. Firefox saw a 15.4% lift in browser downloads.

If all of this weren’t compelling enough, you should also know that organic search results can be negatively affected by slow load times. If you run search engine advertising, you’re familiar with quality score—Google’s determination of how ‘relevant’ your ad is—and you know it impacts the per-click price of your ad. Landing page speed is part of the quality score determination, too.

You get the point. The need for speed is great, and there’s a lot at stake.

What can you do to improve load speed?

There are a lot of solutions for improving how quickly your site loads. Some are simple and quick to implement, and others are tougher to tackle. Here’s a strategy to start moving your site in the right direction.

Run speed tests. Use Google’s PageSpeed Insights tool. See what easy-to-implement suggestions it spits out and heed the recommendations.

Then run your site through the Pingdom speed tool. How many requests have to be done to load your site? Are there tracking scripts that might be outdated or aren’t needed anymore? Can you consolidate any of the other requests?

Knock out the low-hanging fruit changes. Some of the recommendations you might receive include things like:

● Minimize HTTP requests.
● Resize and optimize images.
● Optimize multimedia.
● Convert JavaScript behavior to CSS.
● Use server-side sniffing.
● Optimize JavaScript for execution speed and file size.
● Convert table layout to CSS layout.
● Replace inline style with CSS rules.
● Minimize initial display time.
● Load JavaScript wisely.
● Create a dedicated landing page for mobile.

Install plugins to simplify your process. Your content management system might have plugins available that’ll make your life easier. For example, here are a couple of popular WordPress plugins that help with load speed in various ways.

W3totalcache improves site performance by improving caching with respect to the browser, page, objects, database and more. To learn more about this, you can read up on configuring the W3 total cache plugin.

WP—Especially if you’re a blogger, you probably use plenty of images, and images can take considerable time to load. This plugin reduces image file sizes and improves performance by compressing the files.

WP Optimize—This plugin allows you to clean up and optimize your database, especially if you’re a blogger with significant archives.

When in doubt, simplicity is key. Don’t be afraid to gut components that increase load time and A/B test simpler versions of the page against their predecessors. You may be surprised at the impact of a faster loading page, even if it suddenly has less of the stuff you once considered critical.

Toby Biddle is a seasoned website usability expert and CEO of Loop11, a tool for unmoderated online user testing.

Footnotes and sources

1 Nielsen, J. (1994). Usability engineering. London: Morgan Kaufmann.
2 You can learn about the Mozilla site speed case study here.

Interviewing Executives and SME Stakeholders

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Senior executives

Ideally, there is at least one executive involved who has cross-functional authority and can balance the perspectives of both marketing and engineering; you need this person to make critical decisions, such as what’s worth waiting a little longer for. These are usually the most critical stakeholder interviews, because the way other team members approach product development depends on the views of the people at the top.

It can be difficult to get on a senior executive’s schedule, particularly if the executives regard the product’s design as a secondary concern. If they seem reluctant to spend the time, point out the kinds of strategic decisions that will be made in the course of the design work. However, most executives are more willing to spend this kind of time than people expect.

The concerns of senior executives may include any of the concerns mentioned above for marketing, sales, or engineering, as well as a common concern that they can’t get their subordinates to “see the big picture.”

What do we need to know that you don’t think other members of your team have said?

Senior executives often have a vision or perspective that others in the organization don’t. If they’ve shared that vision much at all, you will have heard it already from multiple people, but some executives communicate about their vision less than they think they do.

We know that both timeline and functionality are important, but if you had to choose one, what would it be?

When there seems to be some controversy about schedule, it’s usually because senior executives are asking to their teams to make omelettes without breaking any eggs. Mention the controversy, then ask what timeline they want you to design for and whether they would rather go to market with an incomplete product or delay shipment to get a product that meets more user needs. (Some designers frame this as “do it fast or do it right,” but it’s best to suspend this kind of judgment; sometimes, doing it “right” means shipping at a certain time to get critical revenue in the door, so tradeoffs have to be made.)

Subject matter experts

If you are working on a consumer product or a business product that involves common work or life activities, you probably won’t need domain experts to help you understand what you see in your research. For products in complex industries, though, subject matter experts (SMEs) are incredibly helpful to have around—so helpful that you might want to hire a consultant to spend a few hours here and there, if there is no expert already on the product team. Even in-house designers with a lot of experience working on certain products can benefit from the perspective of people with deep industry expertise, though they may be able to skip some of the following questions. In-house SMEs are usually part of a product management or professional services group.

A subject matter expert isn’t just someone who was a user (or did a similar job) once upon a time—it’s someone who has broad and deep industry experience and who understands industry best (and worst) practices. If your product overlaps a couple of disciplines, it’s best to have an SME in each; for example, when designing a device that delivers intravenous medication to patients in a hospital, we found it helpful to have the perspectives of both a pharmacy expert, who had a thorough understanding of the drugs, and a nursing expert, who had a thorough understanding of clinical practice.

Beware of getting presumed SMEs who are a little outside their expertise, though—for example, a surgeon who spends his time in the operating room is not an expert in how nurses do their jobs on the hospital ward.

Unless they’ve worked with you before, SMEs will be more concerned than anyone else that you won’t be able to understand their incredibly complex world, since it took them many years to get where they are. They usually wind up surprised at how quickly immersion in the usage environment can educate the design team. However, it’s important to be clear that good research techniques will let you develop a working vocabulary and high-level understanding very quickly, but you will be absolutely reliant on the SMEs for their detailed knowledge.

Spend a couple of hours with SMEs before the user interviews to get some background. Get definitions of terms, ask about best and worst practices, common processes, and regulations. If you’re talking about processes, ask the SME to diagram them on the whiteboard or do this yourself, using your sketches as a discussion tool.

Specific topics will vary by domain, but here are some typical topics to cover with SMEs:

What are the typical demographics and skills of potential users, and how much do these vary?

This information is handy for planning your interview sample, as well as for assessing how typical your actual interviewees seem to be in these respects.

What distinctions in user roles and tasks would you expect us to see?

A SME may be able to tell you about likely differences, such as tasks that vary based on seniority or skill levels that differ with geography. They probably won’t be able to point out all of those factors that make people behave differently, but they should at least be able to give you enough background to help determine how large an interview sample you need.

What sorts of workflows or practices do you think we’ll be seeing in the field?

Some SMEs will describe only the best practices in their industry, while others are very good at pointing out where reality tends to deviate from what people are supposed to do. This kind of discussion is a great way to think about topics you’ll want to explore in user interviews. However, avoid getting into tremendous detail or spending more than an hour or so on this, because you will still want to look at user behavior from a fresh point of view. A certain amount of ignorance helps you ask the naïve questions that can lead to important insights.

Other product team members

In theory, some organizations place QA and support on a par with marketing, sales, and development, but in practice, these organizations seldom have much influence over product direction. However, they may have a variety of useful insights, and at a minimum, they will be able to answer two important questions.

An experienced QA manager can often tell you how solid the engineering team is and can point out process holes that are currently leading to problems. The support or customer service team can tell you where users are most often encountering problems today, whether this is based on tech support calls for software or common failures for hardware—either could mean a flaw in the current design. In some companies, there are other groups that can provide useful information, as well, such as the training staff or technical writers, who may be able to identify where users most often get confused with the current products. Regulatory experts are also indispensable for medical products.

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.