{"id":414,"date":"2026-02-09T22:03:59","date_gmt":"2026-02-10T03:03:59","guid":{"rendered":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/?post_type=chapter&p=414"},"modified":"2026-03-12T17:02:38","modified_gmt":"2026-03-12T21:02:38","slug":"6-1-what-is-user-experience-design","status":"publish","type":"chapter","link":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/chapter\/6-1-what-is-user-experience-design\/","title":{"raw":"6.1 What is User Experience Design?","rendered":"6.1 What is User Experience Design?"},"content":{"raw":"Jesse James Garrett defines user experience<\/strong> (UX) as \"the experience the product creates for people who use it in the real world.\"[footnote]J.J. Garrett, The Elements of User Experience: User-Centred Design for the Web<\/em>. New York: American Institute of Graphic Arts, 2003.[\/footnote] Simple enough on the surface, but the phrasing matters: the focus is on experience<\/em>, not the product. A website can be beautifully designed and still confuse everyone who visits it. An application can be packed with features and still overwhelm anyone trying to use it for the first time. Technical impressiveness doesn't guarantee a good experience. UX design is about shaping how people actually perceive and interact with what you've built.\r\n
\r\n\r\nUser Experience (UX) Design<\/strong> addresses all aspects of a product or service as perceived by users. This includes not just the interface itself but the user's initial awareness, discovery, learning, use, support, and eventual discontinuation of the product. UX design extends traditional Human-Computer Interaction (HCI) by considering the total experience rather than only the moments of direct interaction.\r\n\r\nHave a look at Jakob Nielson's 10 Usability Heuristics for User Interface Design<\/a> to get a sense of the many apects of the user's experience that we need to consider.\r\n\r\n<\/div>\r\nUX design often gets lumped in with nearby disciplines of UI and product design, so it helps to draw some lines.\r\n

User Interface (UI) design<\/strong> is the part you can point to on the screen. It\u2019s the buttons and menus, the typography choices, spacing, color, layout, icon styles, or, all the visual and interactive pieces people directly use. UI is important, and it\u2019s usually part of UX work, but it\u2019s only one slice of it.<\/p>\r\n

Product design<\/strong> is another neighbour term. Products can be physical or digital, or both, with an emphasis on what the thing is and how it\u2019s built: features, form, function, constraints, tradeoffs. UX design overlaps with that, but it keeps pulling you back to a different question: what does this product actually feel like to use in real life? You can ship something that\u2019s feature-complete and looks great and still make people miserable if you didn\u2019t account for how they behave, what they expect, or the situation they\u2019re in when they\u2019re using it.<\/p>\r\n

UX<\/strong> stretches across the whole relationship a person has with a product. It starts before they ever sign up: how they hear about it, what they assume it does, what the first few minutes are like. It includes discovery and learning and day-to-day use: can people get their job done without wrestling with the tool?<\/p>\r\nAnd it doesn\u2019t stop there. UX also covers what happens when something breaks, how user support systems work, how errors are explained, and even how someone leaves\u2014canceling, exporting data, switching to something else. Every one of those moments can either feel smooth and respectful or turn into a source of friction.\r\n

\r\n

EXERCISE 6.1<\/strong>\u00a0 Defining Boundaries<\/p>\r\n\r\n<\/header>\r\n

\r\n\r\nThe boundaries between\u00a0 UX design, UI Design and Product design can be a bit fuzzy at times. Try sharpening your understanding of the distinctions by applying them to a real world example. Choose a digital product you are very familiar with, such as a banking app, a streaming service, your university\u2019s course registration system, or a social media platform.\r\n\r\nIdentify at least one specific example for each\u00a0 category below, and provide a 1-2 sentence rationale for why it belongs in that category.\r\n

UI Design<\/strong> (Visual and interactive elements that users directly touch)<\/p>\r\n

Product Design<\/strong> (features, forms, functions, technical constraints)<\/p>\r\n

UX Design<\/strong> (the overall experience across the full relationship with the produce)<\/p>\r\nDiscuss<\/strong>:\u00a0 Where did you find it most difficult to \"draw the line\" between categories? What does that difficulty tell you about how UX, UI, and Product Design relate to each other in practice?\r\n\r\n<\/div>\r\n<\/div>\r\n

UX Design and Technical Communications:\u00a0 Shared Foundations<\/h2>\r\nYou might be thinking, \u201cWhy is UX design showing up in a technical communication textbook?\u201d The short answer is that the two fields are closer than they look.\r\n\r\nBoth grew out of the same basic realization: communication works well only when you understand the people on the other end. Clarity beats cleverness. And the best results usually come from doing a version, getting feedback, and improving it. UX design is, in a lot of ways, technical communication applied to interactive digital spaces.\r\n\r\nTake audience analysis, for example. In Chapters 1 and 2, you looked at questions like: Who\u2019s going to read this? What do they already know? What are they trying to do? UX designers ask the same things, just with \u201cusers\u201d instead of \u201creaders.\u201d They conduct interviews, surveys, and observation to figure out what people need, what they expect, and what gets in their way. If you\u2019re comfortable with task and audience analysis from Chapter 2, you already have a mental model that fits neatly with UX research.\r\n\r\nThe overlap shows up again in document design. The principles from Chapter 3\u2014readability, visual hierarchy, purposeful formatting\u2014don\u2019t stop working just because the content is on a screen. Headings, spacing, and consistency help someone scan a report; the same ideas help someone find their way through an app or a website. Good interfaces rely on the same kind of structure and cueing that good documents do (see Figure 6.1.1<\/strong>).\r\n\r\nThe key connection, though, is the process. Technical communication is iterative: you plan, research, draft, revise, and edit based on feedback. UX follows a similar loop: research, design, test, refine. In both cases, the first pass is rarely the final one, and \u201cdone\u201d usually means \u201cgood enough for now, with a plan to keep improving.\u201d\r\n\r\n[caption id=\"attachment_419\" align=\"alignnone\" width=\"1024\"]\"A Figure 6.6.1<\/strong> Overlapping Competencies in Technical Communications and UX Design[\/caption]\r\n\r\nThis overlap matters in practical, career-shaping ways. A lot of technical communicators now work in jobs that mix \u201cclassic\u201d documentation with UX work, especially in companies building digital products. Job titles like Content Strategist, UX Writer, Information Architect<\/strong>, and UX Researcher<\/strong> lean heavily on the same skills you develop in technical communication: figuring out what people need, organizing information so it\u2019s easy to use, and testing whether the result actually works.\r\n\r\nLearning UX principles isn\u2019t about leaving technical communication behind. It\u2019s more like adding range. You\u2019re still doing the core work (e.g., making complex things understandable and usable) but you\u2019re doing it in environments where the \u201cdocument\u201d might be an onboarding flow, a settings screen, an error message, or an in-app help article. As more work moves into digital systems, employers want people who can think about communication as part of the product itself, not just something that sits beside it.\r\n
\r\n

EXERCISE 6.2<\/strong>\u00a0 Examine the Overlap in Document Design and Interface Design<\/p>\r\n\r\n<\/header>\r\n

\r\n\r\nTechnical Communications and UX design share a set of core competencies: audience analysis, document design, iterative revision, and research. Test that claim against your own experience:\r\n\r\nThink of a digital product you used today (e.g., an app, a website, a self-service kiosk, a registration portal, anything interactive). Then think of a document you\u2019ve read or written recently in this course (an email, a set of instructions, a report draft). In a short paragraph for each, answer the following:\r\n
    \r\n \t
  1. What was the purpose of the product or document? Who was it designed for?<\/li>\r\n \t
  2. Where did the design help you accomplish what you needed? Where did it create friction?<\/li>\r\n \t
  3. What design choices (layout, language, structure, visual cues) seemed intentional? What seemed like an afterthought?<\/li>\r\n<\/ol>\r\nShare your examples with a partner or small group. As you compare, look for patterns: which kinds of design strengths and weaknesses showed up in both the digital product and the document? Where do the overlaps between technical communication and UX design feel strongest to you? Where do the two seem to diverge?\r\n\r\n<\/div>\r\n<\/div>\r\n

    A Brief History of UX in Technical Communication<\/h2>\r\nThe phrase \u201cuser experience\u201d started circulating in the 1990s, especially after cognitive scientist Don Norman joined Apple and pushed for a more big-picture way of thinking about design. Norman (and his book The Design of Everyday Things<\/em><\/a>,[footnote]D. Norman, The Design of Everyday Things, Revised and Expanded Edition<\/em>. New York: Basic Books, 2013.[\/footnote] which people still recommend constantly) argued that designers shouldn\u2019t stop at technical specs or a good-looking interface. They needed to pay attention to how products fit into real human behaviour: how people understand them, stumble through them, and make them part of their routines. That idea may sound modern, but a lot of what we now call UX has been building inside technical communication for decades.\r\n\r\nA major piece of that history is the usability movement<\/strong> in technical communication, which picked up speed in the 1980s and 1990s. Scholars and practitioners like Janice Redish<\/a> helped make the case that \u201cexpert review\u201d wasn\u2019t enough. If you want documentation to work, you have to put it in front of actual users and see what happens. Watching real people try real tasks, paying special attention to where they hesitate, what they misread, what they skip, what they assume, became a practical method, not an academic luxury. That approach sits at the center of usability studies, and it later became one of the standard pillars of UX work.\r\n\r\nThen the web changed the scale of the problem. In the mid-1990s, websites moved from novelty to necessity, and soon after, mobile computing made digital interfaces even more constant and personal. Suddenly, products weren\u2019t being used by a narrow group of trained users. They were being used by everyone: people with different levels of experience, different devices, different access needs, and wildly different expectations. The methods that once mattered mostly for specialized software or workplace documentation started to matter for basically any organization trying to communicate online. Today, UX thinking reaches beyond apps and websites into physical products, services, and the larger systems people have to navigate.\r\n\r\nFor students of technical communication, this background is useful because it reframes UX as less of a \u201cnew field you have to learn\u201d and more of a continuation of work you already recognize. UX designers ask questions that technical communicators have asked all along: Who is this for? What are they trying to do? What\u2019s getting in their way? How do we help them succeed? The difference is the setting and the number of ways you can respond\u2014screens, flows, microcopy, support content, onboarding, and more.\r\n\r\nIn the next sections, we\u2019ll connect rhetorical ideas to UX practice, look at a widely used framework for thinking through user experience, and walk through research methods you can start using right away. The goal isn\u2019t to toss out what you\u2019ve learned so far, but to build on it and run basic UX research in your own projects.","rendered":"

    Jesse James Garrett defines user experience<\/strong> (UX) as “the experience the product creates for people who use it in the real world.”[1]<\/sup><\/a> Simple enough on the surface, but the phrasing matters: the focus is on experience<\/em>, not the product. A website can be beautifully designed and still confuse everyone who visits it. An application can be packed with features and still overwhelm anyone trying to use it for the first time. Technical impressiveness doesn’t guarantee a good experience. UX design is about shaping how people actually perceive and interact with what you’ve built.<\/p>\n

    \n

    User Experience (UX) Design<\/strong> addresses all aspects of a product or service as perceived by users. This includes not just the interface itself but the user’s initial awareness, discovery, learning, use, support, and eventual discontinuation of the product. UX design extends traditional Human-Computer Interaction (HCI) by considering the total experience rather than only the moments of direct interaction.<\/p>\n

    Have a look at Jakob Nielson’s 10 Usability Heuristics for User Interface Design<\/a> to get a sense of the many apects of the user’s experience that we need to consider.<\/p>\n<\/div>\n

    UX design often gets lumped in with nearby disciplines of UI and product design, so it helps to draw some lines.<\/p>\n

    User Interface (UI) design<\/strong> is the part you can point to on the screen. It\u2019s the buttons and menus, the typography choices, spacing, color, layout, icon styles, or, all the visual and interactive pieces people directly use. UI is important, and it\u2019s usually part of UX work, but it\u2019s only one slice of it.<\/p>\n

    Product design<\/strong> is another neighbour term. Products can be physical or digital, or both, with an emphasis on what the thing is and how it\u2019s built: features, form, function, constraints, tradeoffs. UX design overlaps with that, but it keeps pulling you back to a different question: what does this product actually feel like to use in real life? You can ship something that\u2019s feature-complete and looks great and still make people miserable if you didn\u2019t account for how they behave, what they expect, or the situation they\u2019re in when they\u2019re using it.<\/p>\n

    UX<\/strong> stretches across the whole relationship a person has with a product. It starts before they ever sign up: how they hear about it, what they assume it does, what the first few minutes are like. It includes discovery and learning and day-to-day use: can people get their job done without wrestling with the tool?<\/p>\n

    And it doesn\u2019t stop there. UX also covers what happens when something breaks, how user support systems work, how errors are explained, and even how someone leaves\u2014canceling, exporting data, switching to something else. Every one of those moments can either feel smooth and respectful or turn into a source of friction.<\/p>\n

    \n
    \n

    EXERCISE 6.1<\/strong>\u00a0 Defining Boundaries<\/p>\n<\/header>\n

    \n

    The boundaries between\u00a0 UX design, UI Design and Product design can be a bit fuzzy at times. Try sharpening your understanding of the distinctions by applying them to a real world example. Choose a digital product you are very familiar with, such as a banking app, a streaming service, your university\u2019s course registration system, or a social media platform.<\/p>\n

    Identify at least one specific example for each\u00a0 category below, and provide a 1-2 sentence rationale for why it belongs in that category.<\/p>\n

    UI Design<\/strong> (Visual and interactive elements that users directly touch)<\/p>\n

    Product Design<\/strong> (features, forms, functions, technical constraints)<\/p>\n

    UX Design<\/strong> (the overall experience across the full relationship with the produce)<\/p>\n

    Discuss<\/strong>:\u00a0 Where did you find it most difficult to “draw the line” between categories? What does that difficulty tell you about how UX, UI, and Product Design relate to each other in practice?<\/p>\n<\/div>\n<\/div>\n

    UX Design and Technical Communications:\u00a0 Shared Foundations<\/h2>\n

    You might be thinking, \u201cWhy is UX design showing up in a technical communication textbook?\u201d The short answer is that the two fields are closer than they look.<\/p>\n

    Both grew out of the same basic realization: communication works well only when you understand the people on the other end. Clarity beats cleverness. And the best results usually come from doing a version, getting feedback, and improving it. UX design is, in a lot of ways, technical communication applied to interactive digital spaces.<\/p>\n

    Take audience analysis, for example. In Chapters 1 and 2, you looked at questions like: Who\u2019s going to read this? What do they already know? What are they trying to do? UX designers ask the same things, just with \u201cusers\u201d instead of \u201creaders.\u201d They conduct interviews, surveys, and observation to figure out what people need, what they expect, and what gets in their way. If you\u2019re comfortable with task and audience analysis from Chapter 2, you already have a mental model that fits neatly with UX research.<\/p>\n

    The overlap shows up again in document design. The principles from Chapter 3\u2014readability, visual hierarchy, purposeful formatting\u2014don\u2019t stop working just because the content is on a screen. Headings, spacing, and consistency help someone scan a report; the same ideas help someone find their way through an app or a website. Good interfaces rely on the same kind of structure and cueing that good documents do (see Figure 6.1.1<\/strong>).<\/p>\n

    The key connection, though, is the process. Technical communication is iterative: you plan, research, draft, revise, and edit based on feedback. UX follows a similar loop: research, design, test, refine. In both cases, the first pass is rarely the final one, and \u201cdone\u201d usually means \u201cgood enough for now, with a plan to keep improving.\u201d<\/p>\n

    \"A
    Figure 6.6.1<\/strong> Overlapping Competencies in Technical Communications and UX Design<\/figcaption><\/figure>\n

    This overlap matters in practical, career-shaping ways. A lot of technical communicators now work in jobs that mix \u201cclassic\u201d documentation with UX work, especially in companies building digital products. Job titles like Content Strategist, UX Writer, Information Architect<\/strong>, and UX Researcher<\/strong> lean heavily on the same skills you develop in technical communication: figuring out what people need, organizing information so it\u2019s easy to use, and testing whether the result actually works.<\/p>\n

    Learning UX principles isn\u2019t about leaving technical communication behind. It\u2019s more like adding range. You\u2019re still doing the core work (e.g., making complex things understandable and usable) but you\u2019re doing it in environments where the \u201cdocument\u201d might be an onboarding flow, a settings screen, an error message, or an in-app help article. As more work moves into digital systems, employers want people who can think about communication as part of the product itself, not just something that sits beside it.<\/p>\n

    \n
    \n

    EXERCISE 6.2<\/strong>\u00a0 Examine the Overlap in Document Design and Interface Design<\/p>\n<\/header>\n

    \n

    Technical Communications and UX design share a set of core competencies: audience analysis, document design, iterative revision, and research. Test that claim against your own experience:<\/p>\n

    Think of a digital product you used today (e.g., an app, a website, a self-service kiosk, a registration portal, anything interactive). Then think of a document you\u2019ve read or written recently in this course (an email, a set of instructions, a report draft). In a short paragraph for each, answer the following:<\/p>\n

      \n
    1. What was the purpose of the product or document? Who was it designed for?<\/li>\n
    2. Where did the design help you accomplish what you needed? Where did it create friction?<\/li>\n
    3. What design choices (layout, language, structure, visual cues) seemed intentional? What seemed like an afterthought?<\/li>\n<\/ol>\n

      Share your examples with a partner or small group. As you compare, look for patterns: which kinds of design strengths and weaknesses showed up in both the digital product and the document? Where do the overlaps between technical communication and UX design feel strongest to you? Where do the two seem to diverge?<\/p>\n<\/div>\n<\/div>\n

      A Brief History of UX in Technical Communication<\/h2>\n

      The phrase \u201cuser experience\u201d started circulating in the 1990s, especially after cognitive scientist Don Norman joined Apple and pushed for a more big-picture way of thinking about design. Norman (and his book The Design of Everyday Things<\/em><\/a>,[2]<\/sup><\/a> which people still recommend constantly) argued that designers shouldn\u2019t stop at technical specs or a good-looking interface. They needed to pay attention to how products fit into real human behaviour: how people understand them, stumble through them, and make them part of their routines. That idea may sound modern, but a lot of what we now call UX has been building inside technical communication for decades.<\/p>\n

      A major piece of that history is the usability movement<\/strong> in technical communication, which picked up speed in the 1980s and 1990s. Scholars and practitioners like Janice Redish<\/a> helped make the case that \u201cexpert review\u201d wasn\u2019t enough. If you want documentation to work, you have to put it in front of actual users and see what happens. Watching real people try real tasks, paying special attention to where they hesitate, what they misread, what they skip, what they assume, became a practical method, not an academic luxury. That approach sits at the center of usability studies, and it later became one of the standard pillars of UX work.<\/p>\n

      Then the web changed the scale of the problem. In the mid-1990s, websites moved from novelty to necessity, and soon after, mobile computing made digital interfaces even more constant and personal. Suddenly, products weren\u2019t being used by a narrow group of trained users. They were being used by everyone: people with different levels of experience, different devices, different access needs, and wildly different expectations. The methods that once mattered mostly for specialized software or workplace documentation started to matter for basically any organization trying to communicate online. Today, UX thinking reaches beyond apps and websites into physical products, services, and the larger systems people have to navigate.<\/p>\n

      For students of technical communication, this background is useful because it reframes UX as less of a \u201cnew field you have to learn\u201d and more of a continuation of work you already recognize. UX designers ask questions that technical communicators have asked all along: Who is this for? What are they trying to do? What\u2019s getting in their way? How do we help them succeed? The difference is the setting and the number of ways you can respond\u2014screens, flows, microcopy, support content, onboarding, and more.<\/p>\n

      In the next sections, we\u2019ll connect rhetorical ideas to UX practice, look at a widely used framework for thinking through user experience, and walk through research methods you can start using right away. The goal isn\u2019t to toss out what you\u2019ve learned so far, but to build on it and run basic UX research in your own projects.<\/p>\n

      1. J.J. Garrett, The Elements of User Experience: User-Centred Design for the Web<\/em>. New York: American Institute of Graphic Arts, 2003. ↵<\/a><\/li>
      2. D. Norman, The Design of Everyday Things, Revised and Expanded Edition<\/em>. New York: Basic Books, 2013. ↵<\/a><\/li><\/ol><\/div>","protected":false},"author":254,"menu_order":1,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["justin-lewis"],"pb_section_license":""},"chapter-type":[],"contributor":[67],"license":[],"class_list":["post-414","chapter","type-chapter","status-publish","hentry","contributor-justin-lewis"],"part":412,"_links":{"self":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/414","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/users\/254"}],"version-history":[{"count":11,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/414\/revisions"}],"predecessor-version":[{"id":776,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/414\/revisions\/776"}],"part":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/parts\/412"}],"metadata":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/414\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/media?parent=414"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapter-type?post=414"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/contributor?post=414"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/license?post=414"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}