We’re in the process of a major overhaul to this plugin. There was a lot of infrastructural work to do to modernize the plugin and set the stage for a host of new features to make designers more productive when it comes to making their designs more accessible. This release incorporates a lot of that foundational work, notably:

• Annotations are now presented as Figma-native Dev Mode annotations; this greatly reduces the working overhead of the plugin and reduces visual clutter in the document. We’ve also color-coordinated the icons in the Annotation Set viewer to the labels you see in the Dev Mode annotations, making it easier to scan.
• Legacy annotation tables will automatically be migrated into the new system. The visual readout tables will be hidden when this happens, but are still accessible if you need to copy or reference them. We’ve also included a tool to clean up these old layers when you’re ready.
• Annotations are now managed in a single UI rather than being separated, based on whether they impact focus order. This means you don’t need to jump back & forth between tools to properly annotate your designs.
• We’ve organized and expanded the list of W3C roles available in the role picker. Additionally, the form now adapts to the role, offering you only the relevant fields and reducing distraction. We also added a description field, should you need it.

We also fixed bugs related to duplicating layers. You can now copy layers and the annotations will go along for the ride, becoming a new Annotation Set. Similarly, you can now duplicate pages and the annotations — which are page-bound — will be re-generated. It’s worth noting that this may take some time on particularly large pages.

This release has been a long time coming, but I’m incredibly proud of the team that’s been working so diligently on this, particularly Ashish Singh from HCL and Michael Fairchild, Scott O’Hara, and Ben Truelove from Microsoft. Their attention to detail and encyclopedic knowledge of accessibility has been instrumental in getting this project to the place that it is.

And there’s more to come!

# The CSS Setup

The theming of this particular project uses CSS custom properties. For simplicty I’m going to set up two named colors and then use two theme-specific custom properties to apply them in the default light theme and the dark theme:

