One thing that’s been missing is being able to have an idea of which pages on my website are getting visits, and what some of the referring sites are.

After successfully setting up Webmentions for Jekyll to capture incoming mentions from other website creators (an entirely different post!), I decided to look for an easy way to collect usage data from the site.

Measuring use, not users

Before I started looking at options, I reflected on what data I wanted to gather:

• which pages on my site are being accessed,
• how many times, and
• how people got there.

I didn’t want to collect data about the people using my site - just how it’s being used.

Tech requirements

I’ve worked with a number of web analytics tools over the years - AwStats, Urchin, Google Analytics, Matomo. GA is the giant player because it is free and thus ubiquitous. (Check out the Google Analytics stats on BuiltWith if you want to truly see how popular it is.) And as the adage goes, when a product with this many features is free, it’s because you and your users are the product.

Beyond my privacy concerns with Google Analytics, I just don’t need all of that! I get overwhelmed when I log in to check on other projects I’m working on because the UI is just so impenetrable. I don’t need all that data, and I certainly don’t need to be calling all those Javascript files and trackers all over my website.

When I started looking at alternatives, I wanted a tool that:

• Has a non-Javascript option
• Only collects the info I want to collect
• Doesn’t invade my visitors’ privacy
• Is hosted or easily hosted by me
• Is easy to use and understand
• Is low-cost

Choosing SimpleAnalytics

I did some shopping around, and to my delight, there are some really fantastic options out there for privacy-respecting analytics packages, many of them from Europe due to the GDPR requirements.

Of the many products I explored, SimpleAnalytics was one that matched my list of requirements best because it can be used without Javascript.

No Javascript required

The instructions for installing SimpleAnalytics are straightforward: call an external Javascript file, and if your users have Javascript turned off, use a tracking GIF as a fallback. The GIF returns less data than the Javascript method does (which is actually great!). Even better, the image file can be the primary way that data makes it to SimpleAnalytics, rather than just a fallback.

But also maybe some light Javascript

After tinkering with the GIF-only analytics implementation a bit, I realized I could send more information consistently using the GIF if I added some parameters to the URL for the image file. The data points I really wanted to capture reliably were referrer, which isn’t available by default with the GIF, and page path , which can be reported less reliably using the GIF.

To be able to identify these variables and add them to the link to the GIF, I’d need to add some Javascript on the page. One of the things I loved about moving to Jekyll was that I didn’t have any Javascript on my site, but adding these few lines was an acceptable compromise for me - still better than calling a huge external file, and it also allowed me to hand-tailor what attributes I sent to analytics.

Here’s where I landed - a quick script in the footer template of my site that…

• pulls in the full hostname and pathname of the current page
• grabs the referring URL if there is one
• concatenates everything into the full URL to the GIF
• builds an <img> tag to render the GIF on the page and send the analytics

Code

Note: I wrote another version of this script that collects the user’s time zone, just to complete the set of attributes that can be sent using the GIF with SimpleAnalytics.

Second note: Yes, I realize that embedding a Gist is embedding an external Javascript. The difference here is that it’s not on every single page of my site, and it isn’t tracking users.

We’ll see!

The SimpleAnalytics free plan keeps the data for only 30 days, which is also a feature and not a bug to me. I signed myself up for weekly reports in my email inbox so I can set it and forget it.

This is yet another example of choosing to change tech platforms and just seeing what happens. This is a really low-stakes test for me and was very gratifying to get up and running.

Postscript: Making shit feels good

With this and my other tech-focused posts this year, I’ve been finding a lot of grounding during a time of looming fascism in the USA by being able to enter a flow state, learn some new stuff, and create something with my hands. Ethan Marcotte has written about this on his blog and I continue to think about how, coupled with other actions in our communities, making things can be a way to keep sane and build a future we want to see. Even if it’s 12 lines of Javascript code.

Our digital ecosystem is big, and there are scores of teams using our design system to build their products (What is a design system?). Our design system has been around a while, it’s super-robust, and it has buy-in across the organization. My team’s main job is to meet with other teams throughout their design process to make sure that the teams’ products align with the rest of the website, meet web and accessibility standards, and of course, use our design system appropriately.

This doesn’t happen all the time, but there are some recurring patterns I’ve observed as product teams work with our design system. I don’t think this is unique to our context; I’d wager that these are totally normal things that happen when a design system matures and is in active use by a lot of teams.

1. Design by number

What it is

Instead of designing an experience or an interaction, the team puts design system components on a page (or in a Figma file) to create an interface, without thinking about the actual user experience. Components are chosen because of how they look, not because of what they do. It’s not UX so much as paint by number. The design has features you recognize, but that’s where the familiarity ends.

Why it happens

• Inexperienced designers: Designers who take this approach are often new or inexperienced, undersupported, or stretched too thin.
• Free-ranging stakeholders: A non-designer stakeholder is exerting undue influence on the design, or is being inflexible about business rules, and designers are not empowered or knowledgeable enough to push back. Common signals that a stakeholder is pulling the strings:
  • ”We’ll need to get approval for that change.”
  • “Our stakeholder said we need to do it this way.”

The result

If you have a pre-launch QA process for products (as we do), those design issues, if not caught early, result in a ton of problems that need to be fixed before the product goes live. If those findings aren’t deemed important enough to fix before go-live, they go to the team’s backlog to die, and the user experience suffers.

If the product ships as-is, it looks like the rest of your site in some ways, but it’s unusable, inaccessible (or 508-compliant only, rather than truly accessible) and you’re not sure what it’s supposed to do. It doesn’t actually help your users.

Interventions

• Designers: Focus on clearly defining the problem to be solved, creating user flows before moving to the toolbox of high-fidelity tools.
• Designers: Design for mobile first Designing for a small screen (or high browser zoom) streamlines design and really forces decision-making about the most important elements and interactions. If the page was laid out in one long line, what should the sequence of elements be? What headings would need to be present to help convey the content grouping and hierarchy? This results in a more accessible experience for most users, especially users who rely on assistive technologies like screen readers.
• Leaders: Mentor junior teams and designers. This problem is not specifically a design system problem, but it’s exacerbated by a readily available component library. It’s moreso an underdeveloped design ethos. Seasoned, user-centered UX designers who are trusted, mentored, and supported to do good work will know and do better. These folks not only have more experience, but are also prepared to push back when stakeholders ask for something that’s a bad solution. Junior designers can grow into this skillset if they have good mentors.

2. First-solution inertia

What it is

