davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Fast Path to a Great UX - Increased Exposure Hours (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Is that even respected? Retrospectively? What a shAItshow…
  https://neil-clarke.com/block-the-bots-that-feed-ai-models-by-scraping-your-website/ -->
<meta name="robots" content="noai, noimageai">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
    function toggleTheme(themeName) {
        document.documentElement.classList.toggle(
            'forced-dark',
            themeName === 'dark'
        )
        document.documentElement.classList.toggle(
            'forced-light',
            themeName === 'light'
        )
    }
    const selectedTheme = localStorage.getItem('theme')
    if (selectedTheme !== 'undefined') {
        toggleTheme(selectedTheme)
    }
</script>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://articles.uie.com/user_exposure_hours/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
  <header>
    <h1>Fast Path to a Great UX - Increased Exposure Hours</h1>
  </header>
  <nav>
    <p class="center">
      <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
      <a href="https://articles.uie.com/user_exposure_hours/" title="Lien vers le contenu original">Source originale</a>
    </p>
  </nav>
  <hr>
  <p>
    As we’ve been researching what design teams need to do to create great user experiences, we’ve stumbled across an interesting finding. It’s the closest thing we’ve found to a silver bullet when it comes to reliably improving the designs teams produce. This solution is so simple that we didn’t believe it at first. After all, if it was this easy, why isn’t everyone already doing it?
</p>
<p>
    To make sure, we’ve spent the last few years working directly with teams, showing them what we found and helping them do it themselves. By golly, it actually worked. We were stunned.
</p>
<p>
    The solution? Exposure hours. The number of hours each team member is exposed directly to real users interacting with the team’s designs or the team’s competitor’s designs. There is a direct correlation between this exposure and the improvements we see in the designs that team produces.
</p>
<h2>
    It Makes Perfect Sense: Watch Your Users<br>
</h2>
<p>
    For more than 20 years, we’ve known that teams spending time watching users, can see improvements. Yet we still see many teams with regular user research programs that produce complicated, unusable products. We couldn’t understand why, until now.
</p>
<p>
    Each team member has to be exposed directly to the users themselves. Teams that have dedicated user research professionals, who watch the users, then in turn, report the results through documents or videos, don’t deliver the same benefits. It’s from the direct exposure to the users that we see the improvements in the design.
</p>
<p>
    Over the years, there has been plenty of debate over how many participants are enough for a study. It turns out we were looking in the wrong direction. When you focus on the hours of exposure, the number of participants disappears as an important discussion. We found 2 hours of direct exposure with one participant could be as valuable (if not more valuable) than eight participants at 15-minutes each. The two hours with that one participant, seeing the detailed subtleties and nuances of their interactions with the design, can drive a tremendous amount of actionable value to the team, when done well.
</p>
<h2>
    First Forays: Field Visits<br>
</h2>
<p>
    As we watched different teams go through this process, we started to notice some repeatable patterns. For example, many teams spent little time watching their users. Often these teams had successful, profitable products that had evolved over many years into very complicated designs, chock full of features that users found hard to find and often frustrating to use.
</p>
<p>
    Before they began watching users, the teams would frequently find themselves at odds in meetings. They knew that the product was getting more complex, but nobody had any real information about how the product was being used. Stakeholders would ask for features without giving any useful details to the team to implement. An attitude of “Let’s build it, and if we get it wrong, we’ll fix it” would prevail.
</p>
<p>
    For teams like these, we often choose a field visit as their first foray into watching their users. Field visits are great because we get to see what the users do in their natural environment. It doesn’t require prior knowledge of what the proper tasks in the design are. We interview the user, uncover their goals and objectives, and then ask them to use the product or service to accomplish those.
</p>
<p>
    A typical field visit is two hours. Usually with ten to twelve visits, each team member can get at least eight hours of exposure to a minimum of four different users, each trying to use the design in interesting ways.
</p>
<p>
    The results are typically a list of easy fixes. One recent 12-visit venture with a 10-member team produced 350 items on their list of quick fixes. The product improvements started showing up in just a matter of weeks.
</p>
<h2>
    A Minimum of Every Six Weeks<br>
</h2>
<p>
    We saw many teams that conducted a study once a year or even less. These teams struggled virtually the same as teams who didn’t do any research at all. Their designs became more complex and their users reported more frustration as they kept adding new features and capabilities.
</p>
<p>
    The teams with the best results were those that kept up the research on an ongoing basis. It seems that six weeks was the bare minimum for a two-hour exposure dose. The teams with members who spent the minimum of two hours every six weeks saw far greater improvements to their design’s user experience than teams who didn’t meet the minimum. And teams with more frequent exposure, say two-hours every three weeks, saw even better results.
</p>
<p>
    We think there are two reasons the frequency turns out to be important. First is the way memory works. It’s harder to remember someone you’ve met more than six weeks ago than someone you’ve met last week. If we want our users and their needs to be present in our minds as we’re creating our designs, we need to regularly see them.
</p>
<p>
    The second reason has to do with the pain of an ongoing frustration. It’s painful to watch someone struggle with your design. It’s even more painful to come back a few weeks later and see someone else struggle with the same problem again. The more times we’re exposed to those struggles, the more frustrated we get, the more we want to fix those problems. (And the happier we’ll be when we finally see someone who breezes right through with our new design.)
</p>
<p>
    Some problems are particularly gnarly. Seeing these problems repeat, in the field and in the lab, gives us insights into the nuances behind their potential causes. Testing out new design ideas can help us get to a solution faster. A regular exposure program makes that happen even better.
</p>
<p>
    By having a six-week minimum to our exposure, we leverage these two factors, making our users and their needs the driver of the design work we’re doing on any given day.
</p>
<h2>
    Types of Exposure to Users<br>
</h2>
<p>
    Field visits aren’t the only form of exposure we found that works. Usability tests, both in-person and remote, can be very effective. (We found a mixture of both works better than 100% remote sessions.) Once you know the tasks that users naturally use with the design (because you discovered them during your field visits), it’s easy to construct realistic scenarios for usability testing.
</p>
<p>
    For folks heavily involved with a style of self-design, using it themselves for real work also can contribute. (For more about self-design, see my recent article, <a href="//articles.uie.com/self_design/">Actually, You Might Be Your User</a>.) Again, validating these results with other methods, such as field visits and usability testing, helps you understand what your users experience that you don’t when using the design.
</p>
<p>
    Watching users work with competitive designs also is important. Seeing them work through those same tasks with someone else’s design can help identify where there are gaps in your own design. It also makes it easy to point out where your advantages lie.
</p>
<h2>
    The Team of Influencers<br>
</h2>
<p>
    Our research had a finding that took us by surprise: Teams that excluded non-design personnel didn’t see the same advantages as teams that included those people.
</p>
<p>
    For example, we worked with teams where only the designers and developers were having regular exposure to their users. Stakeholders, such as product managers and executives, along with other non-design folks, like technical support liaisons and quality assurance management, didn’t participate in the field studies or usability tests. While the core design team became very familiar with what users needed and wanted, they were constantly battling with these other individuals who didn’t have the same experiences.
</p>
<p>
    The tipping point came when we found teams where all these other folks were participating in the user research studies. No longer did they assert their own opinions of the design direction above what the research findings were telling the teams. Having the execs, stakeholders, and other non-design folks part of the exposure program produced a more user-focused process overall.
</p>
<p>
    Exposure is easy to measure. You can just count the hours everyone has had participating in the studies. We’re seeing teams make it part of their quarterly performance reviews, sending a clear message of the importance of user experience, especially when all the influencers are measured the same way.
</p>
<h2>
    The Challenge: Two Hours Every Six Weeks For Everyone<br>
</h2>
<p>
    Granted, we admit our data could be flawed. There could be other factors here. However, we’ve tested every possible theory, spent time reviewing every factor we could imagine, and we keep coming back to this one item: Get every member on the team to spend two hours every six weeks and you’ll likely have a great user experience appear before your very eyes.</p>
</article>


<hr>

<footer>
  <p>
    <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
    <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
      </svg> Suivre</a> •
    <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
      </svg> Pro</a> •
    <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
      </svg> Email</a> •
    <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
      </svg> Légal</abbr>
  </p>
  <template id="theme-selector">
      <form>
          <fieldset>
              <legend><svg class="icon icon-brightness-contrast">
                <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
              </svg> Thème</legend>
              <label>
                  <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
              </label>
              <label>
                  <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
              </label>
              <label>
                  <input type="radio" value="light" name="chosen-color-scheme"> Clair
              </label>
          </fieldset>
      </form>
  </template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
    function loadThemeForm(templateName) {
        const themeSelectorTemplate = document.querySelector(templateName)
        const form = themeSelectorTemplate.content.firstElementChild
        themeSelectorTemplate.replaceWith(form)

        form.addEventListener('change', (e) => {
            const chosenColorScheme = e.target.value
            localStorage.setItem('theme', chosenColorScheme)
            toggleTheme(chosenColorScheme)
        })

        const selectedTheme = localStorage.getItem('theme')
        if (selectedTheme && selectedTheme !== 'undefined') {
            form.querySelector(`[value="${selectedTheme}"]`).checked = true
        }
    }

    const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
    window.addEventListener('load', () => {
        let hasDarkRules = false
        for (const styleSheet of Array.from(document.styleSheets)) {
            let mediaRules = []
            for (const cssRule of styleSheet.cssRules) {
                if (cssRule.type !== CSSRule.MEDIA_RULE) {
                    continue
                }
                // WARNING: Safari does not have/supports `conditionText`.
                if (cssRule.conditionText) {
                    if (cssRule.conditionText !== prefersColorSchemeDark) {
                        continue
                    }
                } else {
                    if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
                        continue
                    }
                }
                mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
            }

            // WARNING: do not try to insert a Rule to a styleSheet you are
            // currently iterating on, otherwise the browser will be stuck
            // in a infinite loop…
            for (const mediaRule of mediaRules) {
                styleSheet.insertRule(mediaRule.cssText)
                hasDarkRules = true
            }
        }
        if (hasDarkRules) {
            loadThemeForm('#theme-selector')
        }
    })
</script>
</body>
</html>