:root{–color-dark: #222;–color-light:rgba(255, 255, 255, 0.5);–color-background:var(–color-light);–color-foreground:var(–color-dark);}@media(prefers-color-scheme: dark){:root{–color-background:var(–color-dark);–color-foreground:var(–color-light);}}

# Applying the Theme to Canvas

To get the theme into my canvas-related code, I set up a theme object to hold the values:

const theme ={};

Next, I wrote a function to pull in the theme colors using window.getComputedStyle(). After defining the function, I call it immediately to populate the theme object:

functionimportTheme(){theme.foreground =window.getComputedStyle(document.documentElement).getPropertyValue(“–color-foreground”).trim()||“black”;theme.background =window.getComputedStyle(document.documentElement).getPropertyValue(“–color-background”).trim()||“white”;}importTheme();

I set this up with just two theme colors, but you can import as many (or few) as you like. Be sure to set a sensible default or fallback for each color though, just in case your theme’s custom property names change.

With this in place, I can set my canvas animation’s colors by referencing them from the theme object. For example:

context.fillStyle = theme.foreground;

# Keeping Things in Sync

The final bit of magic comes when you add an event listener to a MediaQueryList:

const mediaQuery = window.matchMedia(“(prefers-color-scheme: dark)”);mediaQuery.addEventListener(“change”, importTheme);

Here I’ve used matchMedia() to get a MediaQueryList object. Typically we use the matches property of this object to establish whether the media query currently matches or not. A lesser-known option, however, is that you can attach an event listener to it that will be triggered whenever the query’s status changes. So cool! With this in place, the canvas contents will update whenever the user’s theme changes. Here’s an example of that:

# Demo

I put together a quick demo of this in a fork of Alvin Shaw’s Canvas Sine Wave Experiment:

Hopefully this is helpful to someone out there. Happy theming!

First off, I agree with his core message: designers should understand the medium they are working in, be it web or an OS-specific UI. That’s where my agreements end, however.

They pat themselves on the back, believing they’ve mastered digital design. Meanwhile, a developer glances at the file, sighs, and codes the button in five minutes.

Condescention toward designers aside, this also assumes a high degree of competency and understanding of nuance on the engineering side which — in my experience — is not guaranteed. I cannot tell you how often I’ve designed an interface that calls for a button to submit a form and I get back a div with a click handler that can’t accept focus and has no design considerations for hover, focus, etc. In other words, if I provided a design with a single button on it, I get that button exactly. Sometimes exactly to those explicit dimensions, text overflow be damned.

There needs to be an acknowledgement and appreciation that designers know their craft and (generally) have good reasons for being overly prescriptive. Do some designers stray into realms of self-indulgence… absolutely! But so do engineers.

I think where we need to get to is a place where handoff provides enough information to inform the engineer of the totality of what’s needed. Sure, to a seasoned engineer that may seem overly detailed, but to a junior engineer it can be incredibly helpful in learning all of the considerations of something as seemingly simple as a button. And even a seasoned engineer might learn a thing (or three) from annotations regarding accessibility and such. Communication is the key to success here.

Also, some prototyping in a tool like Figma can help with catching issues — like keyboard traps, for instance — before they are codified into code. Making changes in Figma or other design tools is generally a lot cheaper that doing it in code. Back of the napkin math — which is generally agreed upon across the industry — is that catching & fixing an accessibility issue in design costs about $100. In development, it’s like $1,000. If it sneaks into production, it’s gonna be more like $10,000.

To be clear, I’m not disagreeing with the piece in its entirety — designers should learn their medium (which is coding to a degree but also UX expectations) and Figma’s not the medium — but I think there’s more nuance to it. I also dislike the us vs. them framing; we’re all in this together.

# What’s the issue?

Not to pick on anyone in particular, but consider this example from a recent talk I gave:

When CSS fails to load, however, check out what happens:

Yeah, that’s an inline SVG. You see, without any explicit dimensions set, the SVG will naturally grow to become as large as possible. Chances are you’re constraining that growth in CSS somewhere, but when your CSS fails to apply for any reason, every inline SVG on your site will swell like Violet Beauregarde after eating Willy Wonka’s “three-course dinner” chewing gum.

# How do we solve this?

Thankfully, this is a pretty easy situation to avoid: just set an explicit width and height. To use an example from this site, instead of saying

<svgviewBox=“0 0 38 48”version=“1.1”xmlns=“http://www.w3.org/2000/svg”></svg>

You can explicitly set the width and height in the svg element like this:

<svgwidth=“38”height=“48”viewBox=“0 0 38 48”version=“1.1”xmlns=“http://www.w3.org/2000/svg”></svg>

What you set these values to will likely vary depending on how the icon is being used. In a pinch, you could also pull the values directly from the viewbox value. And using that value, you could even make the inline values dynamic within your template, reading in the viewbox values and tweaking them to a ratio specific to the context.

Setting the SVG’s dimensions inline like this doesn’t restrict their flexibility either. You can still use CSS to override these inline values and set the SVG to whatever size you wish:

svg{inline-size: 200px;block-size: 200px;}

I’ve thrown together a quick comparison over on CodePen so you can see the three different states:

And now that you know, please, please, please take a few minutes to make this small, simple change to your websites. While not a catastrophic issue, taking care to control how your sites render in the worst of circumstances goes a long way to demonstrating thoughtful consideration of your users.

Update: For more in-depth info on this topic (and scenarios where CSS isn’t applied to your SVGs), be sure to check out this piece from Sara Soueidan.

I’ve worked on the web for a long time. When I say a long time, I mean a long time. As in my first browser was on the command line old. As in my first back-end development was a CGI script old. With my nearly three decades of building dozens upon dozens of projects for the web, the one skill I’ve found most valuable is the ability to bridge the gaps between the worlds of design, user experience, and development.

Each of these fields attract practitioners from different education and/or hobbyist backgrounds. This can be a point of tension, as folks in each camp tend to see their own field as having the greatest influence on a web project’s success. The reality is that web exists in the nexus of these fields, relying equally on what each of these practices bring to the table. I have found that the most valuable people in any web project are those that understand enough of each field to be able to operate in that nexus, ensuring each team is communicating effectively with the other teams and that everyone is working together toward a shared goal.

Which brings me to Stephanie Stimac’s Design for Developers. This book is an invaluable resource for developers looking to level up in their understanding of what it takes to build for the web today. It provides a crash course in design and user experience in a way that will both improve your fluency with these topics and give you the necessary skills to become productive in these spaces as well. Beyond that superficial perspective, however, this book provides the foundation for leveling up your career and becoming the person who thrives in the space between design, user experience, and development.

Stephanie is the perfect person to provide you with these insights as well. Not only is she an excellent communicator, she also has years of working experience as a designer, developer, user experience practitioner, and an educator. She’s even worked behind the scenes on web browsers and the web standards they implement, giving her an incredible depth of understanding when it comes to the web and the tools we rely on to build it.

Whether you’re a longtime developer looking to grow a new branch on your skill tree or you’re starting out and looking to get a solid foundation in what it takes to build for the web, Design for Developers is sure to provide you with a wealth of knowledge to help you on your way.

Which brings me to the subject at hand: 303 Creative LLC v. Elenis. I tweeted about this case, which is currently before the Supreme Court of the United States, the other day, but felt like I owed it a lengthier—and perhaps more enduring—discussion. So here goes…

# The case, in a nutshell

Lorie Smith, a web designer operating as 303 Creative LLC, is interested in getting into the wedding announcement website game. She does not believe same-sex couples should be able to marry, so she wanted to put a notice on her website to that effect, stating that she would not create wedding announcements for same-sex weddings. This violates Colorado’s anti-discrimination law (some of you may recall it from Masterpiece Cakeshop v. Colorado Civil Rights Commission) which prevents public businesses from discriminating against gay people, who are a “protected class” in legal speak.

Smith contests that her web design work is her “expression” as an “artist” and that the First Amendment protects her right to that expression. What a lot of the coverage fails to include, however, is

1. She does not currently offer wedding announcement website services, and
2. No same-sex couples have requested her services in creating a wedding announcement website.

In other words, this case is not based on fact, but rather on hypotheticals. Additionally, there has been no injury on either side, just the potential for one. Anyway, if you’re interested in learning more about the case, you can check out the following:

• 303 Creative LLC v Elenis on Wikipedia
• Court Docket at the Supreme Court
• Oral Arguments before the Supreme Court
• Strict Scrutiny podcast episode following oral arguments
• Boom! Lawyered podcast episode following oral arguments

In particular, I highly recommend listening to Justices Ketanji Brown Jackson’s and Sonia Sotomayor’s contributions during oral arguments as they really cut through the bullshit and get to the heart of the case and its implications.

# Fact: Design ≠ Art

This is something I talked about way back in my 2013 talk “Designing With Empathy”: Design is not art. Art is self-expression and serves the artist; design serves someone else (typically the client or their audience). If you don’t work in the industry, however, this distinction isn’t always clear. To quote Jeff Veen:

I’ve been amazed at how often those outside the discipline of design assume that what designers do is decoration. Good design is problem solving.

Design is not the creation of pretty pictures and decoration. Design serves a purpose. In fact, the term “design” originated in Medieval Latin as designare which meant “to mark out” (hence the related term designate). To design is “to devise for a specific function or end.” To practice “web design” is to use the tools of graphic design to achieve the purpose of the project.

In the context 303 Creative LLC seeks to operate, the purpose of each project would be to announce and provide the details about a wedding. 303 Creative LLC seeks to provide these services in exchange for money, at the behest of a client. It is not artistic expression any way you slice it.

# Fact: This Case is About Advertising Bigotry

If you’ve run any sort of service business, you’ve likely come across clients and projects you had to turn away. Sometimes you don’t have the bandwidth to take on the project. Other times you may not be interested in the kind of work it entails. Still others, you might not have the right expertise to do the project justice. And sometimes you just get a sense that the potential client is not someone you’d work well with (perhaps based on the tone of their inquiry). Regardless of the reason, however, you can gently explain to them that you cannot do the project for them and either leave it at that or recommend someone who might be able to help them.

In the case of 303 Creative LLC, Smith could have easily used this approach to turn away same-sex couples without making it a thing. She could even have a form email prepared for this very purpose! And unless several couples approached her at roughly the same time and got wildly different responses with respect to her ability to create them a wedding website—which, to reiterate, is not a service she currently offers—no one would be any the wiser when it came to her belief that same-sex marriage doesn’t (or shouldn’t) exist.

But no, that’s not the route that Ms. Smith and 303 Creative LLC seeks to go. Instead, she would like to be able to express her “firmly held religious belief” that same-sex marriages should not happen and to put a notice on her website explicitly saying she refuses to create a website for a same-sex wedding. She wants to put her bigotry on full display and she doesn’t think she should suffer any legal consequences for doing so.

# Clarification: Who qualifies as “Protected”?

Over on Mastodon, I was asked to clarify whether the law allows you to refuse to work for a particular individual or corporation. For example, could a web designer refuse to do work for Chick-fil-a on account of their anti-LGBTQIA+ positions (a stance which I think they’ve reversed, but I don’t eat there so I’m not sure). A similar question was asked in Oral Arguments, framed as a speech writer’s ability to refuse to write a speech for a political candidate they disagree with. Public accommodations law, which is what is being considered in this case, would not require you to work on any project for anyone as long as the reason you are refusing your service is not on account of their membership in a protected class.

Corporations are not a protected class. Neither are politicians. Same-sex couples are protected from discrimination under both the Equal Pay Act of 1963 and the Civil Rights Act of 1964.

# Potential Fallout

If the conservative majority on the Court decides to ignore all of the facts in this case an rule in favor of 303 Creative LLC, that decision will open the floodgates for discrimination against people based on their protected status by anyone who claims to have a religious objection to treating that person respectfully.

For example, people with disabilities are a protected class under the Americans with Disabilities Act. If this ruling goes in 303 Creative LLC’s favor, a business owner could claim eugenics as a “firmly held religious view” and refuse to provide accommodations for them. From the web side of things, that could mean they could intentionally make their site inaccessible to people who use screen readers. In the physical world, it could mean they could make entry to their business impossible for anyone using a wheelchair.

It might take a little time, but we’d likely end up in another “Jim Crow”-like era where restaurants are once again free to adorn their windows with “Whites Only” signs. Where the grocery store hangs a “Christians Only” sign on its door. Where the local bank proudly announces that only “Heterosexual Evangelical Christian Women” can apply for an open teller position. Where only women under 25 can date Leonardo DiCaprio… wait.

Instead of embracing our differences as a complement to one another and for the betterment of our society, condoning this would further drive us apart and foster a world of exclusion. People could use their religion to mask their bigotry and claim exemption from having to provide equal access to people based on their disabilities, gender (or gender expression), sexual orientation, racial characteristics, religion, age, or any other protected category. That’s not a world I want to live in nor is it a future I want for my kid.

If it comes to pass, I suppose the one silver lining is that we’ll learn what companies deserve our business, but that hardly outweighs the potential harms for people who need access to food, clothing, shelter, information, and other necessities for existence both online and off that are supposed to be guaranteed by anti-discrimination laws.

It’s all in the Supreme Court’s hands at this point, but I am more than a little concerned with what this could mean for the future here in the United States.

When we compared average number of fixations and average amount of time people spent looking at each page, we found that:

• The average amount of time was significantly higher on the weak-signifier versions than the strong-signifier versions. On average participants spent 22% more time (i.e., slower task performance) looking at the pages with weak signifiers.
• The average number of fixations was significantly higher on the weak-signifier versions than the strong-signifier versions. On average, people had 25% more fixations on the pages with weak signifiers.
• (Both findings were significant by a paired t-test with sites as the random factor, p < 0.05.)

This means that, when looking at a design with weak signifiers, users spent more time looking at the page, and they had to look at more elements on the page. Since this experiment used targeted findability tasks, more time and effort spent looking around the page are not good. These findings don’t mean that users were more “engaged” with the pages. Instead, they suggest that participants struggled to locate the element they wanted, or weren’t confident when they first saw it.

Do you know where our fascination with averages began? It all started with Adolphe Quételet, a Belgian mathematician and astronomer:

In the 1830s, astronomers were some of the only people that regularly calculated averages, since early telescopes were extremely imprecise. To obtain more accurate data for say, tracking the orbits of planets, astronomers would take multiple measurements (all of which were slightly different) add them together, then divide by the number of observations to get a better approximation of the true value.

Quetelet decided to apply this tool to people, starting with Scottish soldiers’ chest sizes. Turns out the average chest size of a Scottish soldier in the 1830s was 39.75 inches. File that one away for Pub Trivia.

Quetelet believed that the average was the “true” size of something… something that we should strive for or that nature would attempt to create. The Platonic ideal if you will:

In Quetelet’s mind, human averages had a certain moral mandate. By his logic, if everyone were optimally fed and lived under the same environmental conditions, they would be average. And this is what society should be striving for: the continual improvement of the average of the group.

We look at averages all the time in our work. Some, like average Time To Interactive (TTI), are useful measurements that allow us to improve our work; others, like the “average” user are decidedly less so. The “average” person (or dog or flower) is a myth. Everyone and everything is unique to some equally unique degree.Even mass-produced objects have variance.

Designing for the “average” user is incredibly problematic. The episode I mentioned captured this perfectly in a story about the U.S. Army’s design of airplane cockpits:

[I]n 1926, when the Army designed its first airplane cockpit, they measured the physical dimensions of male pilots and calculated the average measurement of their height, weight, arm-length and other dimensions.

The results determined the size and shape of the seat, the distance to the pedals and the stick, and even the shape of the flight helmets. This mean that, in part, pilots were selected based on their ability to fit into the cockpit designed for the average 1920s man.

This worked more or less up until World War II, when the Army began recruiting hundreds of new pilots to expand its air forces (which became a separate branch of the military in 1947). But with the birth and expansion of the Air Force came a decline in performance and a rash of deaths. Even with no war, pilots continued to die during training, as they were unable to control their planes.

The high death rate in the Air Force was a mystery for many years, but after blaming the pilots and their training programs, the military finally realized that the cockpit itself was to blame, that it didn’t actually fit most pilots.

In 1950, the Air Force sent Gilbert S. Daniels out to collect ten measurements from thousands of airmen—yes, they were all men at the time—across the U.S. in order to establish a new average. After collecting the data, Daniels got curious and decided to see how many of the airmen he measured hit the average on all ten measurements. Not a single one. How about three of the measurements? Less than five percent. He realized that in designing for an average, they were, in fact, designing for no one. Based on this discovery, the Air Force commissioned new equipment that including features like adjustable foot pedals, helmet straps, flight suits, and seats. And, wonder of wonders, pilot performance improved dramatically.

When we design, we need to be cognizant of the variety of human experience and plan accordingly. For our work to be successful, we need to accommodate the adjustments our users require for them to be successful. Responsive layouts, adaptive interfaces, support for assistive technologies… all of these approaches enable our work to go further by enabling it to be tailored to the permanent, temporary, and/or situational needs of our users.

All of this is to say, this episode made me an even more ardent believer in the idea of progressive enhancement and the continuum of experience it enables. You should go listen to it now, I promise there’s more to the story.

But why this urge to re-style page elements that end-users are familiar with? … Or is it that we love native look and feel, except when we don’t?

Speaking as the guy who not only wrote JavaScript to help me create an accessible select element alternative, but who also made it the focus of a case study (PNG, 128kB) in AdvancED DOM Scripting, I am fully aware of the desire to have it both ways. I have not often seen the desire for both in a single individual, but it does happen in one particular instance occasionally.

Based on my own experience, I see the following arguments in favor of changing the display of a browser-delivered UI control quite often:

1. It doesn’t look good to me.
2. It is not “on brand”.
3. It clashes with our brand’s color scheme.
4. We want the web experience to feel like a platform-specific app.
5. It doesn’t behave how we think it should.

(n.b. Browsers have done a pretty good job reducing the amount of color and the overall visual strength used in their UI controls to help them better blend in with a wide variety of designs, so clashes as mentioned in #3 happen far less often than they did nearly a decade ago.)

As the weathered, battle tested (and, admittedly, somewhat jaded) front-end dev that I am, I typically push back with one or more of the following:

# In Addressing Desired Design Changes

In terms of aesthetics (addressing arguments 1, 2, and 3), I understand where you’re coming from. Browser-delivered UI controls are not the most appealing things, but they are familiar to your users. A select box they see on your site that looks like the one they see on Wikipedia or their banking site will be immediately recognizable. Sure, the looks and feel may differ from browser to browser, but most people use only a small number of browsers throughout the day—at work, at home, on their device—and if you want to ensure the design of a form control feels “right” in the browser they are using, sometimes it’s best to let go of that control.

# In Addressing OS Parity

I can understand the desire to have a form control in a web page look and feel like the same (or a similar) control within the operating system (argument 4), but I am not sure that’s a rabbit hole you want to go down. Here’s why: Achieving exact design and functional parity between a platform-specific control and a web control quite often requires extra markup, a bunch of CSS, and a bit of JavaScript. Anything is achievable with unlimited time and budget, so it’s completely doable, but it would be good to estimate the cost to see if you still think it is a worthwhile endeavor.

Assuming it is, we then have the question of which operating system to model the control after. Or maybe you want to offer a different take on the control based on the operating system your user is using. In that case, we may need to multiply the original estimate by the number of operating systems you want to support. But it’s worth noting that, in the Android world, different device manufacturers often “skin” the operating system to look different from other ones. Sometimes they even do it on a device-by-device basis. We’ll need to figure out which ones you want to include in your platform-like control matrix and multiply the estimate accordingly.

Then there’s maintenance. We’ll need to test these platform-like controls on each of their corresponding platforms and test the script that determines which experience gets delivered to which device to make sure we’re not accidentally sending the wrong experience. We’ll also need to test the delivery script on every other browser in our test matrix to ensure it is not causing issues there.

What should we do when a new operating system version is rolled out? iOS, for example, has made radical shifts in the design of their platform-specific controls in each major release. We’ll probably want to create unique versions of the control for each version of each OS we support and we’ll need to keep tabs on upgrades so we don’t end up confusing our users if they visit our site in iOS 7 and have a control that looks like it’s from iOS 6. We’ll need to add the number of OS versions into the multiplier as well.

Ok, and finally: How many controls did you want to apply this approach to again?

Or we could use the browser-delivered form control and it will just work.

# In Addressing Altered Behavior

I completely agree that not all browser-delivered UI controls work exactly how I would like, but there are several risks in changing the expected behavior.

First of all, there’s the possibility we could actually end up making the interface more confusing or that the change in behavior might not be exactly what our user’s wanted (either based on what they are used to or our mental model not aligning with theirs). In order to rule out these issues, we should run a few rounds of usability tests. These could be quick café tests or more formal studies depending on the budget.

Assuming our tests go well, we will need to maintain this code and do all of the requisite browser testing. And potentially upgrade our code as new browsers and browser versions come out. Depending on the complexity of the code, this could become a large requirement, but if it is ultimately in the service of making the web a better, more usable interaction environment, it could be worth it.

For what it’s worth, if we go this route and are successful, we should consider getting involved in the spec-writing process at the W3C or WhatWG. We should contribute our recommended changes back to the community and share what we learned. If we make a compelling argument, perhaps our idea will become part of some future standard and we can taper off our browser testing when the change lands in the platform.

As you can probably tell, I’m not a really big fan of changing existing controls as I feel it can amount to a wasted effort. That said, if there are design improvements to be made—“design” in the true sense: being about how usable something is, not just how aesthetically-pleasing it is to someone (e.g. improving contrast, making the control more intuitive, etc.)—I’m willing to accept the change as something we should do and then work to make sure that change has been vetted and, if successful, given away for inclusion in other projects. If it solves a major issue on the web, I want to give that change every opportunity to make it into the appropriate spec by talking to the appropriate folks about it both in-person, in blog posts, and on the appropriate mailing list. If the change solves a problem in a specific browser, I want to see it incorporated into said browser and will file a bug report and try to build momentum around it by engaging the community.

Anyway, that’s my general position on augmenting browser-delivered UI controls. What are your thoughts on the topic?

Note: I no longer use “native” in this context, but it remains in quoted material.

An interface inventory is similar to a content inventory, only instead of sifting through and categorizing content, you’re taking stock and categorizing the components making up your website, app, intranet, hoobadyboop, or whatever (it doesn’t matter). An interface inventory is a comprehensive collection of the bits and pieces that make up your interface.

Interface inventories are a great way to take stock of the design consistency (or inconsistency) of your site and are a typical first step in creating a pattern library. After all, you need to know what patterns you have before you can document them.

In his article, Brad offers a Keynote template for gathering your screenshots, but I have been living in Evernote lately, so I wanted to take a moment to show off how you might use Evernote’s tools to simplify the process of building an interface inventory. If you don’t have an Evernote account, you can get a free one here.

One method of getting screenshots into Evernote is using Skitch. Skitch was originally developed by plasq, but was acquired by Evernote in 2011. It is a general purpose screenshotting tool that supports annotations, etc.

Here’s a quick run-down on how to use Skitch to build your interface inventory:

Step 1: Create a new Notebook for your interface inventory and adjust the Skitch preferences so it uses it.

Step 2: Click the “Screen Snap” button and adjust the crop tool to contain the interface object you want to capture.

Step 3: Rinse & repeat.

When Skitch syncs up to Evernote, your screenshots will magically appear on any device you have.

Another route to go involves the Evernote Web Clipper. This add-on is available for pretty much every browser and is available as a bookmarklet to boot.

Using the Web Clipper is every bit as simple as it is with Skitch. Possibly moreso. One bonus is that you have the benefit of being able to direct your individual clips to different notebooks within Evernote. Simply click the Web Clipper button, select the area to clip, and choose where you want the clip to go. You can even add any tags you might find useful.

Either way you go, you will eventually end up with a nice little collection of interface artifacts in Evernote which are, in turn, available on the web and on any device where you have Evernote installed.

The nice thing about using a tool like Evernote for creating an interface inventory is that you can share this notebook with your colleagues to speed up the documentation. Simply divide up your interface into categories and go on a scavenger hunt. All of the snaps will sync to the same place and become a part of your interface inventory. Done and done.

Happy snapping!

In this session, I explore why empathy is a good thing, how empathy empowers creativity, and how we, as a community, can inject more empathy into our work.