Because robust design systems and Figma libraries make it easier to rapidly develop high-fidelity prototypes, a team’s early design ideas can sometimes ossify too fast. At first glance, the solution seems good. On second glance, it’s clear there is something not quite right, and there is an increasing number of boo-boos being covered up. The sunk cost fallacy leads teams to keep as much of what they’ve got as possible, even if what they actually need to do is scrap it and start again.

Why it happens

• Jumps to solutioning: The design problem hasn’t been completely defined. Key information, constraints or business rules are missing.
• Favoritism: Someone (maybe a non-designer stakeholder?) has fallen in love with an early solution and doesn’t want to change course.
• Iteration creep: The design started as one thing, but has iterated so much that its functionality has left the bounds of its original design completely and no longer makes sense.
• Hotfix glue gun: The design doesn’t accommodate unanticipated stress cases, or doesn’t do well in user testing. “Adjustments” are made by adding on hotfixes rather than addressing the root issue.
• Looming deadlines: a team is far down the road with a high-fidelity design and it’s hard to stop, or to incorporate late-breaking changes, before they have a deadline to complete their work.

The result

The result is something that just ain’t quite right, an incomplete or overly complex solution that has gaps for some users with “non-standard” use cases. It’s an increasingly brittle interface that makes maintenance a bottomless pit until it can be rebuilt. This’ll create frustrating experiences for users, and it’ll be an interface that they have to learn over and over again.

Interventions

• Designers: Go lo-fi first, even when hi-fi is easy: Build lower-fidelity artifacts early in the process, even when it’s easier to jump straight into the weeds with design software. Focus on user flows, rather than getting every single detail right in the wireframes.
• Designers: Research early: Do research with users before letting the design harden.
• Designers: Engage peer reviewers: Get another set of heuristic eyes on your designs. (Either through a governance process or via peer feedback.) Bring your questions.
• Leadership: Build in slack time: Account for time in the project to make potentially breaking changes. Ensure the team is consistently revisiting those user flows from earlier in your design process to make sure you’re solving the right problems the right way.

3. Disengagement

What it is

Teams use the design system to design experiences (perhaps quite well!) but don’t contribute to the design system’s growth. Or, they may craft workarounds when the design system doesn’t do things exactly as needed, rather than suggesting changes.

Why it happens

• Lack of support from leadership: Teams aren’t incentivized, encouraged, or given space to contribute back to the design system and allow it to continue to grow, so it stagnates.
• Technical debt: Teams don’t have time to contribute to the design system because their backlog is too big, they’re moving too fast, or they are simply prioritizing other work.
• Gatekeeping: The process for contributing to the design system is opaque, or onerous, or locked down to only one team (or person!). If community members feel like they can’t or shouldn’t contribute to the design system, they don’t.
• Inflexible/rigid design system: The design system isn’t helping the teams solve their problems, or is incomplete. Or, the team’s engagement with the design system is more punitive (“Fix this or else”) than generative (“Let’s make sure this component does what you need it to do”). Rather than being seen as a toolbox, it’s a checkbox.

The result

The implications for this are system-wide. The overall user experience of your digital ecosystem can suffer. Stale, inflexible experiences don’t evolve with the times, or worse, teams abandon design system components to craft their own experiences, creating long-term maintainability problems. The end result is a degraded experience for your users, a maintainability quagmire, and inconsistent designs across your platform. In my work context, this is something we work very hard to avoid.

Interventions

• Leadership: Prioritize contributions: Product owners/product managers build time in for their teams to contribute to the design system, and actively encourage them to do so.
• Design system leads: Make contributions a snap: Design system owners should pave avenues for teams to make or suggest updates to the design system. The process for new additions to the design system, code updates or new documentation should be well-documented, communicated, and streamlined, including (and especially) for newcomers or novice coders.
• Governance and design system leads: Listen and adapt: Inflexible, brittle design systems with overly complicated processes, obtuse approval processes, or hard-to-use tech stacks are expensive to maintain because they are brittle. It’s crucial to have clear processes for using, expanding on, updating, or even retiring items from the design system. Humans who are responsible for the design system want product designers to use the system in a consistent way; but conversely, they must be listening for ways the design system can flex to meet changing needs.

tl;dr: Design systems are people

Technology is people. Design systems are people, too. Most of the issues here, and their solutions, involve deeply human stuff like relationship-building, conversation, clear documentation, conflict resolution, and feedback loops.

Like any other technology, design systems need attentive care, maintenance, upgrades, and human stewards to ensure that they’re used to do the thing they’re supposed to do. The key is being prepared to support the entire design system, including the people who are building with it.

More about PDN:

The Prosocial Design Network connects research to practice toward a world in which online spaces are healthy, productive, respect human dignity, and improve society.

Here’s their recap of the event, and a video of our Q&A segment (15 minutes).

They shared the questions in advance, which I very much appreciated! Here are my prepared notes - we certainly didn’t cover it all during the call.

What principles should be front of mind in designing inclusive digital spaces, particularly social spaces?

First off, hire people with different lived experiences from yours. Hire trans people. Hire Black people. Hire disabled people. Hire disabled Black trans people. Let them cook. Listen to them. Otherwise you are, as my wife says, “Pissing into the wind.”

Prioritize accessibility. Ensure spaces are accessible for users on many devices, using different device settings, in different contexts in the real world including with assistive technologies. Often accessibility is an afterthought. Shift left and allow it go drive your design and architecture decisions from the jump. For social apps, this includes setting smart defaults - i.e. requiring folks to add alt text if they’re uploading images.

Keep your tech stack light and boring. Design for a 4-year-old Android phone on a 3g connection, with bandwidth paid for by the megabyte. Bloatware takes longer to load and harms or disincentivizes participation from folks on slower connections or older tech.

Design for trust, privacy and safety. Design for people to be able to protect their privacy, control what they share and what they see.

• Don’t ask for information you don’t need, and tell people why you’re asking for what you do need.
• Make privacy and sharing settings crystal clear.
• Remind folks that no site is 100% secure even if you’re encrypting every bit.
• Provide feedback/reporting mechanisms.
• Allow people to block/opt out of interacting with others or groups, or types of content.
• Don’t overpromise! If you have gaps or areas still under development, name them.
• Have good documentation and support. Don’t leave people wondering what to do.
• Look to successful, intentionally-designed communities - like BlackSky - for cues about designing inclusive, safe spaces.

Allow people to define themselves. The way you do it ain’t the way everybody else does it.

