{"id":421,"date":"2026-02-09T22:27:44","date_gmt":"2026-02-10T03:27:44","guid":{"rendered":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/?post_type=chapter&p=421"},"modified":"2026-03-26T20:57:37","modified_gmt":"2026-03-27T00:57:37","slug":"6-2-the-rhetorical-foundations-of-ux-design","status":"publish","type":"chapter","link":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/chapter\/6-2-the-rhetorical-foundations-of-ux-design\/","title":{"raw":"6.2 The Rhetorical Foundations of UX Design","rendered":"6.2 The Rhetorical Foundations of UX Design"},"content":{"raw":"If you\u2019ve worked through the earlier chapters, you\u2019ve already met one of the most useful tools in the book: the rhetorical situation<\/a> (Ch. 2.2). It's introduced as a way to break down any communication event: who\u2019s doing the communicating, who they\u2019re trying to reach, what\u2019s being communicated, the medium or form it takes, and the purpose behind it.\r\n\r\nWhat isn\u2019t always obvious at first is how well that same framework fits UX design. Designing a digital product is still a communication problem. The \u201cspeaker\u201d might be an app, a website, a service, or the organization behind it. The \u201cmessage\u201d shows up in labels, flows, prompts, and defaults. The \u201chow\u201d is the interface, the interaction design, the content, the timing. And the \u201cwhy\u201d is the outcome you\u2019re trying to help the user achieve (alongside whatever goals the organization has). Look at it that way and UX starts to resemble applied rhetoric: using familiar principles of clarity, emphasis, and audience awareness, then translating them into interactive environments where people aren\u2019t just reading\u2014they\u2019re doing.\r\n

The Rhetorical Situation in UX Contexts<\/h1>\r\nThe rhetorical situation is usually described as five connected pieces: purpose, writer, audience, message<\/em>, and context\/culture.<\/em> When you write a document, you\u2019re constantly balancing those elements against each other. What are we trying to get done? What knowledge, constraints, or biases do we bring as the writer? Who\u2019s going to use this, and what are they trying to accomplish? What information belongs here, and how should it be organized? What situational or cultural expectations shape how it will be read?\r\n\r\nUX designers work through the same set of questions, even if the labels shift a bit (see Figure 6.2.1<\/strong>). Put another way, a screen is never \u201cjust a screen.\u201d It\u2019s a response to a rhetorical situation, shaped by purpose, people, content, and context. These are exactly the same forces you\u2019ve already been trained to notice in written communication.<\/span>\r\n\r\n[caption id=\"attachment_422\" align=\"aligncenter\" width=\"1024\"]\"A Figure 6.2.1<\/strong> The Rhetorical Situation adapted for UX Design[\/caption]\r\n\r\nPURPOSE<\/strong>, in UX design, usually has two layers:\r\n

The user\u2019s purpose<\/strong> is the reason someone showed up in the first place. They open a banking app to check a balance, move money, deposit a check. They go to a library site to find a title, renew items, reserve a study room. Getting clear on those goals takes the same kind of task analysis you\u2019d do before writing instructions or a user guide: what are people trying to accomplish, what steps do they expect, where do they get stuck?<\/p>\r\n

The organization\u2019s purpose<\/strong> is what the company or institution wants the product to achieve. Maybe it\u2019s higher engagement, fewer support calls, more completed applications, better retention, stronger brand trust. Good UX is often about negotiating the overlap. When the product helps users succeed quickly and confidently, it usually helps the organization too. When those goals fight each other, people feel it immediately.<\/p>\r\nTHE WRITER <\/b>in a rhetorical situation maps pretty cleanly to the designer<\/strong> in UX, with one wrinkle: in product work, \u201cthe designer\u201d is rarely a single person. Decisions come from teams of designers, engineers, product managers, content producers, legal, and marketing. That mix of labor shapes what gets built. Still, the same self-awareness applies. Designers bring their own habits, assumptions, and technical comfort into the work, and those can quietly steer the design. A core UX lesson is simple, but sometimes hard to keep in mind: you are not your user. What feels obvious after months inside a project can be baffling to someone seeing it for the first time. This is why user testing is so important.\r\n\r\nAUDIENCE <\/strong>becomes users<\/strong>, but UX tends to treat user diversity as unavoidable rather than optional. One product can serve people with very different levels of experience, physical abilities, languages, cultural expectations, and constraints. The same banking app might be used by a twenty-year-old who lives on their phone and a seventy-year-old who finds touchscreens finicky. The same library site might be used on a large monitor in a quiet room and on a phone while someone is juggling a coffee and a backpack. That\u2019s why UX research (which you\u2019ll get into later in 6.4) leans on systematic ways of learning about users instead of guessing.\r\n\r\nTHE MESSAGE<\/strong>\u00a0in UX is the interface<\/strong> itself. It\u2019s the words, yes, but also the whole system of cues: layout, buttons, icons, navigation, confirmations, error states, animations, and feedback. Every choice communicates something about what\u2019s possible, what\u2019s important, and what happens next. The document design skills you already know transfer well here. Interfaces also rely on hierarchy, consistency, and spacing to help people scan, orient themselves, and make decisions. Clear, user-centred writing still matters too: keep it tight, stay consistent, anticipate confusion, and assume people will misread things when they\u2019re moving fast or stressed.\r\n\r\nCONTEXT and CULTURE<\/strong> shape everything around that interface. Context includes where someone is using the product (quiet office vs. noisy train), what device they\u2019re on (desktop, phone, watch), and the conventions they\u2019ve learned from the platform (iOS vs. Android patterns, web vs. native expectations). Culture is broader than nationality: it can mean workplace norms, industry expectations, accessibility norms, privacy expectations, even generational attitudes toward technology. If you ignore context, you can end up with designs that look great in a lab and fall apart in real life, when someone\u2019s using them one-handed, on poor Wi-Fi, with three distractions competing for attention.\r\n\r\nTable 6.2.1<\/strong> Mapping the Rhetorical Situation to UX Design\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Rhetorical Component<\/strong><\/th>\r\nTraditional Tech Comm<\/strong><\/th>\r\nUX Design Context<\/strong><\/th>\r\n<\/tr>\r\n<\/thead>\r\n
Purpose<\/strong><\/td>\r\nInform, instruct, persuade through documents<\/td>\r\nEnable users to accomplish goals through interaction<\/td>\r\n<\/tr>\r\n
Writer\/Creator<\/strong><\/td>\r\nTechnical writer, documentation team<\/td>\r\nUX designer, product team, organization<\/td>\r\n<\/tr>\r\n
Audience<\/strong><\/td>\r\nReaders with varying expertise levels<\/td>\r\nUsers with diverse abilities, contexts, and goals<\/td>\r\n<\/tr>\r\n
Message<\/strong><\/td>\r\nContent of document (text, visuals, structure)<\/td>\r\nInterface elements, interactions, feedback systems<\/td>\r\n<\/tr>\r\n
Context\/Culture<\/strong><\/td>\r\nWorkplace, discipline, organizational norms<\/td>\r\nPlatform, device, cultural expectations, use environment<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Audience Analysis as User Research<\/h2>\r\nChapter 2.2 gave you a practical set of questions for building an audience profile: Who are the primary readers? What\u2019s their relationship to you? What do they already know? What situation created the need for this communication? If you swap \u201creaders\u201d for \u201cusers,\u201d you can see how naturally that framework slides into UX research. The main difference is that UX teams often answer those questions with more structured, evidence-based methods: interviews, surveys, observation, and usability tests, rather than relying mainly on inference.\r\n\r\nWhen UX designers study users, they\u2019re looking at many of the same dimensions you\u2019d cover in audience analysis, just with a wider lens. They pay attention to users\u2019 goals and expectations: the specific tasks people are trying to complete, and the assumptions they bring from using similar products. They consider physical abilities and limitations, because real users have different motor skills, vision, hearing, and cognitive capacities. Based on these factors, they develop designs that work across that range of accessibilities. They think about perception and attention, too. People don\u2019t read screens the way they read essays; they scan, they look for cues, and they miss things when the page is crowded or the wording is vague. And they don\u2019t ignore enjoyment. If something technically \u201cworks\u201d but feels annoying or slow, users will avoid it when they can.\r\n\r\nA key UX insight that\u2019s worth holding onto is that users never arrive empty-handed. People bring a lifetime of learned patterns, or \u201cconventions,\u201d to every new interface. They expect settings to be in a familiar place, common icons to mean familiar things, and standard gestures to behave the way they\u2019ve behaved everywhere else. When a design leans into those conventions, users can borrow their existing knowledge instead of relearning basics. When a design breaks them, it can still succeed; however, there\u2019s a design price to pay: more effort, more mistakes, and a higher chance the user quits. That\u2019s why UX designers treat convention as a tool, not a lack of creativity. Familiar patterns reduce cognitive load and make the experience feel \u201cobvious\u201d in the best sense.\r\n\r\nCulture adds another layer, and it\u2019s where simple demographic checklists stop being enough. Researchers such as Huatong Sun have argued that usability is culturally situated<\/a>: what feels straightforward in one context can feel confusing or even inappropriate in another, even when the language is translated correctly.[footnote]H. Sun and G. Getto, \u201cLocalizing user experience: Strategies, practices, and technique for culturally sensitive design<\/a>,\u201d Technical Communications<\/em>, vol. 64 (2), May 2017.[\/footnote] Jennifer Sano-Franchini\u2019s work<\/a> (including analysis of Asian eyelid surgery apps[footnote]J. Sano-Fanchini, \u201cWhat can Asian eyelinds teach us about User Experience Design?<\/a> A culturally reflexive framework for UX\/I Design,\u201d Rhetoric, Professional Communication and Globalization<\/em>, vol. 10(1), 2017.[\/footnote]) is a good reminder that interfaces aren\u2019t neutral; rather, they can quietly bake in cultural assumptions about bodies, identity, and \u201cnormal\u201d users. Taken together, this line of research pushes UX beyond \u201cdesign for age group X\u201d and toward something more reflective: noticing how identity, culture, and context shape what people expect from technology, and being honest about the limits of the designer\u2019s own viewpoint.\r\n
\r\n

EXERCISE 6.3<\/strong>\u00a0 Assumption Audit: \"You are not your user\"<\/p>\r\n\r\n<\/header>\r\n

\r\n\r\nDesigners bring their own habits, assumptions, and comfort levels into the work, and those can quietly steer the design. This activity asks you to examine those assumptions in yourself\r\n

Think about the last time you helped someone use a piece of technology\u2014a family member, a friend, a coworker. What did they struggle with that seemed obvious to you? Write a brief account of the situation: what was the task, where did they get stuck, and what did you have to explain?<\/p>\r\n

Now flip it. Think about a piece of technology that you find frustrating or confusing, even though other people seem fine with it. Describe the friction: what do you expect to happen, and what actually happens?<\/p>\r\nCompare your experiences with a partner's. What patterns emerge? When you helped someone else, what assumptions were you making about what \u201cshould be obvious\u201d? When you were the frustrated user, what assumptions did the designer seem to be making about you? How does this connect to the audience analysis work you practiced in Chapter 2.2?\r\n\r\n<\/div>\r\n<\/div>\r\n \r\n

Technology as Rhetorical Genre<\/h1>\r\nOne more rhetorical concept turns out to be especially handy for thinking about UX: genre<\/strong>. In rhetoric, genres aren\u2019t just categories based on shape or format. As Carolyn Miller argues<\/a>, genres are \u201ctypified responses\u201d to recurring situations.[footnote]C. R. Miller, \"Genre as social action.\" Quarterly Journal of Speech<\/em>, 70(2), pp.151\u2013167, 1984. https:\/\/doi.org\/10.1080\/00335638409383686[\/footnote] A job application letter counts as a genre less because it has a standard structure and more because it\u2019s a recognized way of handling a familiar social moment: someone asks to be hired, and both sides have expectations about what that request should include and how it should sound.\r\n\r\nYou can take that same idea and apply it to digital products. A mobile banking app, a social media feed, a search results page: these are all responses to situations that keep coming up. People need to manage money without going to a branch. They want to share updates and keep tabs on friends or communities. They need to look things up quickly. Over time, designers build common solutions to those needs, and those solutions harden into patterns users come to expect. A new banking app doesn\u2019t start from zero; it gets compared to everything else people have used. If it can\u2019t do the basics, or if it hides them in weird places, users feel that friction immediately.\r\n\r\nSeeing technology as genre gives you a few useful angles.\r\n\r\nFirst, it makes it harder to pretend products are neutral. A technology is built to solve certain problems in certain settings. What it makes easy, what it makes annoying, what it requires you to do in what order, those are design decisions. They reflect assumptions about who the \u201cnormal\u201d user is, what they want, what they\u2019re willing to tolerate, and what the organization wants from them.\r\n\r\nSecond, genre helps explain why design conventions repeat. The shopping cart icon shows up across e-commerce sites because it\u2019s become a shared response to the recurring situation of buying online. It\u2019s not a law of nature; it\u2019s a convention that stuck because it works well enough and users learned it.\r\n\r\nThinking this way turns \u201cinterface critique\u201d into something broader. You\u2019re not just judging whether a screen looks clean; you\u2019re asking what kind of social situation the technology is built for, what expectations it relies on, and what it nudges people to do.\r\n
\r\n

Analyzing Technology as Rhetorical Genre<\/strong><\/p>\r\nWhen examining a digital product as a rhetorical genre, consider:\r\n

Structural: <\/strong>What recurring design elements characterize this type of technology? What interface patterns appear consistently?<\/p>\r\n

Substantive: <\/strong>What social actions does this technology enable? What purposes does it serve for users and organizations?<\/p>\r\n

Contextual: <\/strong>When, where, and under what circumstances do people use this technology? What situational factors shape its use?<\/p>\r\n

Critical: <\/strong>What assumptions about users does this technology embed? Whose needs does it serve well, and whose does it neglect?<\/p>\r\n\r\n<\/div>\r\nThat last question of whose needs a technology serves well, and whose it ignores gets at the part of rhetorical analysis that\u2019s hardest to dodge. Technologies aren\u2019t neutral. Every design choice helps some people and makes things tougher for others. It can privilege certain workflows, certain bodies, certain languages, certain levels of time and attention. It can quietly assume a \u201cdefault\u201d user and treat everyone else as an edge case. Even decisions that seem purely technical (e.g., what gets prioritized, what\u2019s buried, what\u2019s required, etc.) end up reflecting values.\r\n\r\nNoticing these issues isn\u2019t a reason to be cynical about design. It\u2019s a reason to take design seriously. When you see technologies as rhetorical artifacts, as objects shaped by human choices inside real organizational, economic, and cultural constraints, you also see that they can be changed. The current version isn\u2019t inevitable. It\u2019s a set of decisions that could have gone differently, and that can be revisited. That\u2019s where agency comes in: designers can push for alternatives, and users can demand better ones.\r\n\r\nThe rhetorical concepts in this section give you a vocabulary for doing that kind of analysis without drifting into vague criticism. They let you talk concretely about purpose, audience, message, context, and genre, and about what gets left out when those elements are defined too narrowly.\r\n

\r\n

EXERCISE 6.4<\/strong>\u00a0 Analyze familiar technology through the lens of Genre<\/p>\r\n\r\n<\/header>\r\n

\r\n\r\nWe have used Caroline Miller's concept of genre to argue that digital products are \"typified responses to recurrent situations.\" Let's put that to the test.\r\n
    \r\n \t
  1. Pick a common type of digital product: a search engine, a social media feed, an e-commerce checkout flow, a messaging app, a calendar tool, or anything else you use regularly.<\/li>\r\n \t
  2. Identify three to five design conventions that are shared across most products of this type. (For example: most e-commerce sites use a cart icon; most messaging apps put the newest messages at the bottom.) These are the genre\u2019s structural patterns.<\/li>\r\n \t
  3. Now find one place where a specific product breaks or modifies a convention. Describe the departure. Does it work? Does it create confusion? What might have motivated the designers to depart from the pattern?<\/li>\r\n \t
  4. Technologies are not completely \u201cneutral\u201d in that every design choice helps some people and makes things harder for others. Pick one of the conventions you identified and consider: whose needs does it serve well? Whose needs might it overlook?<\/li>\r\n<\/ol>\r\n<\/div>\r\n<\/div>\r\n \r\n\r\nNext, we\u2019ll move from that vocabulary to a more structured UX framework: Jesse James Garrett\u2019s five planes of user experience. It\u2019s a useful model for tracing how high-level goals and strategy turn into the actual screens, interactions, and content people deal with day to day.","rendered":"

    If you\u2019ve worked through the earlier chapters, you\u2019ve already met one of the most useful tools in the book: the rhetorical situation<\/a> (Ch. 2.2). It’s introduced as a way to break down any communication event: who\u2019s doing the communicating, who they\u2019re trying to reach, what\u2019s being communicated, the medium or form it takes, and the purpose behind it.<\/p>\n

    What isn\u2019t always obvious at first is how well that same framework fits UX design. Designing a digital product is still a communication problem. The \u201cspeaker\u201d might be an app, a website, a service, or the organization behind it. The \u201cmessage\u201d shows up in labels, flows, prompts, and defaults. The \u201chow\u201d is the interface, the interaction design, the content, the timing. And the \u201cwhy\u201d is the outcome you\u2019re trying to help the user achieve (alongside whatever goals the organization has). Look at it that way and UX starts to resemble applied rhetoric: using familiar principles of clarity, emphasis, and audience awareness, then translating them into interactive environments where people aren\u2019t just reading\u2014they\u2019re doing.<\/p>\n

    The Rhetorical Situation in UX Contexts<\/h1>\n

    The rhetorical situation is usually described as five connected pieces: purpose, writer, audience, message<\/em>, and context\/culture.<\/em> When you write a document, you\u2019re constantly balancing those elements against each other. What are we trying to get done? What knowledge, constraints, or biases do we bring as the writer? Who\u2019s going to use this, and what are they trying to accomplish? What information belongs here, and how should it be organized? What situational or cultural expectations shape how it will be read?<\/p>\n

    UX designers work through the same set of questions, even if the labels shift a bit (see Figure 6.2.1<\/strong>). Put another way, a screen is never \u201cjust a screen.\u201d It\u2019s a response to a rhetorical situation, shaped by purpose, people, content, and context. These are exactly the same forces you\u2019ve already been trained to notice in written communication.<\/span><\/p>\n

    \"A
    Figure 6.2.1<\/strong> The Rhetorical Situation adapted for UX Design<\/figcaption><\/figure>\n

    PURPOSE<\/strong>, in UX design, usually has two layers:<\/p>\n

    The user\u2019s purpose<\/strong> is the reason someone showed up in the first place. They open a banking app to check a balance, move money, deposit a check. They go to a library site to find a title, renew items, reserve a study room. Getting clear on those goals takes the same kind of task analysis you\u2019d do before writing instructions or a user guide: what are people trying to accomplish, what steps do they expect, where do they get stuck?<\/p>\n

    The organization\u2019s purpose<\/strong> is what the company or institution wants the product to achieve. Maybe it\u2019s higher engagement, fewer support calls, more completed applications, better retention, stronger brand trust. Good UX is often about negotiating the overlap. When the product helps users succeed quickly and confidently, it usually helps the organization too. When those goals fight each other, people feel it immediately.<\/p>\n

    THE WRITER <\/b>in a rhetorical situation maps pretty cleanly to the designer<\/strong> in UX, with one wrinkle: in product work, \u201cthe designer\u201d is rarely a single person. Decisions come from teams of designers, engineers, product managers, content producers, legal, and marketing. That mix of labor shapes what gets built. Still, the same self-awareness applies. Designers bring their own habits, assumptions, and technical comfort into the work, and those can quietly steer the design. A core UX lesson is simple, but sometimes hard to keep in mind: you are not your user. What feels obvious after months inside a project can be baffling to someone seeing it for the first time. This is why user testing is so important.<\/p>\n

    AUDIENCE <\/strong>becomes users<\/strong>, but UX tends to treat user diversity as unavoidable rather than optional. One product can serve people with very different levels of experience, physical abilities, languages, cultural expectations, and constraints. The same banking app might be used by a twenty-year-old who lives on their phone and a seventy-year-old who finds touchscreens finicky. The same library site might be used on a large monitor in a quiet room and on a phone while someone is juggling a coffee and a backpack. That\u2019s why UX research (which you\u2019ll get into later in 6.4) leans on systematic ways of learning about users instead of guessing.<\/p>\n

    THE MESSAGE<\/strong>\u00a0in UX is the interface<\/strong> itself. It\u2019s the words, yes, but also the whole system of cues: layout, buttons, icons, navigation, confirmations, error states, animations, and feedback. Every choice communicates something about what\u2019s possible, what\u2019s important, and what happens next. The document design skills you already know transfer well here. Interfaces also rely on hierarchy, consistency, and spacing to help people scan, orient themselves, and make decisions. Clear, user-centred writing still matters too: keep it tight, stay consistent, anticipate confusion, and assume people will misread things when they\u2019re moving fast or stressed.<\/p>\n

    CONTEXT and CULTURE<\/strong> shape everything around that interface. Context includes where someone is using the product (quiet office vs. noisy train), what device they\u2019re on (desktop, phone, watch), and the conventions they\u2019ve learned from the platform (iOS vs. Android patterns, web vs. native expectations). Culture is broader than nationality: it can mean workplace norms, industry expectations, accessibility norms, privacy expectations, even generational attitudes toward technology. If you ignore context, you can end up with designs that look great in a lab and fall apart in real life, when someone\u2019s using them one-handed, on poor Wi-Fi, with three distractions competing for attention.<\/p>\n

    Table 6.2.1<\/strong> Mapping the Rhetorical Situation to UX Design<\/p>\n\n\n\n\n\n\n\n\n\n
    Rhetorical Component<\/strong><\/th>\nTraditional Tech Comm<\/strong><\/th>\nUX Design Context<\/strong><\/th>\n<\/tr>\n<\/thead>\n
    Purpose<\/strong><\/td>\nInform, instruct, persuade through documents<\/td>\nEnable users to accomplish goals through interaction<\/td>\n<\/tr>\n
    Writer\/Creator<\/strong><\/td>\nTechnical writer, documentation team<\/td>\nUX designer, product team, organization<\/td>\n<\/tr>\n
    Audience<\/strong><\/td>\nReaders with varying expertise levels<\/td>\nUsers with diverse abilities, contexts, and goals<\/td>\n<\/tr>\n
    Message<\/strong><\/td>\nContent of document (text, visuals, structure)<\/td>\nInterface elements, interactions, feedback systems<\/td>\n<\/tr>\n
    Context\/Culture<\/strong><\/td>\nWorkplace, discipline, organizational norms<\/td>\nPlatform, device, cultural expectations, use environment<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Audience Analysis as User Research<\/h2>\n

    Chapter 2.2 gave you a practical set of questions for building an audience profile: Who are the primary readers? What\u2019s their relationship to you? What do they already know? What situation created the need for this communication? If you swap \u201creaders\u201d for \u201cusers,\u201d you can see how naturally that framework slides into UX research. The main difference is that UX teams often answer those questions with more structured, evidence-based methods: interviews, surveys, observation, and usability tests, rather than relying mainly on inference.<\/p>\n

    When UX designers study users, they\u2019re looking at many of the same dimensions you\u2019d cover in audience analysis, just with a wider lens. They pay attention to users\u2019 goals and expectations: the specific tasks people are trying to complete, and the assumptions they bring from using similar products. They consider physical abilities and limitations, because real users have different motor skills, vision, hearing, and cognitive capacities. Based on these factors, they develop designs that work across that range of accessibilities. They think about perception and attention, too. People don\u2019t read screens the way they read essays; they scan, they look for cues, and they miss things when the page is crowded or the wording is vague. And they don\u2019t ignore enjoyment. If something technically \u201cworks\u201d but feels annoying or slow, users will avoid it when they can.<\/p>\n

    A key UX insight that\u2019s worth holding onto is that users never arrive empty-handed. People bring a lifetime of learned patterns, or \u201cconventions,\u201d to every new interface. They expect settings to be in a familiar place, common icons to mean familiar things, and standard gestures to behave the way they\u2019ve behaved everywhere else. When a design leans into those conventions, users can borrow their existing knowledge instead of relearning basics. When a design breaks them, it can still succeed; however, there\u2019s a design price to pay: more effort, more mistakes, and a higher chance the user quits. That\u2019s why UX designers treat convention as a tool, not a lack of creativity. Familiar patterns reduce cognitive load and make the experience feel \u201cobvious\u201d in the best sense.<\/p>\n

    Culture adds another layer, and it\u2019s where simple demographic checklists stop being enough. Researchers such as Huatong Sun have argued that usability is culturally situated<\/a>: what feels straightforward in one context can feel confusing or even inappropriate in another, even when the language is translated correctly.[1]<\/sup><\/a> Jennifer Sano-Franchini\u2019s work<\/a> (including analysis of Asian eyelid surgery apps[2]<\/sup><\/a>) is a good reminder that interfaces aren\u2019t neutral; rather, they can quietly bake in cultural assumptions about bodies, identity, and \u201cnormal\u201d users. Taken together, this line of research pushes UX beyond \u201cdesign for age group X\u201d and toward something more reflective: noticing how identity, culture, and context shape what people expect from technology, and being honest about the limits of the designer\u2019s own viewpoint.<\/p>\n

    \n
    \n

    EXERCISE 6.3<\/strong>\u00a0 Assumption Audit: “You are not your user”<\/p>\n<\/header>\n

    \n

    Designers bring their own habits, assumptions, and comfort levels into the work, and those can quietly steer the design. This activity asks you to examine those assumptions in yourself<\/p>\n

    Think about the last time you helped someone use a piece of technology\u2014a family member, a friend, a coworker. What did they struggle with that seemed obvious to you? Write a brief account of the situation: what was the task, where did they get stuck, and what did you have to explain?<\/p>\n

    Now flip it. Think about a piece of technology that you find frustrating or confusing, even though other people seem fine with it. Describe the friction: what do you expect to happen, and what actually happens?<\/p>\n

    Compare your experiences with a partner’s. What patterns emerge? When you helped someone else, what assumptions were you making about what \u201cshould be obvious\u201d? When you were the frustrated user, what assumptions did the designer seem to be making about you? How does this connect to the audience analysis work you practiced in Chapter 2.2?<\/p>\n<\/div>\n<\/div>\n

     <\/p>\n

    Technology as Rhetorical Genre<\/h1>\n

    One more rhetorical concept turns out to be especially handy for thinking about UX: genre<\/strong>. In rhetoric, genres aren\u2019t just categories based on shape or format. As Carolyn Miller argues<\/a>, genres are \u201ctypified responses\u201d to recurring situations.[3]<\/sup><\/a> A job application letter counts as a genre less because it has a standard structure and more because it\u2019s a recognized way of handling a familiar social moment: someone asks to be hired, and both sides have expectations about what that request should include and how it should sound.<\/p>\n

    You can take that same idea and apply it to digital products. A mobile banking app, a social media feed, a search results page: these are all responses to situations that keep coming up. People need to manage money without going to a branch. They want to share updates and keep tabs on friends or communities. They need to look things up quickly. Over time, designers build common solutions to those needs, and those solutions harden into patterns users come to expect. A new banking app doesn\u2019t start from zero; it gets compared to everything else people have used. If it can\u2019t do the basics, or if it hides them in weird places, users feel that friction immediately.<\/p>\n

    Seeing technology as genre gives you a few useful angles.<\/p>\n

    First, it makes it harder to pretend products are neutral. A technology is built to solve certain problems in certain settings. What it makes easy, what it makes annoying, what it requires you to do in what order, those are design decisions. They reflect assumptions about who the \u201cnormal\u201d user is, what they want, what they\u2019re willing to tolerate, and what the organization wants from them.<\/p>\n

    Second, genre helps explain why design conventions repeat. The shopping cart icon shows up across e-commerce sites because it\u2019s become a shared response to the recurring situation of buying online. It\u2019s not a law of nature; it\u2019s a convention that stuck because it works well enough and users learned it.<\/p>\n

    Thinking this way turns \u201cinterface critique\u201d into something broader. You\u2019re not just judging whether a screen looks clean; you\u2019re asking what kind of social situation the technology is built for, what expectations it relies on, and what it nudges people to do.<\/p>\n

    \n

    Analyzing Technology as Rhetorical Genre<\/strong><\/p>\n

    When examining a digital product as a rhetorical genre, consider:<\/p>\n

    Structural: <\/strong>What recurring design elements characterize this type of technology? What interface patterns appear consistently?<\/p>\n

    Substantive: <\/strong>What social actions does this technology enable? What purposes does it serve for users and organizations?<\/p>\n

    Contextual: <\/strong>When, where, and under what circumstances do people use this technology? What situational factors shape its use?<\/p>\n

    Critical: <\/strong>What assumptions about users does this technology embed? Whose needs does it serve well, and whose does it neglect?<\/p>\n<\/div>\n

    That last question of whose needs a technology serves well, and whose it ignores gets at the part of rhetorical analysis that\u2019s hardest to dodge. Technologies aren\u2019t neutral. Every design choice helps some people and makes things tougher for others. It can privilege certain workflows, certain bodies, certain languages, certain levels of time and attention. It can quietly assume a \u201cdefault\u201d user and treat everyone else as an edge case. Even decisions that seem purely technical (e.g., what gets prioritized, what\u2019s buried, what\u2019s required, etc.) end up reflecting values.<\/p>\n

    Noticing these issues isn\u2019t a reason to be cynical about design. It\u2019s a reason to take design seriously. When you see technologies as rhetorical artifacts, as objects shaped by human choices inside real organizational, economic, and cultural constraints, you also see that they can be changed. The current version isn\u2019t inevitable. It\u2019s a set of decisions that could have gone differently, and that can be revisited. That\u2019s where agency comes in: designers can push for alternatives, and users can demand better ones.<\/p>\n

    The rhetorical concepts in this section give you a vocabulary for doing that kind of analysis without drifting into vague criticism. They let you talk concretely about purpose, audience, message, context, and genre, and about what gets left out when those elements are defined too narrowly.<\/p>\n

    \n
    \n

    EXERCISE 6.4<\/strong>\u00a0 Analyze familiar technology through the lens of Genre<\/p>\n<\/header>\n

    \n

    We have used Caroline Miller’s concept of genre to argue that digital products are “typified responses to recurrent situations.” Let’s put that to the test.<\/p>\n

      \n
    1. Pick a common type of digital product: a search engine, a social media feed, an e-commerce checkout flow, a messaging app, a calendar tool, or anything else you use regularly.<\/li>\n
    2. Identify three to five design conventions that are shared across most products of this type. (For example: most e-commerce sites use a cart icon; most messaging apps put the newest messages at the bottom.) These are the genre\u2019s structural patterns.<\/li>\n
    3. Now find one place where a specific product breaks or modifies a convention. Describe the departure. Does it work? Does it create confusion? What might have motivated the designers to depart from the pattern?<\/li>\n
    4. Technologies are not completely \u201cneutral\u201d in that every design choice helps some people and makes things harder for others. Pick one of the conventions you identified and consider: whose needs does it serve well? Whose needs might it overlook?<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

       <\/p>\n

      Next, we\u2019ll move from that vocabulary to a more structured UX framework: Jesse James Garrett\u2019s five planes of user experience. It\u2019s a useful model for tracing how high-level goals and strategy turn into the actual screens, interactions, and content people deal with day to day.<\/p>\n

      1. H. Sun and G. Getto, \u201cLocalizing user experience: Strategies, practices, and technique for culturally sensitive design<\/a>,\u201d Technical Communications<\/em>, vol. 64 (2), May 2017. ↵<\/a><\/li>
      2. J. Sano-Fanchini, \u201cWhat can Asian eyelinds teach us about User Experience Design?<\/a> A culturally reflexive framework for UX\/I Design,\u201d Rhetoric, Professional Communication and Globalization<\/em>, vol. 10(1), 2017. ↵<\/a><\/li>
      3. C. R. Miller, \"Genre as social action.\" Quarterly Journal of Speech<\/em>, 70(2), pp.151\u2013167, 1984. https:\/\/doi.org\/10.1080\/00335638409383686 ↵<\/a><\/li><\/ol><\/div>","protected":false},"author":254,"menu_order":2,"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-421","chapter","type-chapter","status-publish","hentry","contributor-justin-lewis"],"part":412,"_links":{"self":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/421","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\/421\/revisions"}],"predecessor-version":[{"id":851,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/421\/revisions\/851"}],"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\/421\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/media?parent=421"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapter-type?post=421"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/contributor?post=421"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/license?post=421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}