{"id":436,"date":"2026-02-09T23:18:21","date_gmt":"2026-02-10T04:18:21","guid":{"rendered":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/?post_type=chapter&#038;p=436"},"modified":"2026-03-12T17:40:11","modified_gmt":"2026-03-12T21:40:11","slug":"6-3","status":"publish","type":"chapter","link":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/chapter\/6-3\/","title":{"raw":"6.3 The Five Planes of User Experience","rendered":"6.3 The Five Planes of User Experience"},"content":{"raw":"When you\u2019re told to design a digital product, it\u2019s tempting to start with the obvious stuff: what it should look like, what features it needs, maybe a quick list of screens. The problem is that starting there can produce a product that\u2019s nicely polished but oddly hollow. The UI might be attractive, the feature set might look impressive on paper, and people still end up feeling lost because no one sorted out, early on, who and what the product is really for, and how it\u2019s supposed to fit into a user\u2019s life.\r\n\r\nThat\u2019s why experienced UX designers lean on frameworks. A good framework keeps you from treating design as a pile of disconnected decisions. It forces you to work from the inside out: define the purpose, clarify what success looks like, and make sure each layer supports the one beneath it.\r\n\r\nJesse James Garrett\u2019s \u201cfive planes\u201d model, laid out in <a href=\"http:\/\/www.jjg.net\/elements\/\" target=\"_blank\" rel=\"noopener\"><em>The Elements of User Experience<\/em><\/a>,[footnote]J.J. Garrett, <em>The Elements of User Experience: User-Centred Design for the Web<\/em>. New York: American Institute of Graphic Arts, 2003[\/footnote] is one of the most widely used ways to do that. Garrett describes five levels of UX decisions, moving from the most abstract to the most concrete:\r\n<ul>\r\n \t<li><strong>Strategy<\/strong> (what we\u2019re trying to achieve, for users and for the organization)<\/li>\r\n \t<li><strong>Scope<\/strong> (what the product will and won\u2019t include)<\/li>\r\n \t<li><strong>Structure<\/strong> (how the experience is organized and how users move through it)<\/li>\r\n \t<li><strong>Skeleton<\/strong> (the arrangement of interface elements: layout, navigation, information design)<\/li>\r\n \t<li><strong>Surface<\/strong> (the final look and feel: visual design, styling, micro-interactions)<\/li>\r\n<\/ul>\r\nEach plane builds on the one below it. If you\u2019re unclear at the strategy level, everything above becomes guesswork. If the scope is bloated or inconsistent, structure turns into a maze. And if structure is shaky, no amount of surface-level polish will fix the experience. The value of the model is that it gives designers a shared map: a way to talk about where a problem really lives, and a way to keep \u201cmake it prettier\u201d from becoming the default solution to deeper confusion.\r\n\r\nBefore you dig into the five planes, Garrett asks you to notice a basic split in how digital products work: functionality and information:\r\n<p style=\"padding-left: 40px\"><strong>Functionality<\/strong>: the product is basically a tool for completing a task. People show up to do something: write in a word processor, build a spreadsheet, manage tasks in a project tool. Success looks like completing work efficiently, with as little friction as possible.<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Information<\/strong>: the product is mainly about information. News sites, library catalogues and corporate intranets help people find, understand, and use content. Here, success is about clear organization, easy discovery, and content that\u2019s legible and trustworthy.<\/p>\r\nMost real products are a blend. A banking app is a functional tool (pay bills, transfer funds) and an information source (check balances, review transactions). A university website provides information (program details, faculty pages) and also enables actions (registering for courses, submitting forms). Garrett\u2019s model still holds in mixed cases, but the way each \u201cplane\u201d shows up can look a little different depending on whether you\u2019re focusing on the product\u2019s tool side or its information side. As we move through the planes, it helps to keep both in view.\r\n<h2>Understanding the Five Planes<\/h2>\r\nGarrett\u2019s five planes work like a stack from an abstract foundation (strategy) to concrete surface.\r\n\r\n<img class=\"wp-image-427 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-1024x539.png\" alt=\"The five planes, in a pyramid, starting from the top: Surface, Skeleton, Structure, Scope and Strategy.\" width=\"1024\" height=\"539\" \/>A house-building analogy fits well if you don\u2019t push it too hard. You start with the reason for the house and who will live there (strategy). Then you decide what rooms you need and what features matter (scope). Next you plan how the rooms connect and flow (structure). After that you figure out the placement of doors, windows, and major fixtures (skeleton). Only then do you pick paint, materials, and finishes (surface). If you jump straight to paint colours before you know whether you need two bedrooms or four, you end up with a lot of expensive rework . . . or a house that looks fine but functions badly.\r\n<h3>The STRATEGY Plane: What is our Purpose?<\/h3>\r\nStrategy is the foundation: why the product exists, who it\u2019s for, and what success means.\u00a0 Think Purpose, Audience, and Goals, but in two connected contexts: What do <strong>users<\/strong> need from this product, and what does the <strong>organization<\/strong> need from it?\r\n\r\nThose answers aren\u2019t always compatible, and a lot of UX work is the process of finding a workable overlap: an experience that helps people accomplish what they came for while also supporting the organization\u2019s goals.\r\n<p style=\"padding-left: 40px\"><strong>User needs<\/strong> are the reasons people show up. What are they trying to get done? What problem are they trying to solve, or what information are they trying to confirm? You can\u2019t guess your way to reliable answers here. You need research like interviews, surveys, field observation, and usability testing. You also need the discipline to see the product from the user\u2019s point of view instead of your own. People don\u2019t use products the way teams imagine they will; they use them in the middle of messy lives, with limited patience and divided attention.<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Organizational objectives<\/strong> (business goals) are the other half of the picture. These might be revenue, fewer support tickets, higher retention, increased sign-ups, improved completion rates, stronger trust in the brand, the list goes on. The important thing is that objectives have to be specific enough to steer decisions. \u201cMake the product better\u201d doesn\u2019t help anyone decide what to build. \u201cReduce checkout time by 20%,\u201d \u201ccut password-reset requests in half,\u201d or \u201cincrease successful account onboarding\u201d gives you something you can test and measure.<\/p>\r\nThis is where the strategy plane connects directly to the rhetorical idea of purpose from <a href=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/chapter\/6-2-the-rhetorical-foundations-of-ux-design\/\" target=\"_blank\" rel=\"noopener\">Section 6.2<\/a>. Just as a document without a clear purpose tends to wander, a product without a clear strategy tends to sprawl. It tries to satisfy every possible user and every internal business request, and it ends up feeling scattered. It has lots of features, no clarity, and no strong reason for anyone to stick with it.\r\n<h3>The SCOPE Plane: What are We Building?<\/h3>\r\nOnce you\u2019ve nailed down strategy, the next step is scope: turning those big goals into a concrete list of what the product will actually deliver \u2013 and what it won\u2019t! Every project has limits: time, budget, technical constraints, staffing. If you try to include every feature someone suggests or cover every possible edge case, you usually end up with a product that feels bloated and harder to use. Good scope work means saying no (or \u201cnot yet\u201d) to ideas that are interesting but don\u2019t serve the strategy.\r\n\r\nScope is where \u201cwe want to help users do X\u201d turns into features, content, and requirements. On the functionality side, scope shows up as functional requirements, or, what the product will do. On the information side, it shows up as content requirements, or, what the product will contain, what topics it covers, what information users can expect to find.\r\n<h3>The STRUCTURE Plane: How Does it Fit Together?<\/h3>\r\nThe structure plane is where the things you decided to include (scope) get organized into a system that makes sense. It answers a basic question: how do all these pieces relate? It organizes the user experience and determines how things are arranged, and how the users will move through tasks (functionality) or information.\r\n<p style=\"padding-left: 40px\"><strong>Functionality<\/strong>: structure is about designing the user interactions. If someone taps a button, what happens next? Do they get immediate feedback? Is there a confirmation step? What does the system do when something goes wrong, or when the user tries an unexpected path? Interaction design is basically the rules of the conversation: what the product \u201csays\u201d in response to what the user does.<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Information architecture:<\/strong> The structure determines the underlying organization of content: categories, labels, navigation, and relationships between pages or sections. Information architecture asks questions like: What belongs together? What needs to be separated so it doesn\u2019t get confusing? What are the main pathways users will follow? If you\u2019ve ever been stuck clicking around a site that seems to hide the one thing you need in a random menu, you\u2019ve felt what weak information architecture looks like. Good information architecture is often invisible! Users simply find the content intuitive to navigate. Poor information architecture forces users to think about the system rather than their goals.<\/p>\r\n\r\n<h3>The SKELETON Plane: Where Does Everything Go?<\/h3>\r\nThe skeleton plane is where that theoretical blueprint of the structural plane gets translated into an actual screen layout. It\u2019s still not \u201cfinal design,\u201d but it\u2019s concrete enough that you can point to where things like navigation and interface elements will live and how people will use them.\r\n\r\nThree kinds of design work come together here:\r\n<p style=\"padding-left: 40px\"><strong>Interface design<\/strong> is about the controls people use to take action: buttons, form fields, dropdowns, toggles, sliders, and the other pieces that make functionality usable. Strong interface design makes it obvious what\u2019s clickable, what\u2019s editable, what\u2019s required, and what will happen next. It usually leans on patterns users already know, and it only introduces new ones when there\u2019s a real payoff.<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Navigation design<\/strong> is about movement through the product\u2019s content and sections: menus, links, tabs, breadcrumbs, search, site maps, and any \u201cyou are here\u201d cues that keep people oriented. There\u2019s always a tradeoff here. You want users to be able to reach everything, but you don\u2019t want to throw twenty options at them on every screen and call it clarity.<\/p>\r\n<p style=\"padding-left: 40px\"><strong>Information design<\/strong> is about how content is presented so it\u2019s easy to understand and act on. That includes the layout of text, the formatting of numbers and dates, the way data is visualized, what gets emphasized, and how the interface signals meaning. This is where a lot of document-design skills transfer directly: hierarchy, chunking, alignment, consistency, and using visuals with a purpose.<\/p>\r\nDesigners often capture the skeleton plane with wireframes (see <strong>Figure 6.3.1<\/strong>). These simple page diagrams show layout and placement without the \u201csurface\u201d details like colours, photography, or polished typography. The point is to keep the conversation focused on whether the arrangement supports user tasks before the team spends time perfecting the look.\r\n\r\n&nbsp;\r\n\r\n[caption id=\"attachment_428\" align=\"alignnone\" width=\"1024\"]<img class=\"wp-image-428 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-1024x834.png\" alt=\"An annotated wireframe of a simple web page showing: header with logo and main navigation (labeled 'Navigation Design'), a form with input fields and buttons (labeled 'Interface Design'), and a content area with headings and text blocks (labeled 'Information Design'). Annotations point to specific elements explaining their purpose.\" width=\"1024\" height=\"834\" \/> <strong>Figure 6.3.1<\/strong> Sample Wireframe Showing Interface, Navigation, and Information Design[\/caption]\r\n<h3>The SURFACE Plane: What Do Users See?<\/h3>\r\nAt the top of Garrett\u2019s model is the surface plane, the part of the experience users actually perceive: the visual design, typography, colour palette, spacing, imagery, and sensory layer of the interface. In some products, this might also include motion, sound, and haptics (touch).\r\n\r\nIt\u2019s easy to treat the surface as \u201cthe important part\u201d because it\u2019s what people notice first. Garrett puts it last on purpose. Surface design sits on top of everything else and depends on it. A gorgeous interface can\u2019t rescue a product with a muddled <em>strategy<\/em> or a <em>structure<\/em> that sends users in circles. On the flip side, when the foundation is solid and includes clear <em>strategy<\/em>, disciplined <em>scope<\/em>, sensible <em>structure<\/em>, a workable <em>skeleton<\/em>, etc., the product can still succeed even if the visuals are a bit rough around the edges. Function can carry you farther than people expect.\r\n\r\nStill, surface design isn\u2019t decoration. It\u2019s part of the visual rhetoric that shapes how people move through the product moment to moment. Visual hierarchy tells users what to look at first and what can wait. Consistent styling helps people build trust in the interface: if two elements look the same, users assume they behave the same. Typography affects readability and scanning. Color can set mood and also communicate meaning (errors, warnings, success states). The same layout principles you\u2019ve learned for documents, including contrast, alignment, proximity, repetition, show up here too, just translated into screens.\r\n\r\nAnd \u201csurface\u201d can mean more than sight. Motion matters: do animations feel smooth and informative, or do they slow users down and pull attention away from the task? Sound matters in some contexts: is it helpful feedback or unwanted noise? On a mobile device, haptics can either reassure users (\u201cyour action registered\u201d) or annoy them if overused. These details don\u2019t replace good structure, but they do change the feel of the experience. They\u2019re often the difference between a product that seems carefully made and one that feels slightly sloppy, even if the features are the same.\r\n<h2>Working with the Five Planes<\/h2>\r\nGarrett is careful to say the five planes are a way of thinking, not a step-by-step recipe. Real projects don\u2019t move neatly from strategy to surface in a straight line. Work overlaps, and you often learn things \u201clate\u201d that force you to go back and adjust earlier decisions.\r\n\r\nThat\u2019s normal. A designer building wireframes at the skeleton level might suddenly notice that a key task takes too many steps, which points back to a structure problem: the information architecture isn\u2019t supporting what users are trying to do. Or a visual exploration at the surface level might expose something more fundamental: there are simply too many features to present clearly. Based on this feedback, the team has to revisit scope and cut or postpone work.\r\n\r\nThe value of the model is that it gives you a grounding rule: decisions at each level should make sense given the levels underneath. Before you lock in surface design, you should have confidence in the skeleton. Before you lock in the skeleton, you should understand the structure. Before you finalize structure, you need a clear scope. And before you commit to scope, you need strategy: why this product exists and who it\u2019s meant to serve.\r\n\r\nThat discipline is what helps teams avoid a classic trap: picking solutions early (a layout, a feature, a visual style) before they\u2019ve really understood the problem they\u2019re trying to solve.\r\n<div class=\"textbox textbox--examples\"><header class=\"textbox__header\"><strong>EXAMPLE:\u00a0 Applying the Five Planes to A Library Website Redesign<\/strong><\/header>\r\n<div class=\"textbox__content\">\r\n\r\n<strong>Strategy: <\/strong>User research reveals that students primarily need to find and access resources quickly, often on mobile devices between classes. The library's goal is to increase digital resource usage and reduce in-person reference questions.\r\n\r\n<strong>Scope: <\/strong>The redesigned site will include: search (books, articles, databases), account management (renewals, holds), research guides by subject, and library hours\/locations. Features like event calendars and staff directories are deprioritized.\r\n\r\n<strong>Structure: <\/strong>Information architecture organizes content around user tasks (Find, Borrow, Get Help) rather than library departments. Search is integrated across resource types.\r\n\r\n<strong>Skeleton: <\/strong>Wireframes place a prominent search box at the top of every page. Mobile layouts prioritize search and account functions, with secondary content accessible through a menu.\r\n\r\n<strong>Surface: <\/strong>Visual design uses university brand colors, clear typography optimized for screen reading, and minimal decoration to keep focus on functionality.\r\n\r\n<\/div>\r\n<\/div>\r\n<h2>From Framework To Practice<\/h2>\r\nGarrett\u2019s five planes work in two directions at once. They\u2019re a thinking tool, because they help you sort decisions by level and keep you from treating UX as a grab bag of screens and features. And they\u2019re a communication tool, because they give teams a shared set of terms. This is especially useful when you\u2019re talking with colleagues, clients, or stakeholders who don\u2019t speak \u201cdesign\u201d fluently but still need to weigh in on what\u2019s being built.\r\n\r\nFor students of technical communication, the model should feel familiar. It reinforces the same basic discipline you\u2019ve practiced in writing: you start by getting clear on purpose and audience, then you make choices about what to include, how to organize it, and how to present it. And the process is likely iterative, forcing you to revisit previous steps as needed. Working from strategy through surface mirrors the process of working from task analysis through document design. In both cases, the aim is the same: build something that fits what people actually need, not what the creator assumes they need.\r\n\r\n&nbsp;\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>EXERCISE 6.5<\/strong>\u00a0 Diagnosing Problems within the 5 Planes<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nGarrett\u2019s model argues that problems at lower planes (strategy, scope) can\u2019t be fixed by work at higher planes (skeleton, surface). This exercise asks you to practice diagnosing where a problem really lives.\r\n\r\nRead each scenario below. For each one, identify\r\n<p style=\"padding-left: 40px\">(a) which plane the core problem belongs to\r\n(b) explain your reasoning in one to two sentences.<\/p>\r\nSome scenarios may involve more than one plane; if so, identify the deepest one (the one closest to strategy), since fixing it there will likely resolve the higher-level symptoms.\r\n<ol>\r\n \t<li>A university\u2019s course registration portal lets students add courses to a cart, but there\u2019s no clear way to see whether a course conflicts with their existing schedule until after they try to enroll.<\/li>\r\n \t<li>An employee onboarding app has a clean, modern visual style but organizes content by department rather than by task, so new hires can\u2019t figure out the sequence of steps they need to complete.<\/li>\r\n \t<li>A city transit app shows real-time bus locations, but the icons and text are so small on mobile that riders can\u2019t read route numbers without zooming in.<\/li>\r\n \t<li>A hospital patient portal was designed to help patients manage prescriptions, but it was never tested with elderly users, who make up 60% of the patient base. The team only realized this after launch.<\/li>\r\n \t<li>A nonprofit\u2019s website has a prominent \u201cDonate\u201d button and an elegant donation flow, but the organization\u2019s actual goal for the site was volunteer recruitment. Donations aren\u2019t the problem\u2014nobody can find the volunteer sign-up page.<\/li>\r\n<\/ol>\r\nCompare your answers with a partner. Where did you disagree? What made certain scenarios harder to pin to a single plane? How does this exercise change the way you might approach giving feedback on a design?\r\n\r\n&nbsp;\r\n\r\n<\/div>\r\n<\/div>\r\n&nbsp;\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>EXERCISE 6.6<\/strong>\u00a0 Defining a UX Problem<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nUse the Hyman Problem Formulation framework, applied to the Strategy Plan to define a UX problem.\r\n\r\nChoose a real digital product or service you\u2019ve found frustrating:\u00a0 Your university\u2019s website, a government services portal, a workplace tool, an app you\u2019ve given up on\u2014anything you have firsthand experience with. Define the UX problem using the Hyman framework below (remember, you are defining the problem; do not propose solutions yet).\r\n<ul>\r\n \t<li><strong>Need\/Unsatisfactory Situation<\/strong>: What is the current experience like? What\u2019s going wrong for users? Be specific about what you\u2019ve observed or experienced.<\/li>\r\n \t<li><strong>User Goals:<\/strong> What are users trying to accomplish when they use this product?<\/li>\r\n \t<li><strong>Organizational Goals<\/strong>: What does the organization behind the product likely want the product to achieve?<\/li>\r\n \t<li><strong>Measurable Objectives:<\/strong> If you were going to improve this product, what specific, measurable outcomes would tell you the improvement was working? (e.g., \u201creduce average task completion time,\u201d \u201cincrease successful form submissions,\u201d \u201cdecrease support requests about X\u201d)<\/li>\r\n \t<li><strong>Constraints<\/strong>: What limits would any solution have to respect? Consider budget, technology, legal requirements, accessibility standards, existing user expectations, and organizational politics.<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\n&nbsp;\r\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\r\n<p class=\"textbox__title\"><strong>EXERCISE 6.7\u00a0<\/strong> Negotiating Scope: What gets cut?<\/p>\r\n\r\n<\/header>\r\n<div class=\"textbox__content\">\r\n\r\nGarrett emphasizes that scope is as much about what you leave out as what you include. This exercise gives you practice with that tradeoff.\r\n\r\nImagine you are redesigning your school\u2019s library website. The team has brainstormed the following feature and content ideas. However, due to budget and timeline constraints, you can only include 6 of the 10 items in the first release. The rest will have to wait. Here are the 10 features:\r\n<ul>\r\n \t<li>Search the full catalog by keyword, title, author, or subject<\/li>\r\n \t<li>Real-time availability for each item (checked out or on the shelf)<\/li>\r\n \t<li>User account page showing items checked out, holds, and due dates<\/li>\r\n \t<li>Online reservation system for study rooms<\/li>\r\n \t<li>Interactive floor map showing where each call number range is shelved<\/li>\r\n \t<li>Integration with the campus course management system so students can see items on reserve for their courses<\/li>\r\n \t<li>Blog with librarian-curated reading recommendations<\/li>\r\n \t<li>FAQ and help documentation for using library databases<\/li>\r\n \t<li>Event calendar for workshops, guest speakers, and exhibits<\/li>\r\n \t<li>Accessibility checker that lets users report barriers on any page<\/li>\r\n<\/ul>\r\n<strong><em>Your task:\u00a0 <\/em><\/strong>Choose the 6 items you would keep for the first release.\r\n\r\nFor each item you keep, write one sentence explaining why it belongs in the first release, connected to what you understand about user needs and organizational goals.\r\n\r\nFor each item you cut, write one sentence explaining why it can wait.\r\n\r\nCompare your choices with a partner or group. Did you make the same cuts? What principles guided your decisions? How did you weigh user needs against organizational goals? Did anyone argue for keeping the accessibility checker as a first-release priority, and if so, on what grounds?\r\n\r\n<\/div>\r\n<\/div>\r\n&nbsp;\r\n\r\nOf course, a framework is only helpful if you can use it. That\u2019s where methods come in. Research methods are the hands-on techniques that let you learn about users, test ideas, and improve what you\u2019ve made. In the next section, we\u2019ll look at research methods that support the UX process. Many of these approaches come straight from qualitative research traditions in technical communication, adapted for the realities of interactive digital products.\r\n\r\n&nbsp;","rendered":"<p>When you\u2019re told to design a digital product, it\u2019s tempting to start with the obvious stuff: what it should look like, what features it needs, maybe a quick list of screens. The problem is that starting there can produce a product that\u2019s nicely polished but oddly hollow. The UI might be attractive, the feature set might look impressive on paper, and people still end up feeling lost because no one sorted out, early on, who and what the product is really for, and how it\u2019s supposed to fit into a user\u2019s life.<\/p>\n<p>That\u2019s why experienced UX designers lean on frameworks. A good framework keeps you from treating design as a pile of disconnected decisions. It forces you to work from the inside out: define the purpose, clarify what success looks like, and make sure each layer supports the one beneath it.<\/p>\n<p>Jesse James Garrett\u2019s \u201cfive planes\u201d model, laid out in <a href=\"http:\/\/www.jjg.net\/elements\/\" target=\"_blank\" rel=\"noopener\"><em>The Elements of User Experience<\/em><\/a>,<a class=\"footnote\" title=\"J.J. Garrett, The Elements of User Experience: User-Centred Design for the Web. New York: American Institute of Graphic Arts, 2003\" id=\"return-footnote-436-1\" href=\"#footnote-436-1\" aria-label=\"Footnote 1\"><sup class=\"footnote\">[1]<\/sup><\/a> is one of the most widely used ways to do that. Garrett describes five levels of UX decisions, moving from the most abstract to the most concrete:<\/p>\n<ul>\n<li><strong>Strategy<\/strong> (what we\u2019re trying to achieve, for users and for the organization)<\/li>\n<li><strong>Scope<\/strong> (what the product will and won\u2019t include)<\/li>\n<li><strong>Structure<\/strong> (how the experience is organized and how users move through it)<\/li>\n<li><strong>Skeleton<\/strong> (the arrangement of interface elements: layout, navigation, information design)<\/li>\n<li><strong>Surface<\/strong> (the final look and feel: visual design, styling, micro-interactions)<\/li>\n<\/ul>\n<p>Each plane builds on the one below it. If you\u2019re unclear at the strategy level, everything above becomes guesswork. If the scope is bloated or inconsistent, structure turns into a maze. And if structure is shaky, no amount of surface-level polish will fix the experience. The value of the model is that it gives designers a shared map: a way to talk about where a problem really lives, and a way to keep \u201cmake it prettier\u201d from becoming the default solution to deeper confusion.<\/p>\n<p>Before you dig into the five planes, Garrett asks you to notice a basic split in how digital products work: functionality and information:<\/p>\n<p style=\"padding-left: 40px\"><strong>Functionality<\/strong>: the product is basically a tool for completing a task. People show up to do something: write in a word processor, build a spreadsheet, manage tasks in a project tool. Success looks like completing work efficiently, with as little friction as possible.<\/p>\n<p style=\"padding-left: 40px\"><strong>Information<\/strong>: the product is mainly about information. News sites, library catalogues and corporate intranets help people find, understand, and use content. Here, success is about clear organization, easy discovery, and content that\u2019s legible and trustworthy.<\/p>\n<p>Most real products are a blend. A banking app is a functional tool (pay bills, transfer funds) and an information source (check balances, review transactions). A university website provides information (program details, faculty pages) and also enables actions (registering for courses, submitting forms). Garrett\u2019s model still holds in mixed cases, but the way each \u201cplane\u201d shows up can look a little different depending on whether you\u2019re focusing on the product\u2019s tool side or its information side. As we move through the planes, it helps to keep both in view.<\/p>\n<h2>Understanding the Five Planes<\/h2>\n<p>Garrett\u2019s five planes work like a stack from an abstract foundation (strategy) to concrete surface.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-427 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-1024x539.png\" alt=\"The five planes, in a pyramid, starting from the top: Surface, Skeleton, Structure, Scope and Strategy.\" width=\"1024\" height=\"539\" srcset=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-1024x539.png 1024w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-300x158.png 300w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-768x404.png 768w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-1536x809.png 1536w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-65x34.png 65w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-225x118.png 225w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes-350x184.png 350w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Garretts-Five-Planes.png 1706w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/>A house-building analogy fits well if you don\u2019t push it too hard. You start with the reason for the house and who will live there (strategy). Then you decide what rooms you need and what features matter (scope). Next you plan how the rooms connect and flow (structure). After that you figure out the placement of doors, windows, and major fixtures (skeleton). Only then do you pick paint, materials, and finishes (surface). If you jump straight to paint colours before you know whether you need two bedrooms or four, you end up with a lot of expensive rework . . . or a house that looks fine but functions badly.<\/p>\n<h3>The STRATEGY Plane: What is our Purpose?<\/h3>\n<p>Strategy is the foundation: why the product exists, who it\u2019s for, and what success means.\u00a0 Think Purpose, Audience, and Goals, but in two connected contexts: What do <strong>users<\/strong> need from this product, and what does the <strong>organization<\/strong> need from it?<\/p>\n<p>Those answers aren\u2019t always compatible, and a lot of UX work is the process of finding a workable overlap: an experience that helps people accomplish what they came for while also supporting the organization\u2019s goals.<\/p>\n<p style=\"padding-left: 40px\"><strong>User needs<\/strong> are the reasons people show up. What are they trying to get done? What problem are they trying to solve, or what information are they trying to confirm? You can\u2019t guess your way to reliable answers here. You need research like interviews, surveys, field observation, and usability testing. You also need the discipline to see the product from the user\u2019s point of view instead of your own. People don\u2019t use products the way teams imagine they will; they use them in the middle of messy lives, with limited patience and divided attention.<\/p>\n<p style=\"padding-left: 40px\"><strong>Organizational objectives<\/strong> (business goals) are the other half of the picture. These might be revenue, fewer support tickets, higher retention, increased sign-ups, improved completion rates, stronger trust in the brand, the list goes on. The important thing is that objectives have to be specific enough to steer decisions. \u201cMake the product better\u201d doesn\u2019t help anyone decide what to build. \u201cReduce checkout time by 20%,\u201d \u201ccut password-reset requests in half,\u201d or \u201cincrease successful account onboarding\u201d gives you something you can test and measure.<\/p>\n<p>This is where the strategy plane connects directly to the rhetorical idea of purpose from <a href=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/chapter\/6-2-the-rhetorical-foundations-of-ux-design\/\" target=\"_blank\" rel=\"noopener\">Section 6.2<\/a>. Just as a document without a clear purpose tends to wander, a product without a clear strategy tends to sprawl. It tries to satisfy every possible user and every internal business request, and it ends up feeling scattered. It has lots of features, no clarity, and no strong reason for anyone to stick with it.<\/p>\n<h3>The SCOPE Plane: What are We Building?<\/h3>\n<p>Once you\u2019ve nailed down strategy, the next step is scope: turning those big goals into a concrete list of what the product will actually deliver \u2013 and what it won\u2019t! Every project has limits: time, budget, technical constraints, staffing. If you try to include every feature someone suggests or cover every possible edge case, you usually end up with a product that feels bloated and harder to use. Good scope work means saying no (or \u201cnot yet\u201d) to ideas that are interesting but don\u2019t serve the strategy.<\/p>\n<p>Scope is where \u201cwe want to help users do X\u201d turns into features, content, and requirements. On the functionality side, scope shows up as functional requirements, or, what the product will do. On the information side, it shows up as content requirements, or, what the product will contain, what topics it covers, what information users can expect to find.<\/p>\n<h3>The STRUCTURE Plane: How Does it Fit Together?<\/h3>\n<p>The structure plane is where the things you decided to include (scope) get organized into a system that makes sense. It answers a basic question: how do all these pieces relate? It organizes the user experience and determines how things are arranged, and how the users will move through tasks (functionality) or information.<\/p>\n<p style=\"padding-left: 40px\"><strong>Functionality<\/strong>: structure is about designing the user interactions. If someone taps a button, what happens next? Do they get immediate feedback? Is there a confirmation step? What does the system do when something goes wrong, or when the user tries an unexpected path? Interaction design is basically the rules of the conversation: what the product \u201csays\u201d in response to what the user does.<\/p>\n<p style=\"padding-left: 40px\"><strong>Information architecture:<\/strong> The structure determines the underlying organization of content: categories, labels, navigation, and relationships between pages or sections. Information architecture asks questions like: What belongs together? What needs to be separated so it doesn\u2019t get confusing? What are the main pathways users will follow? If you\u2019ve ever been stuck clicking around a site that seems to hide the one thing you need in a random menu, you\u2019ve felt what weak information architecture looks like. Good information architecture is often invisible! Users simply find the content intuitive to navigate. Poor information architecture forces users to think about the system rather than their goals.<\/p>\n<h3>The SKELETON Plane: Where Does Everything Go?<\/h3>\n<p>The skeleton plane is where that theoretical blueprint of the structural plane gets translated into an actual screen layout. It\u2019s still not \u201cfinal design,\u201d but it\u2019s concrete enough that you can point to where things like navigation and interface elements will live and how people will use them.<\/p>\n<p>Three kinds of design work come together here:<\/p>\n<p style=\"padding-left: 40px\"><strong>Interface design<\/strong> is about the controls people use to take action: buttons, form fields, dropdowns, toggles, sliders, and the other pieces that make functionality usable. Strong interface design makes it obvious what\u2019s clickable, what\u2019s editable, what\u2019s required, and what will happen next. It usually leans on patterns users already know, and it only introduces new ones when there\u2019s a real payoff.<\/p>\n<p style=\"padding-left: 40px\"><strong>Navigation design<\/strong> is about movement through the product\u2019s content and sections: menus, links, tabs, breadcrumbs, search, site maps, and any \u201cyou are here\u201d cues that keep people oriented. There\u2019s always a tradeoff here. You want users to be able to reach everything, but you don\u2019t want to throw twenty options at them on every screen and call it clarity.<\/p>\n<p style=\"padding-left: 40px\"><strong>Information design<\/strong> is about how content is presented so it\u2019s easy to understand and act on. That includes the layout of text, the formatting of numbers and dates, the way data is visualized, what gets emphasized, and how the interface signals meaning. This is where a lot of document-design skills transfer directly: hierarchy, chunking, alignment, consistency, and using visuals with a purpose.<\/p>\n<p>Designers often capture the skeleton plane with wireframes (see <strong>Figure 6.3.1<\/strong>). These simple page diagrams show layout and placement without the \u201csurface\u201d details like colours, photography, or polished typography. The point is to keep the conversation focused on whether the arrangement supports user tasks before the team spends time perfecting the look.<\/p>\n<p>&nbsp;<\/p>\n<figure id=\"attachment_428\" aria-describedby=\"caption-attachment-428\" style=\"width: 1024px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-428 size-large\" src=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-1024x834.png\" alt=\"An annotated wireframe of a simple web page showing: header with logo and main navigation (labeled 'Navigation Design'), a form with input fields and buttons (labeled 'Interface Design'), and a content area with headings and text blocks (labeled 'Information Design'). Annotations point to specific elements explaining their purpose.\" width=\"1024\" height=\"834\" srcset=\"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-1024x834.png 1024w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-300x244.png 300w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-768x626.png 768w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-1536x1251.png 1536w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-65x53.png 65w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-225x183.png 225w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe-350x285.png 350w, https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-content\/uploads\/sites\/2569\/2026\/02\/Sample-Wireframe.png 1586w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption id=\"caption-attachment-428\" class=\"wp-caption-text\"><strong>Figure 6.3.1<\/strong> Sample Wireframe Showing Interface, Navigation, and Information Design<\/figcaption><\/figure>\n<h3>The SURFACE Plane: What Do Users See?<\/h3>\n<p>At the top of Garrett\u2019s model is the surface plane, the part of the experience users actually perceive: the visual design, typography, colour palette, spacing, imagery, and sensory layer of the interface. In some products, this might also include motion, sound, and haptics (touch).<\/p>\n<p>It\u2019s easy to treat the surface as \u201cthe important part\u201d because it\u2019s what people notice first. Garrett puts it last on purpose. Surface design sits on top of everything else and depends on it. A gorgeous interface can\u2019t rescue a product with a muddled <em>strategy<\/em> or a <em>structure<\/em> that sends users in circles. On the flip side, when the foundation is solid and includes clear <em>strategy<\/em>, disciplined <em>scope<\/em>, sensible <em>structure<\/em>, a workable <em>skeleton<\/em>, etc., the product can still succeed even if the visuals are a bit rough around the edges. Function can carry you farther than people expect.<\/p>\n<p>Still, surface design isn\u2019t decoration. It\u2019s part of the visual rhetoric that shapes how people move through the product moment to moment. Visual hierarchy tells users what to look at first and what can wait. Consistent styling helps people build trust in the interface: if two elements look the same, users assume they behave the same. Typography affects readability and scanning. Color can set mood and also communicate meaning (errors, warnings, success states). The same layout principles you\u2019ve learned for documents, including contrast, alignment, proximity, repetition, show up here too, just translated into screens.<\/p>\n<p>And \u201csurface\u201d can mean more than sight. Motion matters: do animations feel smooth and informative, or do they slow users down and pull attention away from the task? Sound matters in some contexts: is it helpful feedback or unwanted noise? On a mobile device, haptics can either reassure users (\u201cyour action registered\u201d) or annoy them if overused. These details don\u2019t replace good structure, but they do change the feel of the experience. They\u2019re often the difference between a product that seems carefully made and one that feels slightly sloppy, even if the features are the same.<\/p>\n<h2>Working with the Five Planes<\/h2>\n<p>Garrett is careful to say the five planes are a way of thinking, not a step-by-step recipe. Real projects don\u2019t move neatly from strategy to surface in a straight line. Work overlaps, and you often learn things \u201clate\u201d that force you to go back and adjust earlier decisions.<\/p>\n<p>That\u2019s normal. A designer building wireframes at the skeleton level might suddenly notice that a key task takes too many steps, which points back to a structure problem: the information architecture isn\u2019t supporting what users are trying to do. Or a visual exploration at the surface level might expose something more fundamental: there are simply too many features to present clearly. Based on this feedback, the team has to revisit scope and cut or postpone work.<\/p>\n<p>The value of the model is that it gives you a grounding rule: decisions at each level should make sense given the levels underneath. Before you lock in surface design, you should have confidence in the skeleton. Before you lock in the skeleton, you should understand the structure. Before you finalize structure, you need a clear scope. And before you commit to scope, you need strategy: why this product exists and who it\u2019s meant to serve.<\/p>\n<p>That discipline is what helps teams avoid a classic trap: picking solutions early (a layout, a feature, a visual style) before they\u2019ve really understood the problem they\u2019re trying to solve.<\/p>\n<div class=\"textbox textbox--examples\">\n<header class=\"textbox__header\"><strong>EXAMPLE:\u00a0 Applying the Five Planes to A Library Website Redesign<\/strong><\/header>\n<div class=\"textbox__content\">\n<p><strong>Strategy: <\/strong>User research reveals that students primarily need to find and access resources quickly, often on mobile devices between classes. The library&#8217;s goal is to increase digital resource usage and reduce in-person reference questions.<\/p>\n<p><strong>Scope: <\/strong>The redesigned site will include: search (books, articles, databases), account management (renewals, holds), research guides by subject, and library hours\/locations. Features like event calendars and staff directories are deprioritized.<\/p>\n<p><strong>Structure: <\/strong>Information architecture organizes content around user tasks (Find, Borrow, Get Help) rather than library departments. Search is integrated across resource types.<\/p>\n<p><strong>Skeleton: <\/strong>Wireframes place a prominent search box at the top of every page. Mobile layouts prioritize search and account functions, with secondary content accessible through a menu.<\/p>\n<p><strong>Surface: <\/strong>Visual design uses university brand colors, clear typography optimized for screen reading, and minimal decoration to keep focus on functionality.<\/p>\n<\/div>\n<\/div>\n<h2>From Framework To Practice<\/h2>\n<p>Garrett\u2019s five planes work in two directions at once. They\u2019re a thinking tool, because they help you sort decisions by level and keep you from treating UX as a grab bag of screens and features. And they\u2019re a communication tool, because they give teams a shared set of terms. This is especially useful when you\u2019re talking with colleagues, clients, or stakeholders who don\u2019t speak \u201cdesign\u201d fluently but still need to weigh in on what\u2019s being built.<\/p>\n<p>For students of technical communication, the model should feel familiar. It reinforces the same basic discipline you\u2019ve practiced in writing: you start by getting clear on purpose and audience, then you make choices about what to include, how to organize it, and how to present it. And the process is likely iterative, forcing you to revisit previous steps as needed. Working from strategy through surface mirrors the process of working from task analysis through document design. In both cases, the aim is the same: build something that fits what people actually need, not what the creator assumes they need.<\/p>\n<p>&nbsp;<\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>EXERCISE 6.5<\/strong>\u00a0 Diagnosing Problems within the 5 Planes<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>Garrett\u2019s model argues that problems at lower planes (strategy, scope) can\u2019t be fixed by work at higher planes (skeleton, surface). This exercise asks you to practice diagnosing where a problem really lives.<\/p>\n<p>Read each scenario below. For each one, identify<\/p>\n<p style=\"padding-left: 40px\">(a) which plane the core problem belongs to<br \/>\n(b) explain your reasoning in one to two sentences.<\/p>\n<p>Some scenarios may involve more than one plane; if so, identify the deepest one (the one closest to strategy), since fixing it there will likely resolve the higher-level symptoms.<\/p>\n<ol>\n<li>A university\u2019s course registration portal lets students add courses to a cart, but there\u2019s no clear way to see whether a course conflicts with their existing schedule until after they try to enroll.<\/li>\n<li>An employee onboarding app has a clean, modern visual style but organizes content by department rather than by task, so new hires can\u2019t figure out the sequence of steps they need to complete.<\/li>\n<li>A city transit app shows real-time bus locations, but the icons and text are so small on mobile that riders can\u2019t read route numbers without zooming in.<\/li>\n<li>A hospital patient portal was designed to help patients manage prescriptions, but it was never tested with elderly users, who make up 60% of the patient base. The team only realized this after launch.<\/li>\n<li>A nonprofit\u2019s website has a prominent \u201cDonate\u201d button and an elegant donation flow, but the organization\u2019s actual goal for the site was volunteer recruitment. Donations aren\u2019t the problem\u2014nobody can find the volunteer sign-up page.<\/li>\n<\/ol>\n<p>Compare your answers with a partner. Where did you disagree? What made certain scenarios harder to pin to a single plane? How does this exercise change the way you might approach giving feedback on a design?<\/p>\n<p>&nbsp;<\/p>\n<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>EXERCISE 6.6<\/strong>\u00a0 Defining a UX Problem<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>Use the Hyman Problem Formulation framework, applied to the Strategy Plan to define a UX problem.<\/p>\n<p>Choose a real digital product or service you\u2019ve found frustrating:\u00a0 Your university\u2019s website, a government services portal, a workplace tool, an app you\u2019ve given up on\u2014anything you have firsthand experience with. Define the UX problem using the Hyman framework below (remember, you are defining the problem; do not propose solutions yet).<\/p>\n<ul>\n<li><strong>Need\/Unsatisfactory Situation<\/strong>: What is the current experience like? What\u2019s going wrong for users? Be specific about what you\u2019ve observed or experienced.<\/li>\n<li><strong>User Goals:<\/strong> What are users trying to accomplish when they use this product?<\/li>\n<li><strong>Organizational Goals<\/strong>: What does the organization behind the product likely want the product to achieve?<\/li>\n<li><strong>Measurable Objectives:<\/strong> If you were going to improve this product, what specific, measurable outcomes would tell you the improvement was working? (e.g., \u201creduce average task completion time,\u201d \u201cincrease successful form submissions,\u201d \u201cdecrease support requests about X\u201d)<\/li>\n<li><strong>Constraints<\/strong>: What limits would any solution have to respect? Consider budget, technology, legal requirements, accessibility standards, existing user expectations, and organizational politics.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>EXERCISE 6.7\u00a0<\/strong> Negotiating Scope: What gets cut?<\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p>Garrett emphasizes that scope is as much about what you leave out as what you include. This exercise gives you practice with that tradeoff.<\/p>\n<p>Imagine you are redesigning your school\u2019s library website. The team has brainstormed the following feature and content ideas. However, due to budget and timeline constraints, you can only include 6 of the 10 items in the first release. The rest will have to wait. Here are the 10 features:<\/p>\n<ul>\n<li>Search the full catalog by keyword, title, author, or subject<\/li>\n<li>Real-time availability for each item (checked out or on the shelf)<\/li>\n<li>User account page showing items checked out, holds, and due dates<\/li>\n<li>Online reservation system for study rooms<\/li>\n<li>Interactive floor map showing where each call number range is shelved<\/li>\n<li>Integration with the campus course management system so students can see items on reserve for their courses<\/li>\n<li>Blog with librarian-curated reading recommendations<\/li>\n<li>FAQ and help documentation for using library databases<\/li>\n<li>Event calendar for workshops, guest speakers, and exhibits<\/li>\n<li>Accessibility checker that lets users report barriers on any page<\/li>\n<\/ul>\n<p><strong><em>Your task:\u00a0 <\/em><\/strong>Choose the 6 items you would keep for the first release.<\/p>\n<p>For each item you keep, write one sentence explaining why it belongs in the first release, connected to what you understand about user needs and organizational goals.<\/p>\n<p>For each item you cut, write one sentence explaining why it can wait.<\/p>\n<p>Compare your choices with a partner or group. Did you make the same cuts? What principles guided your decisions? How did you weigh user needs against organizational goals? Did anyone argue for keeping the accessibility checker as a first-release priority, and if so, on what grounds?<\/p>\n<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<p>Of course, a framework is only helpful if you can use it. That\u2019s where methods come in. Research methods are the hands-on techniques that let you learn about users, test ideas, and improve what you\u2019ve made. In the next section, we\u2019ll look at research methods that support the UX process. Many of these approaches come straight from qualitative research traditions in technical communication, adapted for the realities of interactive digital products.<\/p>\n<p>&nbsp;<\/p>\n<hr class=\"before-footnotes clear\" \/><div class=\"footnotes\"><ol><li id=\"footnote-436-1\">J.J. Garrett, <em>The Elements of User Experience: User-Centred Design for the Web<\/em>. New York: American Institute of Graphic Arts, 2003 <a href=\"#return-footnote-436-1\" class=\"return-footnote\" aria-label=\"Return to footnote 1\">&crarr;<\/a><\/li><\/ol><\/div>","protected":false},"author":254,"menu_order":3,"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-436","chapter","type-chapter","status-publish","hentry","contributor-justin-lewis"],"part":412,"_links":{"self":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/436","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":8,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/436\/revisions"}],"predecessor-version":[{"id":779,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapters\/436\/revisions\/779"}],"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\/436\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/media?parent=436"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/pressbooks\/v2\/chapter-type?post=436"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/contributor?post=436"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/technicalwriting2ed\/wp-json\/wp\/v2\/license?post=436"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}