• Be aware of any type of binary options when it comes to identifying themselves - not just gender, but everything else. Are you technical or nontechnical? Employed or unemployed? Full-time or part-time? In all of these cases it’s not so clear.
• Think in terms of checkboxes, not radios. Tagging, not categorizing.
• Give people freedom in choosing avatars or profile images.
• Give people freedom to change/update usernames and login email addresses without hassle.
• Don’t make inferences about who people are or what they’d like based on their gender, race or other things that they choose to share with you.
• Confront your own ideas about people having one “true identity” - like a real name policy or assuming that everyone has the same interactions with everyone in their lives in every context. We certainly know this is true because 4chan exist(ed) - but let’s also remember that this might be the way that a trans person tries on a new name for the first time.

You may have noticed this isn’t necessarily specific to trans-inclusive design. That’s because this is the kind of work that, by considering folks in marginalized positions, benefits everyone. It’s the curb cut effect for accessibility AND privacy AND safety AND inclusion. By focusing our design on the margins we include everyone between them too.

Since you wrote your article in 2019, what are fails sites continue to make when it comes to trans inclusive design?

The biggest fail I continue to see is that folks are asking for gender or sex information at all, because it is usually not needed. It usually means that this data is being brokered into a database somewhere and sold for money.

I don’t need to tell you my gender to book a hotel. Why are you asking for it?

The unnecessary asking for gender gets worse now that we are seeing a rollback of previous progress in inclusive design we had made in the past few years. We’d been doing so well! The US Web Design system had a really thoughtful pattern about asking for gender that was starting to roll out to all these government forms. But now agencies are in the process of removing the pattern for asking for gender in an inclusive way, and replacing it with a binary option for sex.

These design systems changes are in addition to removing all references to being trans from websites, and no longer offering services or information for trans people. It’s a very literal erasure of trans identity. It’s really upsetting, scary, and for trans folks, it’s existential.

I encourage practitioners to plan ahead for the moment when you are asked to do something that you know is wrong. That day will come. What will you say? What will you say no to? What’s your red line?

What new concerns do you have with AI and do you have any advice for tech folk?

I have a lot of concerns with AI. I do think there are useful applications for the technology, and 99.99% of the applications out there are either actively predatory, passively harmful, gratuitous and mid, or all of the above. And they are all harming the environment and our health.

1. Garbage in, garbage out. AI is pattern recognition. And the patterns it’s trained on are filled with bias! Bias harms people who are in the minority. According to a recent study out of Stanford:

   “synthetically generated texts from five of the most pervasive LMs …perpetuate harms of omission, subordination, and stereotyping for minoritized individuals with intersectional race, gender, and/or sexual orientation identities.” - Laissez-Faire Harms: Algorithmic Biases in Generative Language Models (2024)

2. …and this includes code. When AI is trained on design patterns or code that is widely popular, but that also includes a lot of code that’s inaccessible or unusable, the resulting code is also inaccessible or unusable. We should also be extremely wary of any AI tool that claims it can refactor a codebase written in a language that most modern coders are not using.

3. AI is a tool of capitalism and state violence. Generative AI is being used to consolidate, analyze, and generate information in a way that can be used to surveil, prosecute, incarcerate, and kill people.

4. AI is seen as a smart humanoid. People tend to believe algorithms more than each other as task complexity increases - but we also tend to view AI as human-like. We anthropomorphize AI tools by giving them human-like names or designing them as chat prompts (rather than command prompts or even search boxes), which leads us to believe that we are in fact talking with another living being rather than a computer. It also leads some folks to think that AI will become sentient. It won’t, actually, but it will if humans believe that it is, which is perhaps worse.

5. AI is mid. And by that, I mean that what it produces is functionally a middle-of-the-road, average, non-“edge case” output. This flattens our differences and creates a “norm” which actually does not exist. Individual people aren’t “normal”, but AI sure likes to tell us that’s a thing, and that really harms people who are far from that norm. Saying that everyone is the same denies the fact that we are all weird as hell. It’s our differences that make us stronger, more creative, better.

6. Critique is painted as fear. Proponents of AI say that skeptics are “afraid” of AI or don’t understand it. I, for one, am not afraid of it - I’m frustrated by how folks are positioning it as the solution to all our problems. I do understand it! I know too much. Dismissing AI detractors as “fearful” allows proponents to dismiss valid critique outright rather than engage with it. It’s a strawman argument.

   If you are AI-critique curious:

   • Algorithmic Justice League
   • Distributed AI Research Institute
   • Mystery AI Hype Theater 3000
   • We deserve better than an AI-powered future

My AI wishlist for technologists

If you don’t need to use AI, don’t. Do something else. Turn off default settings that include AI. Switch your search engine to DuckDuckGo and turn off AI features. Turn off Apple intelligence. Turn off Google Gemini. Take a harm-reduction approach to your tech use. (FWIW, this is my approach to eating animal food products. I’m not vegan or even completely vegetarian, but I don’t build my food habits around animal products, which reduces how many animal products I consume.)

Don’t make AI your main thing. Charles Eames said, “Never delegate understanding.” Don’t rely on AI alone to make decisions about what’s true, certainly not for core parts of your work.

Understand the bias that ships with your LLM. Do everything you can to critically evaluate outputs for inaccessible, biased or otherwise harmful content. Right-size your models and turn down the “creativity” setting.

Advocate for sustainable, safe AI, including regulation and environmental mitigation measures. Individual choices get us down the road a piece, but what we really need is to mitigate the impacts at a high level.

Engage your discomfort. If someone critiques AI and it makes you uncomfortable, listen to understand and be open to changing your mind. Most of the folks who are warning about the harms of AI are minoritized people - Black and brown women, queer and trans people. Believe them!

Are there any questions you think researchers could help answer regarding trans-inclusive design?

This is an excellent question. Some of the things I’d ask folks to understand include…

What are ways we can design for trust and safety? How can we create digital spaces where people feel safe? What are some of the ways we can foster trustworthiness?

What would trans-informed design look like? How can we use the very concept of transness - boundary-crossing, liminality, non-binary thinking - to expand our thinking about how technologies can be used, and to what ends?

Oliver Haimson is studying this very thing, and his new book Trans Technologies is available for free, open access, from MIT Press.

How might trans-inclusive digital design change IRL service design? We’re already seeing this as part of our work in Civic Tech, moving from automation to true digital transformation. We all know that real-world constraints map to technological design choices. How then do we transform the tech stack and use that to change our very service delivery model?

After 12 years on Wordpress, I finally moved to a static site generator. I’m writing this post in a Markdown file using Obsidian. More in the colophon.

My goal is to post more often. We’ll see how it goes!

My current role is my first job at a digital services company, my first time working on an Agile team, and the first time I haven’t been one of the only experts in the room on web technologies.

The other big differentiator? Scale.

