Оценка на читателите: / 9
Слаба статияОтлична статия 

Новини от света на уеб дизайна и СЕО

Представям Ви синдикирани новини от няколко от водещите сайтове в областта на уеб дизайна и СЕО - оптимизирането за търсачки.

A List Apart: The Full Feed
Articles for people who make web sites.
  • Responsible JavaScript: Part II

    You and the rest of the dev team lobbied enthusiastically for a total re-architecture of the company’s aging website. Your pleas were heard by management—even up to the C-suite—who gave the green light. Elated, you and the team started working with the design, copy, and IA teams. Before long, you were banging out new code.

    It started out innocently enough with an npm install here and an npm install there. Before you knew it, though, you were installing production dependencies like an undergrad doing keg stands without a care for the morning after.

    Then you launched.

    Unlike the aftermath of most copious boozings, the agony didn’t start the morning after. Oh, no. It came months later in the ghastly form of low-grade nausea and headache of product owners and middle management wondering why conversions and revenue were both down since the launch. It then hit a fever pitch when the CTO came back from a weekend at the cabin and wondered why the site loaded so slowly on their phone—if it indeed ever loaded at all.

    Everyone was happy. Now no one is happy. Welcome to your first JavaScript hangover.

    It’s not your fault

    When you’re grappling with a vicious hangover, “I told you so” would be a well-deserved, if fight-provoking, rebuke—assuming you could even fight in so sorry a state.

    When it comes to JavaScript hangovers, there’s plenty of blame to dole out. Pointing fingers is a waste of time, though. The landscape of the web today demands that we iterate faster than our competitors. This kind of pressure means we’re likely to take advantage of any means available to be as productive as possible. That means we’re more likely—but not necessarily doomed—to build apps with more overhead, and possibly use patterns that can hurt performance and accessibility.

    Web development isn't easy. It’s a long slog we rarely get right on the first try. The best part of working on the web, however, is that we don’t have to get it perfect at the start. We can make improvements after the fact, and that’s just what the second installment of this series is here for. Perfection is a long ways off. For now, let’s take the edge off of that JavaScript hangover by improving your site’s, er, scriptuation in the short term.

    Round up the usual suspects

    It might seem rote, but it’s worth going through the list of basic optimizations. It’s not uncommon for large development teams—particularly those that work across many repositories or don’t use optimized boilerplate—to overlook them.

    Shake those trees

    First, make sure your toolchain is configured to perform tree shaking. If tree shaking is new to you, I wrote a guide on it last year you can consult. The short of it is that tree shaking is a process in which unused exports in your codebase don’t get packaged up in your production bundles.

    Tree shaking is available out of the box with modern bundlers such as webpack, Rollup, or Parcel. Grunt or gulp—which are not bundlers, but rather task runners—won’t do this for you. A task runner doesn’t build a dependency graph like a bundler does. Rather, they perform discrete tasks on the files you feed to them with any number of plugins. Task runners can be extended with plugins to use bundlers to process JavaScript. If extending task runners in this way is problematic for you, you’ll likely need to manually audit and remove unused code.

    For tree shaking to be effective, the following must be true:

    1. Your app logic and the packages you install in your project must be authored as ES6 modules. Tree shaking CommonJS modules isn’t practically possible.
    2. Your bundler must not transform ES6 modules into another module format at build time. If this happens in a toolchain that uses Babel, @babel/preset-env configuration must specify modules: false to prevent ES6 code from being converted to CommonJS.

    On the off chance tree shaking isn’t occurring during your build, getting it to work may help. Of course, its effectiveness varies on a case-by-case basis. It also depends on whether the modules you import introduce side effects, which may influence a bundler’s ability to shake unused exports.

    Split that code

    Chances are good that you’re employing some form of code splitting, but it’s worth re-evaluating how you’re doing it. No matter how you’re splitting code, there are two questions that are always worth asking yourself:

    1. Are you deduplicating common code between entry points?
    2. Are you lazy loading all the functionality you reasonably can with dynamic import()?

    These are important because reducing redundant code is essential to performance. Lazy loading functionality also improves performance by lowering the initial JavaScript footprint on a given page. On the redundancy front, using an analysis tool such as Bundle Buddy can help you find out if you have a problem.

    The Bundle Buddy utility demonstrating how much code is shared between bundles of JavaScript.
    Bundle Buddy can examine your webpack compilation statistics and determine how much code is shared between your bundles.

    Where lazy loading is concerned, it can be a bit difficult to know where to start looking for opportunities. When I look for opportunities in existing projects, I’ll search for user interaction points throughout the codebase, such as click and keyboard events, and similar candidates. Any code that requires a user interaction to run is a potentially good candidate for dynamic import().

    Of course, loading scripts on demand brings the possibility that interactivity could be noticeably delayed, as the script necessary for the interaction must be downloaded first. If data usage is not a concern, consider using the rel=prefetch resource hint to load such scripts at a low priority that won’t contend for bandwidth against critical resources. Support for rel=prefetch is good, but nothing will break if it’s unsupported, as such browsers will ignore markup they doesn’t understand.

    Externalize third-party hosted code

    Ideally, you should self-host as many of your site’s dependencies as possible. If for some reason you must load dependencies from a third party, mark them as externals in your bundler’s configuration. Failing to do so could mean your website’s visitors will download both locally hosted code and the same code from a third party.

    Let’s look at a hypothetical situation where this could hurt you: say that your site loads Lodash from a public CDN. You've also installed Lodash in your project for local development. However, if you fail to mark Lodash as external, your production code will end up loading a third party copy of it in addition to the bundled, locally hosted copy.

    This may seem like common knowledge if you know your way around bundlers, but I’ve seen it get overlooked. It’s worth your time to check twice.

    If you aren’t convinced to self-host your third-party dependencies, then consider adding dns-prefetch, preconnect, or possibly even preload hints for them. Doing so can lower your site’s Time to Interactive and—if JavaScript is critical to rendering content—your site’s Speed Index.

    Smaller alternatives for less overhead

    Userland JavaScript is like an obscenely massive candy store, and we as developers are awed by the sheer amount of open source offerings. Frameworks and libraries allow us to extend our applications to quickly do all sorts of stuff that would otherwise take loads of time and effort.

    While I personally prefer to aggressively minimize the use of client-side frameworks and libraries in my projects, their value is compelling. Yet, we do have a responsibility to be a bit hawkish when it comes to what we install. When we’ve already built and shipped something that depends on a slew of installed code to run, we’ve accepted a baseline cost that only the maintainers of that code can practically address. Right?

    Maybe, but then again, maybe not. It depends on the dependencies used. For instance, React is extremely popular, but Preact is an ultra-small alternative that largely shares the same API and retains compatibility with many React add-ons. Luxon and date-fns are much more compact alternatives to moment.js, which is not exactly tiny.

    Libraries such as Lodash offer many useful methods. Yet, some of them are easily replaceable with native ES6. Lodash’s compact method, for example, is replaceable with the filter array method. Many more can be replaced without much effort, and without the need for pulling in a large utility library.

    Whatever your preferred tools are, the idea is the same: do some research to see if there are smaller alternatives, or if native language features can do the trick. You may be surprised at how little effort it may take you to seriously reduce your app’s overhead.

    Differentially serve your scripts

    There’s a good chance you’re using Babel in your toolchain to transform your ES6 source into code that can run on older browsers. Does this mean we’re doomed to serve giant bundles even to browsers that don’t need them, until the older browsers disappear altogether? Of course not! Differential serving helps us get around this by generating two different builds of your ES6 source:

    • Bundle one, which contains all the transforms and polyfills required for your site to work on older browsers. You’re probably already serving this bundle right now.
    • Bundle two, which contains little to none of the transforms and polyfills because it targets modern browsers. This is the bundle you’re probably not serving—at least not yet.

    Achieving this is a bit involved. I’ve written a guide on one way you can do it, so there’s no need for a deep dive here. The long and short of it is that you can modify your build configuration to generate an additional but smaller version of your site’s JavaScript code, and serve it only to modern browsers. The best part is that these are savings you can achieve without sacrificing any features or functionality you already offer. Depending on your application code, the savings could be quite significant.

    A webpack-bundle-analyzer analysis of a project's legacy bundle (left) versus one for a modern bundle (right). View full-sized image.

    The simplest pattern for serving these bundles to their respective platforms is brief. It also works a treat in modern browsers:

    <!-- Modern browsers load this file: -->
    <script type="module" src="/js/app.mjs"></script>
    <!-- Legacy browsers load this file: -->
    <script defer nomodule src="/js/app.js"></script>

    Unfortunately, there’s a caveat with this pattern: legacy browsers like IE 11—and even relatively modern ones such as Edge versions 15 through 18—will download both bundles. If this is an acceptable trade-off for you, then worry no further.

    On the other hand, you'll need a workaround if you’re concerned about the performance implications of older browsers downloading both sets of bundles. Here’s one potential solution that uses script injection (instead of the script tags above) to avoid double downloads on affected browsers:

    var scriptEl = document.createElement("script");
    
    if ("noModule" in scriptEl) {
      // Set up modern script
      scriptEl.src = "/js/app.mjs";
      scriptEl.type = "module";
    } else {
      // Set up legacy script
      scriptEl.src = "/js/app.js";
      scriptEl.defer = true; // type="module" defers by default, so set it here.
    }
    
    // Inject!
    document.body.appendChild(scriptEl);

    This script infers that if a browser supports the nomodule attribute in the script element, it understands type="module". This ensures that legacy browsers only get legacy scripts and modern browsers only get modern ones. Be warned, though, that dynamically injected scripts load asynchronously by default, so set the async attribute to false if dependency order is crucial.

    Transpile less

    I’m not here to trash Babel. It’s indispensable, but lordy, it adds a lot of extra stuff without your ever knowing. It pays to peek under the hood to see what it’s up to. Some minor changes in your coding habits can have a positive impact on what Babel spits out.

    https://twitter.com/_developit/status/1110229993999777793

    To wit: default parameters are a very handy ES6 feature you probably already use:

    function logger(message, level = "log") {
      console[level](message);
    }

    The thing to pay attention to here is the level parameter, which has a default of “log.” This means if we want to invoke console.log with this wrapper function, we don’t need to specify level. Great, right? Except when Babel transforms this function, the output looks like this:

    function logger(message) {
      var level = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : "log";
    
      console[level](message);
    }

    This is an example of how, despite our best intentions, developer conveniences can backfire. What was a handful of bytes in our source has now been transformed into much larger in our production code. Uglification can’t do much about it either, as arguments can’t be reduced. Oh, and if you think rest parameters might be a worthy antidote, Babel’s transforms for them are even bulkier:

    // Source
    function logger(...args) {
      const [level, message] = args;
    
      console[level](message);
    }
    
    // Babel output
    function logger() {
      for (var _len = arguments.length, args = new Array(_len), _key = 0; _key < _len; _key++) {
        args[_key] = arguments[_key];
      }
    
      const level = args[0],
            message = args[1];
      console[level](message);
    }

    Worse yet, Babel transforms this code even for projects with a @babel/preset-env configuration targeting modern browsers, meaning the modern bundles in your differentially served JavaScript will be affected too! You could use loose transforms to soften the blow—and that’s a fine idea, as they’re often quite a bit smaller than their more spec-compliant counterparts—but enabling loose transforms can cause issues if you remove Babel from your build pipeline later on.

    Regardless of whether you decide to enable loose transforms, here’s one way to cut the cruft of transpiled default parameters:

    // Babel won't touch this
    function logger(message, level) {
      console[level || "log"](message);
    }

    Of course, default parameters aren’t the only feature to be wary of. For example, spread syntax gets transformed, as do arrow functions and a whole host of other stuff.

    If you don’t want to avoid these features altogether, you have a couple ways of reducing their impact:

    1. If you’re authoring a library, consider using @babel/runtime in concert with @babel/plugin-transform-runtime to deduplicate the helper functions Babel puts into your code.
    2. For polyfilled features in apps, you can include them selectively with @babel/polyfill via @babel/preset-env’s useBuiltIns: "usage" option.

    This is solely my opinion, but I believe the best choice is to avoid transpilation altogether in bundles generated for modern browsers. That’s not always possible, especially if you use JSX, which must be transformed for all browsers, or if you’re using bleeding edge language features that aren’t widely supported. In the latter case, it might be worth asking if those features are really necessary to deliver a good user experience (they rarely are). If you arrive at the conclusion that Babel must be a part of your toolchain, then it’s worth peeking under the hood from time to time to catch suboptimal stuff Babel might be doing that you can improve on.

    Improvement is not a race

    As you massage your temples wondering when this horrid JavaScript hangover is going to lift, understand that it’s precisely when we rush to get something out there as fast as we possibly can that the user experience can suffer. As the web development community obsesses on iterating faster in the name of competition, it’s worth your time to slow down a little bit. You’ll find that by doing so, you may not be iterating as fast as your competitors, but your product will be faster than theirs.

    As you take these suggestions and apply them to your codebase, know that progress doesn’t spontaneously happen overnight. Web development is a job. The truly impactful work is done when we’re thoughtful and dedicated to the craft for the long haul. Focus on steady improvements. Measure, test, repeat, and your site’s user experience will improve, and you’ll get faster bit by bit over time.

    Special thanks to Jason Miller for tech editing this piece. Jason is the creator and one of the many maintainers of Preact, a vastly smaller alternative to React with the same API. If you use Preact, please consider supporting Preact through Open Collective.

  • Resilient Management, An Excerpt

    In Tuckman’s Stages of Group Development, the Storming stage happens as a group begins to figure out how to work together. Previously, each person had been doing their own thing as individuals, so necessarily a few things need to be ironed out: how to collaborate, how to hit goals, how to determine priorities. Of course there may be some friction here!

    But even if your team doesn’t noticeably demonstrate this kind of internal Storming as they begin to gel, there might be some outside factors at play in your work environment that create friction. During times of team scaling and organizational change—the water we in the web industry are often swimming in—managers are responsible for things like strategy-setting, aligning their team’s work to company objectives, and unblocking the team as they ship their work.

    In addition to these business-context responsibilities, managers need to be able to help their teammates navigate this storm by helping them grow in their roles and support the team’s overall progress. If you and your teammates don’t adapt and evolve in your roles, it’s unlikely that your team will move out of the Storming stage and into the Norming stage of team dynamics.

    To spur this course-correction and growth in your teammates, you’ll end up wearing four different hats:

    • Mentoring: lending advice and helping to problem solve based on your own experience.
    • Coaching: asking open questions to help your teammate reflect and introspect, rather than sharing your own opinions or quickly problem solving.
    • Sponsoring: finding opportunities for your teammate to level up, take on new leadership roles, and get promoted.
    • Delivering feedback: observing behavior that is or isn’t aligned to what the team needs to be doing and sharing those observations, along with praise or suggestions.

    Let’s dive in to how to choose, and when to use, each of these skills as you grow your teammates, and then talk about what it looks like when teammates support the overarching direction of the team.

    Mentoring

    When I talk to managers, I find that the vast majority have their mentor hats on ninety percent of the time when they’re working with their teammates. It’s natural!

    In mentoring mode, we’re doling out advice, sharing our perspective, and helping someone else problem solve based on that information. Our personal experiences are often what we can talk most confidently about! For this reason, mentorship mode can feel really good and effective for the mentor. Having that mentor hat on can help the other person overcome a roadblock or know which next steps to take, while avoiding drastic errors that they wouldn’t have seen coming otherwise.

    As a mentor, it’s your responsibility to give advice that’s current and sensitive to the changing dialog happening in our industry. Advice that might work for one person (“Be louder in meetings!” or “Ask your boss for a raise!”) may undermine someone else, because members of underrepresented groups are unconsciously assessed and treated differently. For example, research has shown that “when women are collaborative and communal, they are not perceived as competent—but when they emphasize their competence, they’re seen as cold and unlikable, in a classic ‘double bind’”.

    If you are not a member of a marginalized group, and you have a mentee who is, please be a responsible mentor! Try to be aware of the way members of underrepresented groups are perceived, and the unconscious bias that might be at play in your mentee’s work environment. When you have your mentor hat on, do lots of gut checking to make sure that your advice is going to be helpful in practice for your mentee.

    Mentoring is ideal when the mentee is new to their role or to the organization; they need to learn the ropes from someone who has firsthand experience. It’s also ideal when your teammate is working on a problem and has tried out a few different approaches, but still feels stumped; this is why practices like pair coding can help folks learn new things.

    As mentors, we want our mentees to reach beyond us, because our mentees’ success is ultimately our success. Mentorship relationships evolve over time, because each party is growing. Imaginative, innovative ideas often come from people who have never seen a particular challenge before, so if your mentee comes up with a creative solution on their own that you wouldn’t have thought of, be excited for them—don’t just focus on the ways that you’ve done it or seen it done before.

    Managers often default to mentoring mode because it feels like the fastest way to solve a problem, but it falls short in helping your teammate connect their own dots. For that, we’ll look to coaching.

    Coaching

    In mentoring mode, you’re focused on both the problem and the solution. You’ll share what you as the mentor would do or have done in this situation. This means you’re more focused on yourself, and less on the person who is sitting in front of you.

    In coaching mode—an extremely powerful but often underutilized mode—you’re doing two primary things:

    1. Asking open questions to help the other person explore more of the shape of the topic, rather than staying at the surface level.
    2. Reflecting, which is like holding up a mirror for the other person and describing what you see or hear, or asking them to reflect for themselves.

    These two tools will help you become your teammate’s fiercest champion.

    Open Questions

    “Closed” questions can only be answered with yes or no. Open questions often start with who, what, when, where, why, and how. But the best open questions are about the problem, not the solution. Questions that start with why tend to make the other person feel judged, and questions that start with how tend to go into problem solving mode—both of which we want to avoid while in coaching mode.

    However, what questions can be authentically curious! When someone comes to you with a challenge, try asking questions like:

    • What’s most important to you about it?
    • What’s holding you back?
    • What does success look like?

    Let’s say my teammate comes to me and says they’re ready for a promotion. Open questions could help this teammate explore what this promotion means and demonstrate to me what introspection they’ve already done around it. Rather than telling them what I think is necessary for them to be promoted, I could instead open up this conversation by asking them:

    • What would you be able to do in the new level that you can’t do in your current one?
    • What skills are required in the new level? What are some ways that you’ve honed those skills?
    • Who are the people already at that level that you want to emulate? What about them do you want to emulate?

    Their answers would give me a place to start coaching. These questions might push my teammate to think more deeply about what this promotion means, rather than allowing them to stay surface level and believe that a promotion is about checking off a lot of boxes on a list. Their answers might also open my eyes to things that I hadn’t seen before, like a piece of work that my teammate had accomplished that made a huge impact. But most important, going into coaching mode would start a two-way conversation with this teammate, which would help make an otherwise tricky conversation feel more like a shared exploration.

    Open questions, asked from a place of genuine curiosity, help people feel seen and heard. However, if the way you ask your questions comes across as judgy or like you’ve already made some assumptions, then your questions aren’t truly open (and your teammate can smell this on you!). Practice your intonation to make sure your open questions are actually curious and open.

    By the way, forming lots of open questions (instead of problem solving questions, or giving advice) is tremendously hard for most people. Don’t worry if you don’t get the hang of it at first; it takes a lot of practice and intention over time to default to coaching mode rather than mentoring mode. I promise, it’s worth it.

    Reflections

    Just like open questions, reflections help the other person feel seen and heard, and to explore the topic more deeply.

    It’s almost comical how rarely we get the sense that the person we’re talking to is actively listening to us, or focusing entirely on helping us connect our own dots. Help your teammates reflect by repeating back to them what you hear them say, as in:

    • “What I’m hearing you say is that you’re frustrated with how this project is going. Is that right?”
    • “What I know to be true about you is how deeply you care about your teammates’ feelings.”

    In each of these examples, you are holding up a metaphorical mirror to your teammate, and helping them look into it. You can coach them to reflect, too:

    • “How does this new architecture project map to your goals?”
    • “Let’s reflect on where you were this time last year and how far you’ve come.”

    Occasionally, you might get a reflection wrong; this gives the other person an opportunity to realize something new about their topic, like the words they’re choosing aren’t quite right, or there’s another underlying issue that should be explored. So don’t be worried about giving a bad reflection; reflecting back what you’re hearing will still help your teammate.

    The act of reflecting can help the other person do a gut check to make sure they’re approaching their topic holistically. Sometimes the act of reflection forces (encourages?) the other person to do some really hard work: introspection. Introspection creates an opportunity for them to realize new aspects of the problem, options they can choose from, or deeper meanings that hadn’t occurred to them before—which often ends up being a nice shortcut to the right solution. Or, even better, the right problem statement.

    When you have your coaching hat on, you don’t need to have all the answers, or even fully understand the problem that your teammate is wrestling with; you’re just there as a mirror and as a question-asker, to help prompt the other person to think deeply and come to some new, interesting conclusions. Frankly, it may not feel all that effective when you’re in coaching mode, but I promise, coaching can generate way more growth for that other person than just giving them advice or sharing your perspective.

    Choose coaching when you’re looking to help someone (especially an emerging leader) hone their strategic thinking skills, grow their leadership aptitude, and craft their own path forward. Coaching mode is all about helping your teammate develop their own brain wrinkles, rather than telling them how you would do something. The introspection and creativity it inspires create deeper and longer-lasting growth.

    Sponsoring

    While you wear the mentoring and coaching hats around your teammates, the sponsor hat is more often worn when they’re not around, like when you’re in a 1:1 with your manager, a sprint planning meeting, or another environment where someone’s work might be recognized. You might hear about an upcoming project to acquire a new audience and recommend that a budding user researcher take it on, or you’ll suggest to an All Hands meeting organizer that a junior designer should give a talk about a new pattern they’ve introduced to the style guide.

    Sponsorship is all about feeling on the hook for getting someone to the next level. As someone’s sponsor, you’ll put their name in the ring for opportunities that will get them the experience and visibility necessary to grow in their role and at the organization. You will put your personal reputation on the line on behalf of the person you’re sponsoring, to help get them visible and developmental assignments. It’s a powerful tool, and the one most effective at helping someone get to the next level (way more so than mentoring or coaching!).

    The Center for Talent Innovation routinely measures the career benefits of sponsorship (PDF). Their studies have found that when someone has a sponsor, they are way more likely to have access to career-launching work. They’re also more likely to take actions that lead to even more growth and opportunities, like asking their manager for a stretch assignment or a raise.

    When you’re in sponsorship mode, think about the different opportunities you have to offer up someone’s name. This might look like:

    • giving visible/public recognition (company “shout outs,” having them present a project demo, thanking them in a launch email, giving someone’s manager feedback about their good work);
    • assigning stretch tasks and projects that are just beyond their current skill set, to help them grow and have supporting evidence for a future promotion; or
    • opening the door for them to write blog posts, give company or conference talks, or contribute open-source work.

    Remember that members of underrepresented groups are typically over-mentored, but under-sponsored. These individuals get lots of advice (often unsolicited), coffee outings, and offers to teach them new skills. But it’s much rarer for them to see support that looks like sponsorship.

    This isn’t because sponsors intentionally ignore marginalized folks, but because of in-group bias. Because of how our brains (and social networks) work, the people we’re closest to tend to look mostly like us—and we draw from that same pool when we nominate people for projects, for promotions, and for hires. Until I started learning about bias in the workplace, most of the people I sponsored were white, cisgender women, like myself. Since then, I’ve actively worked to sponsor people of color and nonbinary people. It takes effort and intention to combat our default behaviors—but I know you can do it!

    Take a look at the daily communications you participate in: your work chat logs, the conversations you have with others, the process for figuring out who should fix a bug or work on a new project, and the processes for making your teams’ work visible (like an architecture review, code review, launch calendar, etc.). You’ll be surprised how many moments there are to sponsor someone throughout an average day. Please put in the time and intention to ensure that you’re sponsoring members of underrepresented groups, too.

  • Daily Ethical Design
    Suddenly, I realized that the people next to me might be severely impacted by my work. I was having a quick lunch in the airport. A group of flight attendants sat down at the table next to me and started to prepare for their flight. For a while now, our design team had been working on futuristic concepts for the operations control center of these flight attendants’ airline, pushing ourselves to come up with innovative solutions enabled by the newest technologies. As the control center deals with all activities around flying planes, our concepts touched upon everything and everyone within the airline. How was I to know what the impact of my work would be on the lives of these flight attendants? And what about the lives of all the other people working at the airline? Ideally, we would have talked to all the types of employees in the company and tested our concepts with them. But, of course, there was no budget (or time) allocated to do so, not to mention we faced the hurdle of convincing (internal) stakeholders of the need. Not for the first time, I felt frustrated: practical, real-world constraints prevented me from assessing the impact and quality of my work. They prevented me from properly conducting ethical design.

    What is ethical design?

    Right, good question. A very comprehensive definition of ethical design can be found at Encyclopedia.com:
    Design ethics concerns moral behavior and responsible choices in the practice of design. It guides how designers work with clients, colleagues, and the end users of products, how they conduct the design process, how they determine the features of products, and how they assess the ethical significance or moral worth of the products that result from the activity of designing.
    In other words, ethical design is about the “goodness”—in terms of benefit to individuals, society, and the world—of how we collaborate, how we practice our work, and what we create. There’s never a black-and-white answer for whether design is good or bad, yet there are a number of areas for designers to focus on when considering ethics.

    Usability

    Nowadays usability has conquered a spot as a basic requirement for each interface; unusable products are considered design failures. And rightly so; we have a moral obligation as designers to create products that are intuitive, safe, and free from possibly life-threatening errors. We were all reminded of usability’s importance by last year’s accidental nuclear strike warning in Hawaii. What if, instead of a false-positive, the operator had broadcasted a false-negative?

    Accessibility

    Like usability, inclusive design has become a standard item in the requirement list of many designers and companies. (I will never forget that time someone tried to use our website with a screen reader—and got absolutely stuck at the cookie message.) Accessible design benefits all, as it attempts to cover as many needs and capabilities as possible. Yet for each design project, there are still a lot of tricky questions to answer. Who gets to benefit from our solutions? Who is (un)intentionally left out? Who falls outside the “target customer segment”?

    Privacy

    Another day, another Facebook privacy scandal. As we’re progressing into the Data Age, the topic of privacy has become almost synonymous with design ethics. There’s a reason why more and more people use DuckDuckGo as an alternative search engine to Google. Corporations have access to an abundance of personal information about consumers, and as designers we have the privilege—and responsibility—of using this information to shape products and services. We have to consider how much information is strictly necessary and how much people are willing to give up in exchange for services. And how can we make people aware of the potential risks without overloading them?

    User involvement

    Overlapping largely with privacy, this focus area is about how we deal with our users and what we do with the data that we collect from them. IDEO has recently published The Little Book of Design Research Ethics, which provides a comprehensive overview of the core principles and guidelines we should follow when conducting design research.

    Persuasion

    Ethics related to persuasion is about to what extent we may influence the behavior and thoughts of our users. It doesn’t take much to bring acceptable, “white hat” persuasion into gray or even dark territories. Conversion optimization, for example, can easily turn into “How do we squeeze out more revenue from our customers by turning their unconsciousness against them?” Prime examples include Netflix, which convinces us to watch, watch, and watch even more, and Booking.com, which barrages our senses with urgency and social pressure.

    Focus

    The current digital landscape is addictive, distracting, and competing for attention. Designing for focus is about responsibly handling people’s most valuable resource: time. Our challenge is to limit everything that disrupts our users’ attention, lower the addictiveness of products, and create calmness. The Center for Humane Technology has started a useful list of resources for this purpose.

    Sustainability

    What’s the impact of our work on the world’s environment, resources, and climate? Instead of continuously adding new features in the unrelenting scrum treadmill, how could we design for fewer? We’re in the position to create responsible digital solutions that enable sustainable consumer behavior and prevent overconsumption. For example, apps such as Optimiam and Too Good To Go allow people to order leftover food that would normally be thrashed. Or consider Mutum and Peerby, whose peer-to-peer platforms promote the sharing and reuse of owned products.

    Society

    The Ledger of Harms of the Center for Human Technology is a work-in-progress collection of the negative impacts that digital technology has on society, including topics such as relationships, mental health, and democracy. Designers who are mindful of society consider the impact of their work on the global economy, communities, politics, and health.
    [caption id="attachment_7171650" align="alignnone" width="1200"]Focus areas of ethical design: user involvement, persuasion, focus, sustainability, society, usability, accessibility, privacy The focus areas of design ethics. That’s a lot to consider![/caption]

    Ethics as an inconvenience

    Ideally, in every design project, we should assess the potential impact in all of the above-mentioned areas and take steps to prevent harm. Yet there are many legitimate, understandable reasons why we often neglect to do so. It’s easy to have moral principles, yet in the real world, with the constraints that our daily life imposes upon us, it’s seldom easy to act according to those principles. We might simply say it’s inconvenient at the moment. That there’s a lack of time or budget to consider all the ethical implications of our work. That there are many more pressing concerns that have priority right now. We might genuinely believe it’s just a small issue, something to consider later, perhaps. Mostly, we are simply unaware of the possible consequences of our work. And then there’s the sheer complexity of it all: it’s simply too much to simultaneously focus on. When short on time, or in the heat of approaching deadlines and impatient stakeholders, how do you incorporate all of design ethics’ focus areas? Where do you even start?

    Ethics as a structural practice

    For these reasons, I believe we need to elevate design ethics to a more practical level. We need to find ways to make ethics not an afterthought, not something to be considered separately, but rather something that’s so ingrained in our process that not doing it means not doing design at all. The only way to overcome the “inconvenience” of acting ethically is to practice daily ethical design: ethics structurally integrated in our daily work, processes, and tools as designers. No longer will we have to rely on the exceptions among us; those extremely principled who are brave enough to stand up against the system no matter what kind of pressure is put upon them. Because the system will be on our side. By applying ethics daily and structurally in our design process, we’ll be able to identify and neutralize in a very early stage the potential for mistakes and misuse. We’ll increase the quality of our design and our practices simply because we’ll think things through more thoroughly, in a more conscious and structured manner. But perhaps most important is that we’ll establish a new standard for design. A standard that we can sell to our clients as the way design should be done, with ethical design processes and deliverables already included. A standard that can be taught to design students so that the newest generation of designers doesn’t know any better than to apply ethics, always.

    How to practice daily ethical design?

    At this point we’ve arrived at the question of how we can structurally integrate ethics into our design process. How do we make sure that our daily design decisions will result in a product that’s usable and accessible; protects people’s privacy, agency, and focus; and benefits both society and nature? I want to share with you some best practices that I’ve identified so far, and how I’ve tried to apply them during a recent project at Mirabeau. The goal of the project was to build a web application that provides a shaver manufacturer’s factory workers insight into the real-time availability of production materials.

    Connect to your organization’s mission and values

    By connecting our designs to the mission and values of the companies we work for, we can structurally use our design skills in a strategic manner, for moral purposes. We can challenge the company to truly live up to its promises and support it in carrying out its mission. This does, however, require you to be aware of the company’s values, and to compare these to your personal values. As I had worked with our example client before, I knew it was a company that takes care of its employees and has a strong focus on creating a better world. During the kick-off phase, we used a strategy pyramid to structure the client’s mission and values, and to agree upon success factors for the project. We translated the company’s customer-facing brand guidelines to employee-focused design principles that maintained the essence of the organization.

    Keep track of your assumptions

    Throughout our entire design process, we make assumptions for each decision that we take. By structurally keeping track of these assumptions, you’ll never forget about the limitations of your design and where the potential risks lie in terms of (harmful) impact on users, the project, the company, and society. In our example project, we listed our assumptions about user goals, content, and functionalities for each page of the application. If we were not fully sure about the value for end users, or the accuracy of a user goal, we marked it as a value assumption. When we were unsure if data could be made available, we marked this as a data (feasibility) assumption. If we were not sure whether a feature would add to the manufacturer’s business, we marked it as a scope assumption. Every week, we tested our assumptions with end users and business stakeholders through user tests and sprint demos. Each design iteration led to new questions and assumptions to be tested the next week.

    Aim to be proven wrong

    While our assumptions are the known unknowns, there are always unknown unknowns that we aren’t aware of but could be a huge risk for the quality and impact of our work. The only way we can identify these is by applying the scientific principle of falsifiability: seeking actively to be proven wrong. Only outsiders can point out to us what we miss as an individual or as a team. In our weekly user tests, we included factory workers and stakeholders with different disciplines, from different departments, and working in different contexts, to identify the edge cases that could break our concept. On one occasion, this made us reconsider the entirety of our concept. Still, we could have done better: although scalability to other factories was an important success factor, we were unable to gather input from those other factories during the project. We felt our only option was to mention this as a risk (“limit to scalability”).

    Use the power of checklists

    Let’s face it: we forget things. (Without scrolling up the page, can you name all the focus areas of design ethics?) This is where checklists help us out: they provide knowledge in the world, so that we don’t have to process it in our easily overwhelmed memory. Simple yet powerful, a checklist is an essential tool to practice daily ethical design. In our example project, we used checklists to maintain an overview of questions and assumptions to user test, checking whether we included our design principles properly, and assessing whether we complied to the client’s values, design principles, and the agreed-upon success factors. In hindsight, we could also have taken a moment during the concept phase to go through the list of focus areas for design ethics, as well as have taken a more structural approach to check accessibility guidelines.

    The main challenge for daily ethical design

    Most ethics focus areas are quite tangible, where design decisions have immediate, often visible effects. While certainly challenging in their own right, they’re relatively easy to integrate in our daily practice, especially for experienced designers. Society and the environment, however, are more intangible topics; the effects of our work in these areas are distant and uncertain. I’m sure that when Airbnb was first conceived, the founders did not consider the magnitude of its disruptive impact on the housing market. The same goes for Instagram, as its role in creating demand for fast fashion must have been hard to foresee. Hard, but not impossible. So how do we overcome this challenge and make the impact that we have on society and the environment more immediate, more daily?

    Conduct Dark Reality sessions

    The ancient Greek philosopher Socrates used a series of questions to gradually uncover the invalidity of people’s beliefs. In a very similar way, we can uncover the assumptions and potential disastrous consequences of our concepts in a ‘Dark Reality’ session, a form of speculative design that focuses on stress-testing a concept with challenging questions. We have to ask ourselves—or even better, somebody outside our team has to ask us— questions such as, “What is the lifespan of your product? What if the user base will be in the millions? What are the long-term effects on economy, society, and the environment? Who benefits from your design? Who loses? Who is excluded? And perhaps most importantly, how could your design be misused? (For more of these questions, Alan Cooper provided a great list in his keynote at Interaction 18.) The back-and-forth Q&A of the Dark Reality session will help us consider and identify our concept’s weaknesses and potential consequences. As it is a team effort, it will spark discussion and uncover differences in team members’ ethical values. Moreover, the session will result in a list of questions and assumptions that can be tested with potential users and subject matter experts. In the project for the airline control center, it resulted in more consideration for the human role in automatization and how digital interfaces can continue to support human capabilities (instead of replacing them), and reflection on the role of airports in future society. The dark reality session is best conducted during the convergent parts of the double diamond, as these are the design phases in which we narrow down to realistic ideas. It’s vital to have a questioner from outside the team with strong interviewing skills and who doesn’t easily accept an answer as sufficient. There are helpful tools available to help structure the session, such as the Tarot Cards of Tech and these ethical tools.

    Take a step back to go forward

    As designers, we’re optimists by nature. We see the world as a set of problems that we can solve systematically and creatively if only we try hard enough. We intend well. However, merely having the intention to do good is not going to be enough. Our mindset comes with the pitfall of (dis)missing potential disastrous consequences, especially under pressure of daily constraints. That’s why we need to regularly, systematically take a step back and consider the future impact of our work. My hope is that the practical, structural mindset to ethics introduced in this article will help us agree on a higher standard for design.
  • Trans-inclusive Design

    Late one night a few years ago, a panicked professor emailed me: “My transgender student’s legal name is showing on our online discussion board. How can I keep him from being outed to his classmates?” Short story: we couldn’t. The professor created an offline workaround with the student. Years later this problem persists not just in campus systems, but in many systems we use every day.

    To anyone who’d call that an unusual situation, it’s not. We are all already designing for trans users—1 in 250 people in the US identifies as transgender or gender non-binary (based on current estimates), and the number is rising.

    We are web professionals; we can do better than an offline workaround. The choices we make impact the online and offline experiences of real people who are trans, non-binary, or gender-variant—choices that can affirm or exclude, uplift or annoy, help or harm.

    The rest of this article assumes you agree with the concept that trans people are human beings who deserve dignity, respect, and care. If you are seeking a primer on trans-related vocabulary and concepts, please read up and come back later.

    I’m going to cover issues touching on content, images, forms, databases, IA, privacy, and AI—just enough to get you thinking about the decisions you make every day and some specific ideas to get you started.

    “Tried making a Bitmoji again, but I always get disillusioned immediately by their binary gender model from literally step 1 and end up not using it. I don’t feel represented.”

    Editorial note: All personal statements quoted in this article have been graciously shared with the express consent of the original authors.

    How we can get things right

    Gender is expansively misconstrued as some interchangeable term for anatomical features. Unlike the constellation of human biological forms (our sex), gender is culturally constructed and varies depending on where you are in the world. It has its own diversity.

    Asking for gender when it is not needed; limiting the gender options users can select; assuming things about users based on gender; or simply excluding folks from our designs are all ways we reify the man-woman gender binary in design decisions.

    Names are fundamentally important

    If we do nothing else, we must get names right. Names are the difference between past and present, invalidation and affirmation, and sometimes safety and danger.

    Yet, many of the systems we use and create don’t offer name flexibility.

    Many programmers and designers have a few misconceptions about names, such as assuming people have one moniker that they go by all the time, despite how common it is for names to change over a lifetime. People might update them after a change in marital status, family situation, or gender, or perhaps someone is known by a nickname, westernized name, or variation on a first name.

    In most locales, legally changing names is extremely difficult, extremely expensive, requires medical documentation, or is completely out of the question.

    Changes to name and gender marker are even more complicated; they tend to be two separate, long-drawn-out processes. To make matters worse, laws vary from state to state within the U.S. and most only recognize two genders—man and woman—rather than allowing non-binary options.Not all trans people change their names, but for those who do, it’s a serious and significant decision that shouldn’t be sabotaged. We can design systems that protect the lives and privacy of our users, respect the fluid nature of personal identity, and act as an electronic curb cut that helps everyone in the process.

    Deadnaming

    One need only search Twitter for “deadname app” to get an idea of how apps can leave users in the lurch. Some of the most alarming examples involve apps and sites that facilitate real-life interactions (which already involve a measure of risk for everyone).

    “Lyft made it completely impossible for me to change my name on its app even when it was legally changed. I reached out to their support multiple times and attempted to delete the account and start over with no result. I was completely dependent on this service for groceries, appointments, and work, and was emotionally exhausted every single time I needed a ride. I ended up redownloading Uber - even though there was a strike against the service - which I felt awful doing. But Uber allowed me to change my name without any hoops to jump through, so for the sake of my mental health, I had to.”

    Trans people are more likely to experience financial hardship, so using payment apps to ask for donations is often necessary. Some of these services may reveal private information as a matter of course, leaving them exposed and potentially at risk.

    There are also ramifications when linked services rely on our data sources for name information, instigating an unpredictable cascade effect with little or no recourse to prevent the sharing of sensitive details.

    These are examples of deadnaming. Deadnaming is what happens when someone’s previous or birth name is used, rather than the name the person uses now. Deadnaming is invalidating at the least, even as a faux pas, but can be psychologically devastating at the other extreme, even putting lives at risk.The experiences of trans, non-binary, or gender-variant folk can vary widely, and they live in disparate conditions throughout the world. Many are thriving and creating new and joyful ways to resist and undo gender norms, despite the common negative narrative around trans lives. Others can face hardship; trans people are more likely to be unstably housed, underemployed, underpaid, and targets of violence in and out of their homes, workplaces, and intimate relationships. The ramifications are amplified for people of color and those with disabilities, as well as those in precarious living/working situations and environments where exposure can put them in harm’s way.

    Design for name changes

    Heres what we can do:

    Design for renaming. Emma Humphries’ talk on renaming covers this nicely. Airbnb has developed policies and procedures for users who’ve transitioned, allowing users to keep their review histories intact with amended names and/or pronouns.

    Get rid of “real name” requirements. Allow people to use names they go by rather than their legal first names.

    Clarify when you actually need a legal name, and only use that in conjunction with a display name field.

    Have a name change process that allows users to change their names without legal documentation. (It’s likely that you have procedures for marriage-related name changes already.)

    Ensure users can still change their display names when connecting with other data sources to populate users’ names.

    Don’t place onerous restrictions on changes. Once someone creates a username, web address, or profile URL, allow them to change it.

    Draft a code of conduct if you’re part of an online community, and make sure to include policies around deadnaming. Twitter banned deadnaming last year.

    Allow people to be forgotten. When people delete their accounts for whatever reason, help them make sure that their data is not lingering in your systems or in other places online.

    Update the systems users don’t see, too

    Identity management systems can be a mess, and name changes can reveal the failures among those systems, including hidden systems that users don’t see.

    One Twitter user’s health insurance company kept their ID number between jobs but changed their gender. Another user updated their display name but got an email confirmation addressed to their legal name.

    Hidden information can also undermine job opportunities:

    “At a university as a student, I transitioned and changed my name and gender to be a woman. TWELVE YEARS later after being hired to work in the Libraries, the Libraries HR coordinator emailed me that I was listed as male still in the database. He changed it on my asking, but I have to wonder how long… was it a factor in my being turned down for jobs I applied to… who had seen that..?”

    Emma Humphries details the hidden systems that can carry out-of-date information about users. Her tips for database design include:

    • Don’t use emails as unique IDs.
    • Use an invariant user ID internally, and link the user’s current email and display name to it.

    Images

    Visuals should allow room for representation and imagination rather than a narrow subset of the usual suspects: figures who appear to be straight, cisgender, able-bodied, and white/Caucasian.

    What we can do is feature a variety of gender presentations, as well as not assume someone’s gender identity if they buy certain items.

    Some companies, like Wildfang and Thinx, offer a broad array of images representing different races, body sizes, and gender expressions on their websites and in their ads.

    Many are also choosing not to hire models, allowing room for imagination and versatility:

    “I got a catalog for a ‘classic menswear company’ that features zero photos of any person of any gender. Now if only I could afford an $800 blazer...”

    Here's what we can do:

    Actively recruit diverse groups of models for photos. And pay them!

    If you can’t shoot your own photos, Broadly has recently launched a trans-inclusive stock photo collection free for wide use. Avataaars allows users to create an avatar without selecting a gender.

    Information architecture

    How we organize information is a political act and a non-neutral decision (librarians have said this for a while). This applies to gender-based classifications.

    Many companies that sell consumer goods incorporate gender into their product design and marketing, no matter what. The product itself might be inherently gender-neutral (such as clothing, toys, bikes, or even wine), but these design and marketing decisions can directly impact the information architecture of websites.

    Here's what we can do:

    Evaluate why any menus, categories, or tags are based on gender, and how it can be done differently:

    “Nike has a ‘gender neutral’ clothing category, yet it’s listed under ‘men’ and ‘women’ in the website architecture. 🤔”

    Forms

    Forms, surveys, and other types of data gathering are surefire ways to include or exclude people. If you ask for information you don’t need or limit the options that people can select, you risk losing them as users.

    Here's what we can do:

    Critically evaluate why you are asking for personal information, including gender. Will that information be used to help someone, or sell things to your advertisers?

    "Why does the @CocaCola site make me select a gender just to make a purchase? Guess my family isn't getting personalized Coke bottles for Christmas."

    If you are asking users for their gender, you’d better have a good reason and options that include everyone. A gender field should have more than two options, or should ask for pronouns instead. When including more than binary options, actually record the selections in your databases instead of reclassifying answers as male/female/null, otherwise you risk losing trust when disingenuous design decisions become public.

    Honorifics are infrequently used these days, but it takes little work to add gender-inclusive titles to a list. For English-language sites, “Mx.” can go alongside “Mr.” and “Ms.” without fuss. United Airlines debuted this option earlier this year.

    Content

    Here's what we can do:

    Avoid inappropriately gendered language. Your style guide should include singular “they” instead of “he/she” or “s/he,” and exclude frequently used words and phrases that exclude trans folks. Resources such as this transgender style guide are a quick way to check your language and benchmark your own content guidelines.

    Check assumptions about gender and biology. Not everyone who can have a period, can get pregnant, or can breastfeed identifies as women or mothers—just as not everyone who identifies as women or mothers can have periods, can get pregnant, or can breastfeed. Thinx, a company that sells period underwear, has an inclusive tagline: “For people with periods.”

    Avoid reinforcing the binary. Groups of people aren’t “ladies and gentlemen” or “boys and girls.” They are folks, people, colleagues, “y’all,” or even “all y’all.”

    Pronouns aren’t “preferred”—they’re just pronouns. Calling pronouns preferred suggests that they’re optional and are replacing a “true” pronoun.

    Avoid reinforcing stereotypes about trans people. Not all trans people are interested in medically transitioning, or in “passing.” They also aren’t fragile or in need of a savior. Gender is separate from sexual orientation. You can’t “tell” someone is trans.

    Privacy, surveillance, and nefarious AI

    We’ve heard the story of algorithms identifying a pregnant teen before her parents knew. What if an algorithm predicts or reveals information about your gender identity?

    Inferences. Users’ genders are assumed based on their purchase/browsing history.

    Recommendations. A user bought something before they transitioned and it shows up in “recommended because you bought X.”

    Predictions. Users’ genders are not only inferred but used to predict something else based on characteristics of that gender. Even if you don’t tell big websites what your gender is, they assume one for you based on your interests. That kind of reductive essentialism can harm people of all genders. One of this article’s peer readers summed this up:

    “Gender markers are a poor proxy for tastes. I like dresses, cute flats, and Raspberry Pis.”

    Flashbacks. “On this day” algorithms remind users of the past, sometimes for better (“I’ve come so far”) or for worse (“don’t remind me”).

    AI-based discrimination

    AI and surveillance software can also reinforce norms about what men’s and women’s bodies should look like, resulting in harrowing airline travel experiences and creating AI-based discrimination for trans people.

    So, too, can trans folks’ public data be used for projects that they don’t consent to. Just because we can use AI for something—like determining gender based on a face scan—doesn’t mean we should.

    Here's what we can do:

    Read up and proactively mitigate bias. AI and algorithms can reflect developers’ biases and perpetuate stereotypes about how people’s bodies should look. Use AI to challenge the gender binary rather than reinforce it. Design for privacy first. Hire more types of people who represent different lived experiences.

    Toward a gender-inclusive web

    The ideas I’ve offered here are only starting points. How you choose to create space for trans folks is going to be up to you. I don’t have all the solutions here, and there is no singular trans experience. Also, language, definitions, and concepts change rapidly.

    We shouldn’t use any of these facts as excuses to keep us from trying.

    When we start to think about design impact on trans folks, the ideas we bring into question can benefit everyone. Our designs should go beyond including—they should affirm and validate. Ideally, they will also reflect organizational cultures that support diversity and inclusion.

    Here's what we can do:

    Keep learning. Learn how to be a good ally. Pay trans user research participants to help validate your design assumptions. Hire trans people on your team and don't hang them out to dry or make them do all the hard work around inclusion and equity. Make it everyone’s job to build a more just web and world for everybody.

    Editorial note: All personal statements quoted in this article have been graciously shared with the express consent of the original authors.

    This article is stronger and wiser thanks to Mica McPheeters at A List Apart and the following peer readers. Thank you.

    Jake Atchison
    Katherine Deibel, Ph.D.
    Justina F. Hall
    Austyn Higgs
    Emma Humphries
    Tara Robertson
    Levi R. Walter

  • Everyday Information Architecture: Auditing for Structure

    Just as we need to understand our content before we can recategorize it, we need to understand the system before we try to rebuild it.

    Enter the structural audit: a review of the site focused solely on its menus, links, flows, and hierarchies. I know you thought we were done with audits back in Chapter 2, but hear me out! Structural audits have an important and singular purpose: to help us build a new sitemap.

    This isn’t about recreating the intended sitemap—no, this is about experiencing the site the way users experience it. This audit is meant to track and record the structure of the site as it really works.

    Setting up the template

    First, we’re gonna need another spreadsheet. (Look, it is not my fault that spreadsheets are the perfect system for recording audit data. I don’t make the rules.)

    Because this involves building a spreadsheet from scratch, I keep a “template” at the top of my audit files—rows that I can copy and paste into each new audit (Fig 4.1). It’s a color-coded outline key that helps me track my page hierarchy and my place in the auditing process. When auditing thousands of pages, it’s easy to get dizzyingly lost, particularly when coming back into the sheet after a break; the key helps me stay oriented, no matter how deep the rabbit hole.

    Fig 4.1: I use a color-coded outline key to record page hierarchy as I move through the audit. Wait, how many circles did Dante write about?

    Color-coding

    Color is the easiest, quickest way to convey page depth at a glance. The repetition of black text, white cells, and gray lines can have a numbing effect—too many rows of sameness, and your eyes glaze over. My coloring may result in a spreadsheet that looks like a twee box of macarons, but at least I know, instantly, where I am.

    The exact colors don’t really matter, but I find that the familiar mental model of a rainbow helps with recognition—the cooler the row color, the deeper into the site I know I must be.

    The nested rainbow of pages is great when you’re auditing neatly nested pages—but most websites color outside the lines (pun extremely intended) with their structure. I leave my orderly rainbow behind to capture duplicate pages, circular links, external navigation, and other inconsistencies like:

    • On-page navigation. A bright text color denotes pages that are accessible via links within page content—not through the navigation. These pages are critical to site structure but are easily overlooked. Not every page needs to be displayed in the navigation menus, of course—news articles are a perfect example—but sometimes this indicates publishing errors.
    • External links. These are navigation links that go to pages outside the domain. They might be social media pages, or even sites held by the same company—but if the domain isn’t the one I’m auditing, I don’t need to follow it. I do need to note its existence in my spreadsheet, so I color the text as the red flag that it is. (As a general rule, I steer clients away from placing external links in navigation, in order to maintain a consistent experience. If there’s a need to send users offsite, I’ll suggest using a contextual, on-page link.)
    • Files. This mostly refers to PDFs, but can include Word files, slide decks, or anything else that requires downloading. As with external links, I want to capture anything that might disrupt the in-site browsing experience. (My audits usually filter out PDFs, but for organizations that overuse them, I’ll audit them separately to show how much “website” content is locked inside.)
    • Unknown hierarchy. Every once in a while, there’s a page that doesn’t seem to belong anywhere—maybe it’s missing from the menu, while its URL suggests it belongs in one section and its navigation scheme suggests another. These pages need to be discussed with their owners to determine whether the content needs to be considered in the new site.
    • Crosslinks. These are navigation links for pages that canonically live in a different section of the site—in other words, they’re duplicates. This often happens in footer navigation, which may repeat the main navigation or surface links to deeper-but-important pages (like a Contact page or a privacy policy). I don’t want to record the same information about the page twice, but I do need to know where the crosslink is, so I can track different paths to the content. I color these cells gray so they don’t draw my attention.

    Note that coloring every row (and indenting, as you’ll see in a moment) can be a tedious process—unless you rely on Excel’s formatting brush. That tool applies all the right styles in just two quick clicks.

    Outlines and page IDs

    Color-coding is half of my template; the other half is the outline, which is how I keep track of the structure itself. (No big deal, just the entire point of the spreadsheet.)

    Every page in the site gets assigned an ID. You are assigning this number; it doesn’t correspond to anything but your own perception of the navigation. This number does three things for you:

    1. It associates pages with their place in the site hierarchy. Decimals indicate levels, so the page ID can be decoded as the page’s place in the system.
    2. It gives each page a unique identifier, so you can easily refer to a particular page—saying “2.4.1” is much clearer than “you know that one page in the fourth product category?”
    3. You can keep using the ID in other contexts, like your sitemap. Then, later, when your team decides to wireframe pages 1.1.1 and 7.0, you’ll all be working from the same understanding.

    Let me be completely honest: things might get goofy sometimes with the decimal outline. There will come a day when you’ll find yourself casually typing out “1.2.1.2.1.1.1,” and at that moment, a fellow auditor somewhere in the universe will ring a tiny gong for you.

    In addition to the IDs, I indent each level, which reinforces both the numbers and the colors. Each level down—each digit in the ID, each change in color—gets one indentation.

    I identify top-level pages with a single number: 1.0, 2.0, 3.0, etc. The next page level in the first section would be 1.1, 1.2, 1.3, and so on. I mark the homepage as 0.0, which is mildly controversial—the homepage is technically a level above—but, look: I’ve got a lot of numbers to write, and I don’t need those numbers to tell me they’re under the homepage, so this is my system. Feel free to use the numbering system that work best for you.

    Criteria and columns

    So we’ve got some secret codes for tracking hierarchy and depth, but what about other structural criteria? What are our spreadsheet columns (Fig 4.2)? In addition to a column for Page ID, here’s what I cover:

    • URL. I don’t consistently fill out this column, because I already collected this data back in my automated audit. I include it every twenty entries or so (and on crosslinks or pages with unknown hierarchy) as another way of tracking progress, and as a direct link into the site itself.
    • Menu label/link. I include this column only if I notice a lot of mismatches between links, labels, and page names. Perfect agreement isn’t required; but frequent, significant differences between the language that leads to a page and the language on the page itself may indicate inconsistencies in editorial approach or backend structures.
    • Name/headline. Think of this as “what does the page owner call it?” It may be the H1, or an H2; it may match the link that brought you here, or the page title in the browser, or it may not.
    • Page title. This is for the name of the page in the metadata. Again, I don’t use this in every audit—particularly if the site uses the same long, branded metadata title for every single page—but frequent mismatches can be useful to track.
    • Section. While the template can indicate your level, it can’t tell you which area of the site you’re in—unless you write it down. (This may differ from the section data you applied to your automated audit, taken from the URL structure; here, you’re noting the section where the page appears.)
    • Notes. Finally, I keep a column to note specific challenges, and to track patterns I’m seeing across multiple pages—things like “Different template, missing subnav” or “Only visible from previous page.” My only caution here is that if you’re planning to share this audit with another person, make sure your notes are—ahem—professional. Unless you enjoy anxiously combing through hundreds of entries to revise comments like “Wow haha nope” (not that I would know anything about that).
    Fig 4.2: A semi-complete structural audit. This view shows a lot of second- and third-level pages, as well as pages accessed through on-page navigation.

    Depending on your project needs, there may be other columns, too. If, in addition to using this spreadsheet for your new sitemap, you want to use it in migration planning or template mapping, you may want columns for new URLs, or template types. 

    You can get your own copy of my template as a downloadable Excel file. Feel free to tweak it to suit your style and needs; I know I always do. As long as your spreadsheet helps you understand the hierarchy and structure of your website, you’re good to go.

    Gathering data

    Setting up the template is one thing—actually filling it out is, admittedly, another. So how do we go from a shiny, new, naive spreadsheet to a complete, jaded, seen-some-stuff spreadsheet? I always liked Erin Kissane’s description of the process, from The Elements of Content Strategy:

    Big inventories involve a lot of black coffee, a few late nights, and a playlist of questionable but cheering music prominently featuring the soundtrack of object-collecting video game Katamari Damacy. It takes quite a while to exhaustively inventory a large site, but it’s the only way to really understand what you have to work with.

    We’re not talking about the same kind of exhaustive inventory she was describing (though I am recommending Katamari music). But even our less intensive approach is going to require your butt in a seat, your eyes on a screen, and a certain amount of patience and focus. You’re about to walk, with your fingers, through most of a website.

    Start on the homepage. (We know that not all users start there, but we’ve got to have some kind of order to this process or we’ll never get through it.) Explore the main navigation before moving on to secondary navigation structures. Move left to right, top to bottom (assuming that is your language direction) over each page, looking for the links. You want to record every page you can reasonably access on the site, noting navigational and structural considerations as you go.

    My advice as you work:

    • Use two monitors. I struggle immensely without two screens in this process, which involves constantly switching between spreadsheet and browser in rapid, tennis-match-like succession. If you don’t have access to multiple monitors, find whatever way is easiest for you to quickly flip between applications.
    • Record what you see. I generally note all visible menu links at the same level, then exhaust one section at a time. Sometimes this means I have to adjust what I initially observed, or backtrack to pages I missed earlier. You might prefer to record all data across a level before going deeper, and that would work, too. Just be consistent to minimize missed links.
    • Be alert to inconsistencies. On-page links, external links, and crosslinks can tell you a lot about the structure of the site, but they’re easy to overlook. Missed on-page links mean missed content; missed crosslinks mean duplicate work. (Note: the further you get into the site, the more you’ll start seeing crosslinks, given all the pages you’ve already recorded.)
    • Stick to what’s structurally relevant. A single file that’s not part of a larger pattern of file use is not going to change your understanding of the structure. Neither is recording every single blog post, quarterly newsletter, or news story in the archive. For content that’s dynamic, repeatable, and plentiful, I use an x in the page ID to denote more of the same. For example, a news archive with a page ID of 2.8 might show just one entry beneath it as 2.8.x; I don’t need to record every page up to 2.8.791 to understand that there are 791 articles on the site (assuming I noted that fact in an earlier content review).
    • Save. Save frequently. I cannot even begin to speak of the unfathomable heartbreak that is Microsoft Excel burning an unsaved audit to the ground.  

    Knowing which links to follow, which to record, and how best to untangle structural confusion—that improves with time and experience. Performing structural audits will not only teach you about your current site, but will help you develop fluency in systems thinking—a boon when it comes time to document the new site.

Search Engine Watch
Keep updated with major stories about search engine marketing and search engines as published by Search Engine Watch.
Search Engine Watch
ClickZ News
Breaking news, information, and analysis.
PCWorld
CNN.com - RSS Channel - App Tech Section
CNN.com delivers up-to-the-minute news and information on the latest top stories, weather, entertainment, politics and more.
CNN.com - RSS Channel - App Tech Section
 

Ако решите, че "как се прави сайт" ръководството може да бъде полезно и за други хора, моля гласувайте за сайта:

+добави в любими.ком Елате в .: BGtop.net :. Топ класацията на българските сайтове и гласувайте за този сайт!!!

Ако желаете да оставите коментар към статията, трябва да се регистрирате.