Simply put, the projects my colleagues and I are working on are huge. Within the single government agency I’m serving, there are scores of teams working on complicated tech stacks with tons of dependencies, all in support of millions of users – our fellow citizens.

Here are a few things that I’ve observed in my shift from working within smaller digital ecosystems, to working on large-scale federal digital projects.

UX is a given

Thanks to a lot of heavy lifting by UX advocates, user experience and human-centered design are accepted (and funded) norms, rather than something that has to be fought for. User research is an imperative, and product teams are open to – and even hungry for! – their assumptions being disproven through research.

Accessibility to the front

There is a lot of good accessibility work being done in the civic tech space, specifically an accessibility beyond compliance approach that makes a lot of work in civic tech a model for how accessibility should be done in other industries. Accessibility is baked in from the beginning phases of design and development, rather than being an afterthought, an add-on, or a grudging nod to legal compliance. I’ve learned more about accessibility in the past 9 months than in the previous 9 years. There’s a long way to go, and it’s exciting that accessible, inclusive, trauma-informed design is part of everyone’s work.

We prioritize who we’re designing for

This seems obvious, but for many organizations who are trying to use their websites to do everything for everyone, the idea of designing only for certain users can be a tough sell.

We aren’t designing for agency employees, internal stakeholders or casual external audiences. We’re designing for, and prioritizing the experience of, defined groups of users.

We know our target audience(s), and acknowledge that people are visiting our websites to perform tasks. We measure results based on whether folks can do that. Though business needs show up to some degree in the design, the stuff we’re building optimizes for the user experience and task completion.

There are a lot of us

Our digital teams are cross-functional, meaning that there is some mix of front end coders, back end coders, UX designers and researchers, accessibility specialists, content strategists, and product managers working on each team. Each team is working in support of the larger project, and there are many teams that are here just to support other teams. We are all building the thing as we go. We spend a lot of time talking with other teams about what we’re working on.

Not everybody codes

Not everybody needs to know how to code to do their work well.

Email: LOL

Coming from a workplace that relied primarily (and heavily) on email for communication, it’s been a refreshing change of pace that I can count on two hands the number of emails I’ve sent since starting my job 9 months ago. Everything happens on Slack and GitHub.

This also means that we spend time optimizing processes for the best use of each of these tools. My email muscles may have atrophied, but my GitHub contribution history looks great, I have GitHub-flavored markdown syntax memorized, and I now know more about Slack workflows than most folks.

Work is in the open

All our work is paid for by taxpayers and subject to FOIA. We expect that everything we say is public. Most Slack conversations happen in open channels rather than DMs, and we’re helpfully able to hyperlink to previous conversations in other channels, creating a much more dynamic and interconnected communications ecosystem.

Meetings are focused

After years of attending faculty senate meetings that regularly ran an hour over time, I wrote in my notes the first few weeks at this gig: “People know how to run meetings here.”

If there’s a meeting on my calendar, I know who is running the meeting; what the purpose, agenda, and expected outcomes are; and how documentation will be captured. If we have to meet, we get to the point and we make it snappy. (On the flipside, it also means that we have to work intentionally to build community and rapport.)

I have one job

It has taken some time for me to get used to only having one job. My role is limited in scope, and I remain busy. Coming out of my previous role as a manager, the fact that I’m an individual contributor (IC) with a limited role has been extremely freeing. I’ve spent a lot of time focusing on improving within my practice area, learning from my colleagues, improving operational processes, and supporting my team.

No room for big egos

Everybody here is trying to do a thing to help people (or at very least, do no further harm to people). Working on projects with so many stakeholders and multiple levels of review for most decisions, it’s almost impossible to have a big ego, or hold on too closely to darling ideas, and survive.

Blameless but still accountable

The blameless approach to problem-solving asks: what if we assume that people make mistakes because of a systematic or cultural issue, rather than a personal moral failing?

Agile processes encourage us to reflect on how things are going through regular retrospectives and iterative changes. These processes allow us to identify systemic issues, including failure points, without fear of reprisal – and to still hold our teams accountable for making improvements.

Impact hits different

When working on products that have millions of users, one small change can mean a lot for users – in both good and bad ways. Any time my idea shows up in a final product design, no matter how small, I feel like a million bucks (while also hoping that the change doesn’t have unintended harmful effects for our users).

I also know that sharing my knowledge can result in a ripple effect of changes when other practitioners apply it to their work. When I shared a link to the Trans-inclusive design article I wrote almost five years ago, my coworkers applied the takeaways to the project they’re working on at an entirely different federal agency.

The potential for impact is humbling, and balances out the days when I feel like a tiny cog in a big machine.

Same problems, different scale

As much as things change, they also stay the same. For all the things I’ve seen that have been welcome changes, I’ve also seen stuff that’s been present wherever I’ve worked before:

• Varying adherence to, or buy-in for, standards
• Rushed, band-aid solutions
• Making it up as you go
• Teams working in silos, sometimes on the same problems
• Teams not taking feedback well
• Teams working on the parts but not the whole
• “Put it on the backlog. We’ll get to it later”
• Maintenance as an unsolved mystery
• Upgrades breaking stuff
• Legacy technologies secretly holding crucial components together
• Inconsistencies grudgingly accepted as a path to progress
• HIPPOs pushing through bad/precious solutions
• Weird workarounds for weirder constraints
• Constant change and turnover
• Competing priorities
• Growing pains
• Scope creep
• Failure!

The people, though.

One thing I say often is that technology is people – and civic tech as a field tends to attract folks who care very deeply about outcomes for our very human users. I have yet to meet someone who is hesitant to share ideas, give advice, or otherwise help when needed, and I have learned so very much.

This is a lightly edited transcript of our interview in September 2023, shared here with her permission.

Erin joins us today to talk about what it’s like to be an information architect within an organization and how IA’s utilize organization, labeling, navigational systems in their day to day. Welcome, Erin.

Thank you. So excited to be here.

I know, we’re really excited to have you. Before we dive into IA, why don’t you tell us a bit about yourself and your career journey?

Yeah, sure. Like like many folks in the tech space, it’s been kind of a winding path for me. I’ve been making websites since 1998, since I was like a teenager. Didn’t really have many friends but I did have a dial-up modem connection!

Eventually I found myself in a graduate program for information science at the University of North Carolina at Chapel Hill. I knew that I wanted to do digital things and I was really interested in building for the web, but I wanted a theoretical match for that, to understand why we do what we do. I learned a lot and came out on the other side as an academic librarian.

And you know this, because you hired me for my first job!

Okay. I was just thinking about that today. I think you were my first hire ever.

Yeah! It was January of 2009. I interviewed for the job at Virginia Commonwealth University. I came in as a as a web developer, and at that time, “full stack web development” was – the word didn’t exist yet, but that’s basically what I was doing. Web design, web development, a little bit of usability and UX research and a little bit of information architecture.

And then I worked at VCU Libraries for 13 years. When I left I was a department head, leading digital strategy. By the time I was in that role as a department head, I wasn’t so much doing that hands on work anymore. I was leading a team, which I loved. Eventually, though, I was looking for something new. My family relocated a year ago, my wife got a new job, and I took that as an opportunity to pivot my career.

Over the past 15+ years, the roles in web work have specialized a lot as the field has matured. IA had always been one of, like, 20 things that I’d done as part of my job. When I was job hunting earlier this year I decided to try to go all in on information architecture as a career. There’s not a lot of roles out there; there are a lot more in corporate settings and or in large scale government settings.

I had been interested in entering the federal space for a while, then applied at Ad Hoc, and here we are.

We talked a lot at my last organization about Squiggly Line careers instead of the straight path. It sounds like you’ve definitely been on that journey.

Yeah, once I got rid of that idea that I needed to have a career path that just looked like a graph going up, that it could just sort of meander, and I didn’t necessarily have to manage people in order to advance in a career or feel like I was achieving things – I think that’s when I really was able to embrace an individual contributor role, on a team.

It’s different. My current role is really…it’s been a nice fit so far.

Fantastic. What do you find in this transition to a full-time IA since you had other things in the mix – web design, web development – what’s it like to have this full time IA role?

Well, for one thing, it feels like kind of a luxury to be able to just focus in on one practice area. With larger digital shops, you have people who are able to really be focused in on their area of expertise. You have people who are content strategists, who are UX researchers, who are developers. So to to really be able to focus in on the practice area of IA has been really great, and it’s allowed my knowledge to increase really rapidly, because I’m doing it every day instead of it being, you know, one of 20 things that I’m worried about.

Another thing I’ve noticed is, there’s a permeable membrane between information architecture and more strategic work on these projects. I’ve started to work on issues at my job that are not just specific to web interfaces or digital products, but that are more 30,000-foot messy information problems. For example, if we are trying to get a handle on a set of concepts, or how to categorize or group clusters of objects, ideas, etc.

It’s been cool to be able to focus on the website, but also to know that there are thorny info problems that really need that IA brain to be able to to conceptualize, put words on things, and be able to move the conversation. It’s about creating that generative space where you get people together talking about something and you’re asking the questions to move the conversation. IAs do that a lot and it’s a skill that really translates.

Yeah, definitely. When you think about, you know, the traditional things that we learn in IA: organizational systems, labeling systems, navigational systems – how does that appear in some of the day-to-day work that you do?

I think about this a lot in day-to-day work. I’m working on a huge federal project and my team specifically is a governance team. So we work with all the other teams that are working on this digital ecosystem to make sure that what they create is consistent based on standards, and that it’s going to be a unified experience for our users.

I’m not necessarily creating site maps or generating user flows, but what I am doing is working with others to give them guidance and review their work, and make sure that we’re all solving good problems.

We talk about organization a lot. One of the cool things about about this project is that we do a lot of user research. We talk to a lot of people and really try to use that research to understand people’s mental models of what they’re doing, understand how they think, how they group items together in their brains so that we can try to match what we’re building to those conceptual models. Everybody’s got a different brain, but you can observe themes and trends and make some decisions based on that.

On the flip side, we’re working often with legacy systems and designs. This isn’t the first time we’re building, a page about a service. There was a page or entire website about that service that was developed 20 years ago. And at the time, the way that we made websites was different. We didn’t have an emphasis on user research. We were building websites that matched our organizational structures.

That’s Conway’s Law, where the software you build matches your org structure pretty much one to one.

Yeah, Conway wrote that in the sixties and we’re still seeing it in a lot of sites.

Yeah, I saw it when I started at VCU! I was joining you in your work and you were like, oh my god, this website is the library org chart, and we need to undo that.

Yep, exactly.

So there’s a lot of legacy work untangling that and reorganizing to better match how people might actually use the site and understand things.

That’s really awesome to hear about the user research. Within this class, we’ve had a lot of emphasis on user research. One group has done a card sort, and they’ve also interviewed each other to try to dig in to how people think about labeling, and really making sense of any mess, to quote Abby the IA. You know, it doesn’t matter whether you’re in a meeting or not; IA is really integral to being able to connect those dots, but also simplify language.

Yeah, absolutely. And I feel like a lot of times the IA is also the person who will be saying, “Okay, I’ve got the 30,000 foot view of the ecosystem. Let’s talk about how how all of it ties together, and how folks might understand the whole picture of what they’re working with.”

UX folks are also going to be asking those questions. There’s a really strong kinship between IA and UX, and also with accessibility. There’s been a huge emphasis on accessibility with my team, which has been great because we’ve been forefronting the needs of folks with disabilities. Not just talking about folks who use screen readers, but folks with mobility issues, with cognitive impairments. Folks who are experiencing the digital product in ways that maybe people who are abled, are not.

So that’s one that’s been one of the really cool things, just seeing how everything sort of threads together.

Absolutely. A few people in this course have pointed out different ways – they watched a video from the 90s from Dan Brown from IDEO, and there were a few things in there that weren’t really thinking about how people with disabilities might use certain things.

Yeah, and there are good articles on A List Apart as well about accessibility in general, but especially designing for cognitive differences.

One thing I’ve been thinking about a lot, especially since COVID, is that folks are dealing with either situational or long term cognitive impacts of COVID. More and more we’re seeing folks who need more considerate design, who need captions along with their videos – not necessarily because they can’t hear the audio, but because they need to be able to read and hear to understand.

So it’s, it’s just been really eye opening, especially in the past few years, how much that accessibility emphasis is coming to the fore. We’re talking about it and we’re making moves in that direction.

But the more time you spend on a product, the more you see that needs to be improved.

It’s UX vs UI. It can be beautiful, but it can be completely unusable.

Exactly. Switching gears just a little bit, how have you designed for search? Especially given your library background, I would imagine that would be a huge part of that, but maybe in your current role as well.

We think about search a lot.

The big search on the brain, of course, is our favorite consumer search engines: Google, Bing, Duck Duck Go, the big ones. We assume that most of our traffic is coming in from search rather than someone saying, “Let me just type in the web address and click through and find the page.” None of us behave like that anymore. Search is often the default.

So, that encourages us to create digital products that are going to be optimized for search.

The good news is that if you structure your content and your site well for humans, it’ll also be structured well for robots! When you create pages that are accessible and that follow standards, best practices for web creation, that boosts your search engine optimization.

Some of this may be kind of basic information, but things like,

• Do you use headings to convey the structure of the information?
• Is there a single level-one heading that is the title of the page?
• Does the page title that shows up in the browser tab, the title tag, does that clearly reflect what the page is?
• Is there text on the page that describes, “here’s what this page is about”?
• Are you using plain language?
• Are you using clear link text? Instead of links like “click here” or “learn more”, the link describes the its destination.
• Are you not stuffing your page with keywords, because most larger search engines disregard that, and they actually often weigh against keyword stuffing.

There are other things that can be done in your content management system too, like smart title tags, adding things to the meta description for the page. If you’re using WordPress or something, use an SEO plugin and make sure that you’re structuring things well. Use some of those common navigational elements like breadcrumbs in your theme that’ll show search engines how a site is structured, alongside your site navigation.

So that’s the things that we keep in mind for big search.

Many folks in the class are professional writers, and the things that you brought up about the structure of the page are so important. In an IA class, everyone’s thinking about navigation, but there’s all these other structural elements that you brought up that are really important.

Yeah! The navigability within the page, being able to place make and understand, “What am I looking at?”

Nobody’s reading every single word on a page. I don’t do it. You don’t do it. Nobody reads every single word on the page. So we gotta design for scannability, and use words that aren’t, you know, $12 words.

There’s some really good guidance from PlainLanguage.gov about how to write for the web and how to clearly structure things for folks. It not only helps search engines, but it helps your users to access the information quickly.

And, it’s an accessibility thing. It helps folks who maybe have brain fog, or folks who just need something simple and not something clever.

Right! Well, we’re almost at time, but I have a couple last questions for you. You mentioned that IA jobs are, not as abundant as other types of roles. What do you see in some of the challenges and the opportunities for the future?

There’s a ton of opportunities. The joining of the IA and the user experience spheres is very strong. We’ve got a lot of the same concerns. “How are people using our stuff? How can we make it better? Is the interface actually doing what we want it to do?”

One thing I’ve observed, and have been thinking about a lot, is how the web is transforming from this page-based model that we had. Especially in the late nineties, it was like, “Oh, it’s a website. It’s like a book. We have web pages. Sign my guest book.” We used that book mental model to think about the web.

Now, that’s kind of blown up; it’s no longer a thing. We’re having interactions that are nonlinear. We’re having chatbot interactions. Which, chatbots are a whole information architecture tangle. We’ve got people using mobile apps and mobile websites. We’ve got people interacting with different devices in different ways, across entire ecosystems with organizations.

And then we’ve also got third party websites that have information about us. So, you know, Google has information about us. But also we might have a page on Facebook or some other site where we have claimed a page.

So being able to tie that all together in a meaningful way, and to have consistent correct information, is the challenge.

One other thing that I’ll say: I’ve learned recently about Object Oriented UX, which is similar to information architecture in that it steps back from the interface part of the UX and is asking, “What are people’s mental models? What kind of objects to people envision in their brains in this space?”

That object oriented UX approach allows you to then operationalize within an interface, but it’s much more abstracted, and that’s where I really think IA is headed.

This has been amazing. I think everyone is gonna learn so much from you in this session. Is there anything else you wanted to add before we sign off?

I’m glad you said that. I would say, consider government service. There’s a ton of good work to be done, there’s a lot more attention to it recently, and there’s some legislation coming through about technology modernization that will increase the amount of funding. So there are ways to get in, especially if you’re in UX writing and content strategy.

With government work, you’re not necessarily worried about selling something. You’re worried about, are people getting what they need?

It’s mission-driven work and can be really satisfying. So, a little plug for public service.

Gov tech is taking off. I’ve noticed it too, and many of the things that we’ve looked at in class, examples for personas, we’ve pulled from Gov.UK. We’ve also pulled some examples from the USDA, which has an amazing customer experience site. So I think that definitely is helping to amp up government sector.

Yes! Gov.UK is excellent. They’re really leading the charge on a lot of civic tech and design things. Good work being done.

Thank you so much. We really appreciate it and I think this is going to be just amazing for the students.

Thanks so much for asking me.

Job hunting, simply put, sucks. Please do not let the LinkedIn influencers tell you a new job can be willed into being if you’re just passionate enough. It’s a numbers game, a crapshoot, and a deeply demoralizing mindfuck. I’m a pretty confident person and this process had me down in the dumps. I’m sharing this info in hopes that it’s helpful for others and as a record for myself when I’m on the market again.

Big themes

Some big things that I observed:

• Jobs are more plentiful in the private/tech sector and there are also more applicants, especially for fully remote jobs. Folks are hiring on a different scale. And many companies treat applicants accordingly. 🚮
• Timelines are wacky as hell. In higher ed, it can be 4 months at best between a vacancy and a hire (and for tenure-track roles, Jesus take the wheel). The private sector moves faster…mostly. I heard back from some jobs within a day or two. Others took a few weeks. Some, I never heard back from.
• Rejections are helpful and rare. I heard back with a yes or no from only half of the jobs I applied for. 👻
• Interview processes take weeks. Every place where I got to the interview stage let me know I’d be doing at least four different video calls – on different days, different weeks – to complete the interview process. This was a disjointed process and never a positive experience for me.
• Nobody shares interview questions in advance. The really kind and inclusive practice of sharing questions in advance of an interview is becoming more common in higher ed/libraries and is just hilariously nonexistent outside of those spaces. I take that back. One of the interview session leaders at one place I interviewed sent questions in advance. I was so grateful. That was the best interview session of my entire job search.
• People want to help. With few exceptions, most folks in my network were eager to help and extremely supportive. I got better at asking for, and accepting, help. Also, shoutout to my wife for her unwavering support during this time!
• My resume isn’t special. I mean, we are all special, and I stopped being so precious about my resume and asked multiple friends to help me revise it, find ways to talk about my experience, and angle myself appropriately for new roles. Separating my self-worth from my work has been a whole journey since leaving higher ed. Hopefully getting 38 rejection emails has helped move me along the continuum a little bit.
• Money hits way different. The first time I was asked, “What are your salary requirements?” I ’bout fell out of my chair. The salaries are higher in tech than in higher ed and certainly in libraries. I have sold out. This is fine.

What seemed to work for me

• Learning the language. I had never worked in the private sector before 2022. Things are just worded differently and have different names in business, so learning some of that language was helpful. I think that’s an entirely different post and I hope I get it together!
• Updating my LinkedIn After 13 years in academia I hadn’t really thought much about my profile. LinkedIn is a whole-ass weird ecosystem especially for folks in the private sector. I found some folks who I thought had good/aspirational profiles and updated mine with more details, using language similar to theirs.
• Working my network. I reached out to friends, previous colleagues and acquaintances for advice, resume reviews, and internal referrals at their companies. Most folks were very eager to help.
• Asking for informational interviews with folks who had roles similar to the ones I wanted, or who worked at companies that interested me. I tried to keep these to a half hour to respect folks’ time. These conversations helped me (1) get better language to describe my own skills and what I wanted to do; and (2) make connections with folks who could refer me for open positions later on.
• Finding companies I wanted to work for and setting up job alerts for them.
• Updating my resume for each job application. I copy/pasted lines/phrases from the job descriptions or required qualifications into my resume then made small changes.
• Keeping track. I made a spreadsheet of jobs I applied for. Title, company, link to job ad, salary range, date applied, status (applied/no response, rejected, interviewed, etc.) and any other notes I wanted to add.
• Approaching each interview as a conversation. After being on the other side of the hiring table for a very long time, I felt more confident about myself, what I brought to the table, and the types of organizations I wanted to join. I asked questions, followed up my own answers with questions, and generally tried to understand the motivation behind each question that was asked. If someone was looking for a “bias towards action” what would that mean day-to-day? I also asked about their DEI goals and challenges which was a good litmus test for how committed companies were to tackling that work.
• Letting myself feel the feels. Truly, it is hard out there, and though it’s easy to tell myself that it wasn’t about me, I often felt stressed, sad and hopeless. When I needed to I would give myself a day or two off from applying so I could rest. And I would also remind myself that I was still glad to be out of academia.

Where I looked

• Websites for companies I was interested in for remote work and companies nearby with hybrid roles that I thought would be a match for. I signed up for so many email alerts.
• LinkedIn A necessity. Lots of jobs here, searchable on many facets. Can set up push notifications and email alerts. Highly recommend.
• Indeed Many jobs here that aren’t on LinkedIn – including local jobs, hourly, contract and term-limited jobs.
• People-first Jobs Focuses specifically on organizations that (at least claim to) put supporting their people at the top of their priority list.
• Words of Mouth an extremely useful newsletter for hearing about work/fellowships/opportunities from mission-driven companies. This is especially for folks from a humanities/writing/design background.
• Tech Jobs for Good nonprofit jobs in tech – not a super high volume but worth a subscribe.
• Public Sector Job Board Rebecca Heywood compiles an excellent weekly list of government IT/tech jobs.
• We Work Remotely more startup-y; interesting feed of remote work oppportunities

Finally, I must give a huge shoutout to the amazing folks in the GLAMed Out discord community for providing support, resume review, job leads, commiseration and shared joy. If you’re thinking about leaving your work in GLAM to seek techy jobs in other sectors, reach out! I’d love to support folks going down a similar path.

Planning for the most; or, a bellwether speaks

Hi folks,

…just a visit from your future, here. I’m the ram with the bell around its neck.

I’m Erin White. This is my 11th Code4Lib!

I’m head of digital engagement at VCU Libraries in Richmond, VA.

I’m also the interim digital collections librarian
…for the past five years or so.

Interim math

Shoutout to everyone who’s holding an interim appointment or who has absorbed a vacancy in your area. I know many of y’all have been doing this math too. The past year in particular brought so much hardship across all vectors of our lives, and at work that likely included layoffs, retirements, health-related departures, and other stark changes.

I’m in a relatively good position – I get to say how much of this work has to get done. Still, it turns out half-assing a job for a quarter of my time means projects move really slowly or not at all. [2023 editor’s note: “half-assing” was sarcastically used here to mean, “Learning how to do a job I had not done before.” A reminder that we need to be kind to ourselves and others when we take on new roles!]

Where we’re headed

I’m not sharing this with you to complain. It’s not an indictment of my employer. I share it because I think this is where we’re headed.

The early 2000s were a boom time for mass digitization and library investment in digital collections. It was a time of huge growth and excitement in digital libraries.

But, y’all, library budgets are not getting bigger. It’s not that we’re temporarily in tough times. This is how things are and will be. It sure seems to me that digital collections work, and other types of important but invisibilized work in the library, will continue to be deprioritized when budget conversations inevitably get tough. [2023 editor’s note: All this in a broader U.S. political and fiscal climate increasingly hostile to higher ed, libraries, and cultural heritage institutions.]

I won’t tell you not to hope, and fight, for the best.

I will tell you to plan for the worst. Or rather, to plan for the most. ‘Cause this is where most of us are heading. And it’s not necessarily the worst. It’s just different.

The last mile problem

There are a lot of ripple effects of disinvestment that I could talk about, but I only have a few minutes, so I’ll talk about the ones that haunt me most. 🙂

At Code4Lib 2014 Sumana Harihareswara gave a keynote that I still think about.

She talked about the last mile problem: the “largest hurdle we face in making things usable.” She gave many good examples and even wrote it up into a C4L journal article.

The bottom line is that many people don’t use services, even ones that are “best” for them, because they’re simply not usable.

The most beautiful bus stop

Here is a picture of the most beautiful bus stop in Richmond, VA. It’s my bus stop.

[2023 editor’s note: original slide text noted that there is no sidewalk, no bench, no shelter, and the stop is only serviced (unreliably) once per hour. This is still true.]

While this bus stop has the loveliest views, it has zero amenities. It’s inaccessible for many of my neighbors. And it only works well for me because I have a smartphone to check in on bus status, I have flexibility on what time I can arrive at my job, and I can walk quickly down a road with no sidewalk, dodging traffic, to catch a ride. If any of those things were to become untrue, or when the weather goes south, I can’t use the service easily.

This example is the very literal definition of the last mile problem.

The most beautiful workflows

One of the ways the last mile problem has manifested in my work-life has been that, even after a year and a half of using Islandora for our digital collections, we still haven’t figured out a workflow to batch-upload collections. We have added only one item to our digital collections since fall 2019.

First of all, as I said a few slides back, this is a result of disinvestment in libraries as a whole. Like many departments in our library, we’ve had a vacant position for years.

This is also a documentation problem. To get our process sorted out we’ve been hanging on every word of this 7-year-old blog post that’s only accessible through the Wayback Machine.

This is also, fundamentally, a last-mile problem. This upload process was designed assuming every institution had people with scripting expertise and, more importantly, time to design, code, and troubleshoot each bulk upload.

It feels personal. It’s not.

I am actually ashamed to admit this. I feel this failure in my body. I know that if I carved out two solid days I could probably get something working, right? It seems so fundamental! It should be simple. If I just tried harder. If I just had more time.

But this isn’t about me. This isn’t really about Islandora either. (BIG love and gratitude to the community of maintainers for Islandora. I know a lot of this is different in version 8. Again, this isn’t about Islandora.)

This is about beautiful bus stops that only a few people in good circumstances can use. We can and must design more usable things for each other.

Planning for the most

• Design for the margins
• Design for use
• Assume nothing
• Collaborate & de-silo
• Define innovation as a social process rather than a technical one

So I ask you to think of this. How can we adjust the angle of our vision? To set our sights on each other instead of the distant horizon of another cutting-edge revolutionary technology that’ll solve all our problems?

What if instead of thinking of this as “planning for the worst” we see it instead as “planning for the most”? Because most of us are pressed for time, for money, for the brain cells to rub together to create new workflows.

By designing for needs of institutions that have fewer resources, we can design for everybody. Because the center is NOT holding. The dividing line between have- and have-not institutions is only getting stronger, with fewer in between.

Cultural heritage organizations must continue to become interdependent with each other as time goes along. Consortial, collectively-held platforms and communities are the way we need to go. Code4Lib itself is a model of how this can work. We can make this work!

So consider this an invitation.

Let’s keep building the future we need, together.

Postscript

This talk was inspired by all of my amazing colleagues doing library tech and digital collections work, and by the book Design Justice by Sasha Costanza-Chock. Thank you to Drew Heles at LYRASIS who reached out last year about this presentation and inspired me to post it.

When I gave this talk in March 2021, I got some feedback that it was too gloomy. After 13 years in the field, and well over a year after giving this talk, I stick by it. My takeaway is actually not gloomy at all; it’s hopeful. I believe we can have proactive new visions for the future instead of waiting for things to improve. No way out but through, no way through but together.

In the time since this talk I have left libraries and moved to a new city. My (former) institution is currently hiring a digital collections librarian.

Thanks again for reading.

I’ve pulled out some of the topics we discussed and heavily edited/rearranged them for clarity.

Names in systems

Legal name vs. name of use

Let’s think about Facebook’s former Real name policy. Early on Mark Zuckerberg even said that having two names showed a lack of integrity.

The underlying assumption was that there’s one name that everybody always uses, and only people with malicious intend would do anything different. The notion that people are using different identities to “trick” others is also a common, harmful trope used to demonize and discredit trans people.

We now widely acknowledge that people are called different names in different circumstances either because of familial or professional relationships, different eras of their lives, different contexts, or because of a change in their gender identity.

People’s legal names may stay the same, but their names of use vary. That was the thing that got me thinking about trans-affirming systems design.

What would a world look like where trans folks actually see themselves in systems rather than simply accommodated? What if if they truly were affirmed and celebrated?

One way to do that is to allow people to say what their names are. There are very few contexts when we actually need folks’ full legal first names.

Not “edge cases”

Allowing for name flexibility is an example of a technology that helps a lot of different people. For example, of the 140 people on staff at our library, about a third of us are using names that are different from our full legal first name. People are going by middle names or by more familiar versions of first names, like Jimmy instead of James; or are using totally different names. While some people would see an errant name field as a minor annoyance, for other folks it’s a safety issue. It’s one change that’s a big quality of life increase for a lot of folks.

Binaries

Then there’s the gender binary. Computers run on binaries. As technologists we love the idea of ones and zeros, simplifying things when possible: off/on, yes/no; and frequently we do that with gender too. You’ve got a form asking for gender (typically unnecessarily) and there’s only two options.

Gendered stereotypes serve no one

We know full well that when we provide gender data it is often used to sell us things based gender stereotypes. When systems are actively reinforcing the gender binary, the result is reductive and uninspiring, and something that doesn’t reflect the lived gender experience of most people, whether they are trans or not.

Trans/cis binary

Another gender-related binary: either you’re trans or you’re cis. That’s a false binary. People’s gender identities change throughout their lives. There’s valid expressions of gender identity that are neither/nor, that are both/and, so to create that wall between trans and cis is really harmful for all, and cashes out as violence against people who don’t conform.

So many trans people I know don’t think they are “trans enough.” And so many cis people spend so much time trying to prove that they are manly or womanly enough. It’s exhausting.

Everybody has a gender

It’s important for folks who identify as cisgender to to think about and question their genders. You have gender(s)!

Ask yourself, How does my gender impact how I move through the world? How does it impact how I interact with people, and how I present myself, how I dress? It’s not just trans people that should be thinking about this. Just reflect on what your gender is, and how you do it. There’s so much richness there, even within within the cisgender and transgender buckets, there’s just so much.

Binaries create inequalities

Binaries in themselves can be violent. As humans, we categorize things as a survival mechanism so that we don’t have to spend all our energy processing every single sensory input.

At the same time, when we have categories that pit things against each other with a clear delineating line between, those differentiations create inequality.

One harmful binary at the root of American culture: either you’re white or you’re not, and you’re less than. The foundation of the U.S. is the exploitation and oppression of nonwhite people, Black and brown people. In technology, a binary might be “technical” and “non-technical” people. Those types of less-than/greater-than binaries occur across identities and sectors including gender.

Once you start to perceive all the binaries you can’t unsee them. Understanding how detrimental they are helps us understand how the systems we build can reject them and instead reflect the rich bouquet of lived human experience.

Making trans-affirming systems

Audit how how names are handled. Do you require a legal name for anything? If not, let people choose their name, let people update it. Does that name cascade to their username? Are they able to change a username? If I signed up 10 years ago and now I need to change my username, I want to bring over my entire history, am I able to do that?

Follow that up with a gender audit. Are you asking for gender anywhere? Why do you actually need it? Are you asking for people to indicate gender or a title? Add the gender-inclusive Mx. to the honorifics field and if possible make it optional because some folks are just not into it.

Images. If you’re using stock photography or other images on your site, do they represent diversity of lived experiences? Do you have folks who are not white, who are not young, who are disabled, who maybe aren’t conventionally gender presenting? Folks dressed in different types of clothing or with different gender presentation? There’s a few different open photo libraries on the web — the broadly gender spectrum collection comes to mind.

Content. Think about the the content of the web and how users are communicated with in the language that we use. Singular “they” instead of “he or she.”

More on my A List Apart article, Trans-inclusive design.

Closing

I recently read Design Justice and can’t recommend it highly enough. Constant learning is our life’s work. We can’t stay stagnant. We have to keep pushing ourselves, talking to people, and making sure that what we’re building is something that’s going to serve everybody.

I have read A List Apart for years and have always seen it as The Site for folks who make websites, so it is an honor to be published there.