Ky Decker

Do I belong in tech anymore?

Fri, 24 Apr 2026 18:11:49 GMT

Two weeks ago, I quit my job.

It wasn’t a bad job, not by most metrics. It ticked the boxes a job is supposed to tick: good pay. Health insurance. Remote work. Time off. Nice coworkers.

I worked as our org’s only design engineer and maintainer of our design system. My job was to build components, to polish the final product that went out into the world, and to bridge gaps between design and engineering. During my time, I doubled surface coverage of our components, chipped away at bugs, and fixed accessibility issues. I published documentation. I administered twice-yearly surveys which indicated high satisfaction from the team—up significantly compared to when I began. I was doing good work.

And yet, work was rendering me increasingly miserable. I questioned myself. Why am I here? Does any of this work actually matter? And if I stop caring about the quality of my work… will anyone notice? (An uncomfortable thought.)

I knew I was tired, but I wasn’t sure if I wanted to quit. I took a week off to consider it, and told myself: if you still want to leave at the end of this week, hand in your resignation.

The following Monday, I handed in my resignation. I felt immediate relief. I had nothing else lined up, but I knew I needed to go. I’m unsure when (or if) I’ll return to full-time tech work.

What happened?

Not long after quitting, my phone dropped and shattered. Photo by the author.

The psychic toll of AI

Consider the following scenarios:

You join a meeting with a coworker. Your coworker has enabled an AI tool to automatically take notes and summarize the meeting. They do not ask for consent to turn it on. The tool mischaracterizes what you discuss.
A team lead adds an AI chatbot to a Slack channel. Anyone can tag the bot to answer questions about the company’s products. Coworkers tag the chatbot many times a day. You never see someone check that the bot’s responses are correct.
An engineer adds 12,000 lines of code affecting your app’s authentication. They ask that it be reviewed and merged same-day. Another engineer enlists a “swarm” of AI agents to review the code. The code merges with no one having read the full set of changes.
A designer is tasked with exploring a new feature. They prompt an AI tool for an interactive prototype. Design crit is spent analyzing visual details in the generated prototype, with minimal discussion of core ideas, goals, or tradeoffs.
One of your pull requests has been open for a few days. You ask other engineers to leave a code review. Minutes later, an engineer pastes a review that was generated by an AI tool. There are no additional thoughts of their own.
You point an engineer to the relevant section of a library’s docs in order to request a feature. They tell you that the feature request is not possible, and send a screenshot of their chat with an AI tool as proof.
Documents and code are being generated faster than team members can review. You get the feeling that most people have stopped reading altogether.
Organization leadership has mandated that each person adopt new AI tools to “uplevel” themselves and their team.

I encountered each of these scenarios over the past few years, and each one left me wondering: do I raise an issue about AI here? Do I ask my coworker to disable their note-taking tool, or do I allow them to record me? (Where does the data go? Who is reading it? Do we retain knowledge in the same way without manual note-taking?) Do I voice concerns over unread code entering the codebase, and the consequences of that pattern for institutional knowledge-building? Do I ask others on the design team to delay prototyping until later in the design process? Is it already too late to ask? Has the team already shipped the code, already designed the feature, already moved onto the next task? If someone requests my review on a pull request that was clearly vibe coded, do I review the code and write comments as usual, or send it back to them for self-review? Would initiating these discussions result in interpersonal stress? Should I just let things slide? Would I become known as a “difficult” coworker for pushing back on AI use? Does any of it really matter? Does anyone really care?

All of these questions consumed energy. Whether I decided to confront them or not was moot: they left me tired and alienated either way. AI had hooked its tendrils into every corner of my work life. Even if I, personally, abstained from most AI usage, I was steeped in an environment which made it impossible to avoid. Pushing back felt futile.

I prefer to avoid AI usage for ethical, practical, and financial reasons.

Ethically: Generative AI tools, powered by data centers which consume vast amounts of water and pollute our environment, are built on the collective theft of the works of millions of artists, developers, authors, and other creatives, supercharge the spread of disinformation and fascism, have repeatedly provoked psychosis and suicide, and concentrate wealth in fewer hands while providing cover for widespread layoffs.
Practically: I have found that AI tools overcomplicate implementations and that cleaner, simpler solutions can often be written by hand. AI doesn’t “know” anything, and is making life worse for open source maintainers. Overreliance on AI risks deskilling.
Financially: I dislike sending money to large corporations when alternatives include learning the skill for free and contributing to open source projects. Tokens are currently heavily subsidized and likely to become more expensive, so I would prefer not to make a habit of using them.

I use AI tools sparingly for assistance while refactoring code in languages I understand. I occasionally use it to help compose command line arguments for tools like ffmpeg. I never use AI to generate images, video, or prose.

The explosion of AI has played a significant role in my own burnout. Worse, it feels inescapable. Few tech organizations are taking a principled stance against AI use.

But AI use is only one part of broader social trends within tech that leave me questioning whether I should remain here.

The loss of an ideal

When I started full-time design and dev work in the 2010s, tech was generally understood to be a progressive place. This was peak “fun tech job” era, with magazines publishing glossy covers about life at Google. Apple had a gay CEO!

The web was still in flux; as a designer, the prospect of shaping sites into more usable forms excited me. Usability and user-centered design were hot topics. Budding federal organizations like 18F and the United States Digital Service were embarking on meaningful technology-enabled civic work.

After Trump’s first election, people recoiled with shock and disbelief. How could this happen? Many organizations distanced themselves from the administration and reiterated their commitment to equality. Then, the COVID-19 pandemic hit, alongside a surge of protests for racial justice. There was a glimpse of unity. Biden was elected and swiftly proclaimed a return to “normal”.

“Normal” landed us where we are now: the second Trump administration, more flagrantly corrupt and cruel than the first. Protests surge (larger than ever!) amidst a quieter type of elite resignation. The words “equity” and “inclusion” are no more.

Tech organizations have now given up on pushing back against an unethical and violent administration, deciding that it is in their best business interest to flatter the president’s ego with gold trophies and pandering praise. Elon Musk and the “Department of Government Efficiency” took a sledgehammer to 18F and replaced it with National Design Studio, a propaganda shop whose main talent is building expensive and inaccessible landing pages.

Leaders at Google have abandoned former climate pledges as they work to build new data centers powered by natural gas turbines which emit more carbon than the entire city of San Francisco. Other tech CEOs smile for photos alongside war criminals.

Guillermo Rauch, CEO of Vercel, poses with Benjamin Netanyahu, prime minister of Israel. The International Criminal Court has issued an arrest warrant for Netanyahu for “war crimes of starvation as a method of warfare and of intentionally directing an attack against the civilian population.” Original tweet.

I keep asking myself:

What happened to the principles that were professed a decade ago? To address climate change? To reduce racial, gender, and economic inequality? To “don’t be evil”?

Were these principles abandoned, or were they merely born of convenience?

Has tech always been like this? Was I just blind to it before?

When I say that I am burnt out I do not mean simply that I am tired. I’m referring to the “emotional experience of political defeat”:

Burnout in Freudenberger’s articles from this period is not just defined in terms of physical tiredness as a result of doing too many things; rather, it emerges from emotional investment in a cause and from the disappointments that arise when flaws in a political project become apparent. Freudenberger’s concept not only describes physical exhaustion but also acknowledges the need to deal with anger caused by grief brought about by the “loss of an ideal.” Burnout in the context of social justice projects thus often involves a process of mourning, according to Freudenberger. Returning to his earlier writings on burnout makes it clear that when understood as a malaise arising from politically committed activities, burnout cannot be equated with tiredness or stress.
Hannah Proctor, Burnout, p. 92

I love designing and building things for the web, but I’m mourning an industry that does not share the ideals I once thought it did.

I understand why people use AI. Life can be difficult and confusing. Prompting the machine is so alluring—it answers with such certainty! How could it be wrong? (And even if it is a little wrong, well… hasn’t it saved time? Does it need to be perfect?) The temptation is real.

I don’t blame people for opting to use tools that promise quick, convenient solutions to problems. We all operate under capitalism. Many of us have bullshit jobs where the goal is not, in fact, to make something good, or even to learn, but to simply make money to pay rent and medical expenses. To hopefully find a little joy on the side. The whole system is broken; AI alone didn’t break it, but it is widening the cracks.

I guess what I’m trying to say is I wish none of us had to live like this. I would like to imagine a future that does not look like this.

Ironically, what I’ve gained from AI is a deeper appreciation for human communication, in all its messy imperfection. The point of a code review is not simply for good code to make it into a codebase, but to build institutional knowledge as people debate and iterate and compromise, slow as it may be. Friction is good.

Human communication is difficult. Original post.

Where do I go from here?

No matter how rapidly technology changes, I am coalescing around some core beliefs:

Things that are worth doing are worth doing well.
Things that are done well require time and effort.
You make meaning through the doing.
Ideas are common; effort is not.
There are no shortcuts.

I am, as it stands, without a job. Recovering from burnout will take time. Thankfully, I have savings that afford me the privilege to take that time. I’m distancing myself from social media and news, at least for a little while. At some point, I will need to decide if I want to remain in this industry, and if so, where to go next.

In the meantime, I’m going to the gym. (Crossfit, weirdly.) I’m learning more about how synthesizers work and I’m generating different sounds. I’m looking at birds. I’m looking at my cat. I’m continuing to build tools to help trans people with legal name changes. I’m spending time with friends.

Eventually I will find new work. Who knows where.

Mapping where districts start and end

Tue, 13 Feb 2024 05:53:27 GMT

Background

BetaNYC is a non-profit civic tech organization which builds tools and hosts public events to increase access to civic data and demystify government processes. I joined BetaNYC for 8 weeks during Summer 2022 as a Civic Innovation Fellow.

BetaNYC operates out of the Manhattan Municipal Building at 1 Centre Street. Technologists work alongside urban planners and other city professionals. Photo by Mattia Panciroli via Flickr, 2012.

The challenge

Every day, you cross dozens of invisible borders: city council districts, school districts, police precincts, fire battalions, senate districts, zip codes, and more. These borders, although invisible, affect your life in important ways. Who collects your trash? Who represents you? Who arrives to care for you if you’re injured? To answer these questions, it helps to know exactly where boundaries begin and end—and how they overlap.

BetaNYC maintains an open source web app called NYC Boundaries Map. First launched in 2018, the Boundaries Map allows anyone to view and explore overlapping jurisdictional boundaries within the city. The map is commonly used by city council staff and community boards in order to direct feedback from constituents to the correct department.

The Boundaries Map helps answer questions like, “which school districts does this community board serve?”, “which sanitation district do I contact about the trash at 2nd Avenue and East 14th Street?”, and “what police precinct am I in right now?”

The map was not pleasant to use.

The original Boundaries Map. 13 separate boundaries render with 13 separate border colors and labels. A rainbow spaghetti of geographic data.

Working together with Zhi, we noted several usability issues:

Toggling on more than two districts quickly made the map illegible.
Boundaries on the map itself were not interactive.
The map’s implementation in Leaflet resulted in rasterized borders and labels, which looked blurry on HiDPI screens.
Viewing overlaps required a complex sequence of “querying” boundaries by selecting an administrative region and then selecting which district to intersect with, and the query itself was slow to execute.
The map required frequent manual zooming and panning, since it did not adapt automatically to queries.
Searching for an address required pre-selecting a borough.
Viewing additional metadata about a district required leaving the app and searching Google.
The app was desktop-only.
Visual design polish was generally lacking.

Additionally, there was no frontend framework in use (!) and I felt there was an opportunity to modernize and speed up development by adding one.

Research and build

With a solid list of usability tickets to address, I got to work sketching ideas for how we might fit things together.

Sketching ideas. I explored how we might combine location search, district browsing, and overlap browsing within a single interface.

Without delay, we dove into code. After quick exploration with various frontend libraries, I installed Svelte and Tailwind, which would allow us to build more advanced functionality more easily. We moved from Leaflet to Mapbox since it offered us exciting opportunities to interact with the map directly.

We scheduled video calls with some frequent users of the Boundaries Map in order to better understand how they were using the tool and what could be improved. We shared our work-in-progress prototype for feedback. The participants were excited to be a part of the process and helped validate assumptions we had made.

Outcomes

After a few short weeks, we announced the updated app.

The new Boundaries Map. The updated app features overlaps on hover, direct interaction with the map, a unified navigation bar, and clearer information hierarchy.

The new map automatically zooms and pans to the selected boundary. It displays boundary overlaps on hover, allows single-click filtering by clicking any boundary, and supports mobile viewing. It links to the relevant webpage for a district when available, so users can find things like phone numbers for city council members. And it now allows users to share URLs for filtered views, and export overlap data to JSON for analysis in other tools.

Read the announcement or explore boundaries.

Reflections

I had never worked with mapping technology before, so it was fun to learn about how to wield geospatial data using Mapbox. (Huge thanks to Zhi sharing his knowledge of GeoJSON and Shapefiles!) Svelte and Tailwind were also new frameworks for me, and this project helped me get more familiar with their capabilities.

With extra time, I’d explore how to improve mobile navigation, since touchscreens can’t support the same hover interactions as desktop. I’d also explore whether it’s worth introducing color to the base map to more clearly communicate the locations of parks, water, and other regions. (Boundaries Map is open source, so maybe I’ll get to these one day! Or maybe you, my reader, can make contributions of your own.)

BetaNYC introduced me to the city’s vast library of open data, and I’ve continued to think about other possibilities for design and technology to surface public data for good.

Building Commonplace

Sat, 13 Jan 2024 05:13:17 GMT

Background

Cityblock is a health company which got its start within Google’s Sidewalk Labs. Teams of clinicians and other health professionals provide in-community care to people on Medicare and Medicaid to improve health for an often-neglected population.

Andre, a Cityblock member, tells his story. Via Cityblock on Vimeo, 2023.

To support care teams and the members they serve, Cityblock builds and maintains a tool called Commons. I joined Cityblock in February 2019 as a Product Designer and recognized a need for a more systematic approach to design. Over the following two years, I built and expanded a design system in Figma and React. I named it Commonplace.

The challenge

Cityblock was less than two years old, but Commons already offered a sprawling set of features, including: tracking member status, charting member acuity, coordinating member outreach, storing and editing core demographics, viewing health history, scheduling events, managing tasks for individuals and teams, creating and administering health assessments with automated scoring, texting members… all that, and more planned.

All of these features converged in an interface that looked like this:

The appearance of Commons when I joined Cityblock. Here, in the right-hand drawer, a user is composing a progress note about the current member. The varying colors, typography, and hierarchy make the interface difficult to understand. All member data displayed in this case study is notional.

Although there were some underlying commonalities and shared language throughout the product, the design was not scaling to meet the needs of its users or developers.

A lack of systemization was leading to longer development times, more time spent on undifferentiated work, more bugs in the product, and a user experience that was inconsistent and confusing. These problems would only worsen as Cityblock grew.

Mapping the territory

Together with Cityblock’s Director of Design, Neves, we catalogued the available views. I conducted a product audit, clicking through and taking screenshots of every view, dialog, drawer, and dropdown within Commons. The images were then organized into folders for future reference.

A product audit. We captured screenshots from every corner of Commons and organized them in folders corresponding to the app’s information architecture.

The product audit helped us understand the current state of Commons, and it ushered in an essential archival practice for the future. Throughout my tenure at Cityblock, I would continue to catalogue product interfaces at least once a year.

Following the product audit, we created an interface inventory, collecting all variations and permutations of each component and displaying a collage of those permutations on a large poster board.

The interface inventory. The product audit screenshots were used to create a collage of each component’s variations. How many header styles can you count?

This inventory allowed us to more easily spot inconsistencies and discuss how best to resolve them across the system.

Laying foundations

Once the interface inventory was complete, we focused on design foundations—typography, color, and spacing. All components rest on top of these three primitives, and we wanted to get the essentials right.

Typography

Care teams at Cityblock are given small Chromebooks to take with them around the city. They use their Chromebooks to access Commons in many locations: the office, at community hubs, in members’ homes, and in their car or on the subway.

As we laid out a typographic scale and compared different typefaces, we made sure to test text on the Chromebook’s low-DPI display in a variety of real-world, less-than-ideal lighting conditions, in order to ensure that Commons was legible in every setting.

Low-contrast typography within Commons. Many views contained small, light text which was difficult to read under ideal conditions, and practically impossible in others. All data is notional.

With Cityblock’s brand designer, Minji, we tested various typefaces for the product before landing on Graphik for its legibility and understated friendliness. All text colors within the new design system would adhere to WCAG AA or AAA contrast ratios.

The typographic scale. The base unit is set to 16 pixels and most header sizes scale up from there using rem. After experimentation, we decided to break this scale for the body size (15 pixels) and small text (13 pixels) in order to maintain medium-high data density.

Color

When considering colors in Commons, we prioritized pure function, accessibility and contrast, relation to the brand, and coherence as a whole.

I also examined the use of color in film to portray two separate settings—the hospital and the home.

Colors of the hospital, and colors of home. What feelings do these scenes evoke?

The hospital blue-greens are distinctly clinical, down to the robes worn by patients and doctors, and feel somber and sterile. “Home” tones, in contrast, emit a warm, welcoming glow. I wrote at the time, “Cityblock should feel less like the hospital, and more like home.”

This led to guiding principles:

Guiding Principles for Color in Commons

Color gently. Opt for soft, subdued tones. Avoid highly-saturated, electric colors.

Use high contrast elements sparingly. What is the one action on any given view that deserves attention?

Skew warm. Do not tint neutrals blue.

And the resulting palette, defined as matching Figma styles and CSS variables:

The color palette. Colors are arranged along a spectrum from 100 (light) to 900 (dark). Some colors are aliased with a semantic name, so developers don’t need to remember that icons are --color-neutral-600. They can just use --color-icon.

Spacing

We agreed to use an 8 pixel grid for all components, and we agreed on specific fixed widths for sidebars while leaving the rest of the app responsive to scale with the browser.

Building components

Once foundations were in place, primitives were set up both in Figma and as CSS Variables in the codebase, and we were able to quickly and easily replace all existing hex codes with new color variables, replace existing padding, margin, widths, and heights with the new spacing scale, and swap out the typography.

Then began the long and steady process of building and replacing components one-by-one. Create a new Button. Test it. Swap out all existing buttons and delete all existing styles. Merge in the changes. Pick a new component, rinse and repeat.

Commonplace components. Each component in the codebase included unit tests, a Storybook story, and JSDoc comments for each prop in order to provide in-context documentation within VS Code.

Component work took place over the course of many months, alongside other feature work I was involved in. It took place largely independently, although I continued to collaborate with Neves for visual and interaction design feedback, researchers like Amber and Taylor for user insights, and engineers like Brennan, Aster, and Craig for code review.

We chose an incremental approach—rather than building and shipping an entirely new design system all at once—in order to maintain forward momentum, bug test along the way, and enable new features to be built with new components as quickly as possible.

Outcomes

By January 2020, most views within Commons used Commonplace components. Responses from engineers and care team members were overwhelmingly positive. Bug reports decreased, new features became easier to build, and engineers got to spend more time on differentiated work and less time fiddling with CSS.

Despite the addition of new components, several thousand lines of code had been deleted since the start of the project due to the reusability and modular nature of the design system—a meaningful reduction in complexity and technical debt.

Member action plan, before (early 2019) and after (early 2020). More information is available at a glance, without drilling down into cards and accordions.

Member table, before (early 2019) and after (early 2020). We aimed to main medium-high data density, helpful for our care staff, while making the UI feel more approachable and calm.

Around this time, I gave a company-wide talk about design systems, a concept which was unfamiliar to many people outside of the tech team. There was palpable excitement over seeing the drastic comparisons of before and after screens.

I would continue to contribute design and code toward Commonplace until my departure in July 2021.

Reflections

Care teams at Cityblock do difficult, meaningful work, and it’s essential that the technology we build for them respects their time and energy. I’m proud of the way I was able to help transform Cityblock’s approach to design and engineering, and (hopefully) reduce stress for our hard-working care teams.

Health tech is a complex space, and I still see dozens of ways that Commons could be streamlined. A design system is only as strong as the features it’s used to build, but where a design system ends and product features begin isn’t always clear. There is always more to do.

As I write this, in February 2024, I’ve just returned to Cityblock to help level up design systems again. After 3 years’ absence, the system foundations I put in place have held up well. Some areas have flourished, others have remained the same, and a few weeds have sprouted, but it’s a wonderful feeling to see the work you put so much effort into continue to endure.

Building data-driven design systems

Tue, 08 Sep 2026 12:00:00 GMT

Background

In June 2024, I joined Scribe as its first (and only) Design Engineer. Scribe’s VP of Design, Tony Gines, had hired me to take the existing design system and improve its consistency, polish, and accessibility.

Scribe is a tool—commonly used through a browser extension—which allows users to record clicks and keystrokes to automatically generate step-by-step guides. It’s commonly used for creating things like product tutorials and standard operating procedures (SOPs), and is used by over 600,000 businesses, including 94% of the Fortune 500.

The problem

Scribe’s design system, called Stylus, was beginning to show cracks. The system was built on a solid foundation using Radix UI and Tailwind. But as the company expanded, without a dedicated maintainer, issues had emerged:

Fragmented documentation made it unclear what capabilities the system had and how it was intended to be used.
Low adoption meant that teams often defaulted to building new, one-off components, rather than contributing back to the system.
Inconsistent component APIs and a lack of strategy around tokens caused inconsistencies that affected the user experience and damaged trust.
Accessibility issues—like low-contrast text, missing focus rings, and unclickable checkbox labels—prevented certain users from accessing Scribe altogether.

I had built previous design systems and I knew how to address these problems. But I wanted to go a step further and quantify how much the design system improved over time. I wanted to foster a practice of regularly assessing the state of the design system, soliciting feedback and critique from every team member.

Taking a pulse: design system surveys

The month I joined, I wrote and sent a survey to every engineer, designer, and product manager. I would administer and synthesize this same survey every six months during my tenure.

In the survey, I asked participants to rate six statements (like “Stylus documentation helps answer most questions that arise.”) on a 5-point Likert scale, plus rate overall quality on a scale of ten. Low ratings prompted open-ended feedback that fed directly into design system priorities.

Survey results. One part of a much larger Notion doc which synthesized all data alongside open-ended responses. Here, team members request various ways to make the system more predictable.

Results, 18 months later

Here are the trends that emerged from four surveys, collected over nearly two years, along with some of the actions that drove the changes and free responses from survey participants.

Meeting feature needs

I can use existing Stylus components for most new features.

Up 10% over 18 months

The share of people using existing components for most new features increased by 10% thanks to improved teamwide communication about design system updates, better documentation, and preemptive updates to support new product features (for example, I led the addition of dark mode support across our design system to anticipate the launch of a new product feature that prominently used dark colors).

“This is probably one of the best looking component libraries i’ve ever worked with”

Predictability

Stylus components generally work the way I expect them to.

Up 12% over 18 months

12% more people reported that components work the way they expect—often thanks to changes stemming from prior survey feedback! Consolidating Tailwind configs into a single source of truth helped considerably, along with favoring composition instead of configuration for complex components.

“Stylus is great to use, enjoy that ai coding tools have no problem using our design system, appreciate all the great work!”

Naming

Stylus component, token, and property names make sense to me.

Up 11% over 18 months

Naming clarity increased by 11% as I worked to extract and reuse shared prop types, extend (rather than redeclare) native HTML props, and establish global naming patterns like prefixing boolean props with is, has, or should.

“Thanks for constant improvements to an already excellently defined design system”

Saving time

Stylus saves me time on work that would otherwise take longer.

Steady over 18 months

Time savings held roughly steady across the four surveys. While I made progress in many areas, some metrics were good from the start.

“I cannot tell you how much time Stylus saves me!! And any time I’ve had an issue and brought it up Ky is super speedy at proposing and making a fix, 10/10.”

Documentation

Stylus documentation helps answer most questions that arise.

Up 40% over 18 months

I led writing and publishing public, reader-friendly docs using Starlight, which significantly increased team members’ ability to answer questions about the design system. Since docs existed as Markdown in the codebase, this also improved agentic access for developers using LLMs. I minimized drift by automatically populating API reference tables based on JSDoc comments and TypeScript types and cross-linking resources from Figma to code to the docs and back.

“The new docs are gamechanger! I reference them every day.”

Collaboration

Stylus helps design and engineering roles collaborate more effectively.

Up 20% over 18 months

Sentiments around collaboration improved by 20% owing to reduced discrepencies between Figma and code, and a culture of encouraging new contributions to the design system from folks across all teams.

“Adoption and product / design alignment are quite strong here at scribe and its made using the library super easy. Keep it up!”

“This is one of the better component libraries and collaborative experience between design engineers and product engineers Ive seen making development much quicker! Its a great dev experience being able to consume from our stylus library but also having the ability to dig into components to make suggestions / changes with quick review turn around.”

“Reviews are always constructive and quickly guide or enable an engineer to help improve the library.”

Overall

Overall, how would you rate the quality of Stylus?

Up 20% over 18 months

Survey feedback is important, but it skews toward developer experience over end user experience. To counter this, I made sure to supplement internal surveys with user-centeric metrics, like performance testing with Lighthouse, accessibility testing with Playwright and axe-core, and visual regression testing with Chromatic.

I supplemented the sentiment-driven survey data with quantitative data from Omlet, a tool which runs static analysis on a codebase to determine how many times a component is used, how many times a prop is used, and how coverage changes over time. Thanks to insights from Omlet and a lot of deleted code, component coverage increased from 37% to 52% over 6 months.

“Keep crushing it! So appreciate your work”

“Y’all deserve ALL the kudos”

Reflections

Building a design system is a perpetual fight against entropy—the tendency of any sufficiently complex system to devolve into chaos. Taking a regular pulse helps the team stay focused on building what’s important.

I’m proud of how I was able to help shape Scribe’s design system and team culture. It wouldn’t have been possible without the contributions and feedback of all my teammates along the way!

A design system is never done, but we can always push ourselves a little further on the road to “better”. Here’s to measuring—and acting on—what matters.

Design outside the computer

Mon, 20 May 2024 17:30:34 GMT

This weekend, I added a new feature to my site. It’s an old-school kind of webpage—something I’ve always wanted to create, but never really had the tools for until now.

It’s a guestbook.

In the guestbook, anyone can write and publish a short message accompanying a name and optional URL. Once submitted, the message gets published to the top of the page for everyone to see. That’s it—no likes, no shares, no threads. Nothing fancy.

The guestbook. People have already written kind things and drawn snails.

Astro DB, recently released, made it a breeze to spin up a database and implement publishing, even for a backend novice like me. But this post isn’t about how to implement a guestbook. (UX developer Ryan Trimble already wrote a great tutorial for that!) It’s about how invigorating it can be to design digital UI when you step away from your computer.

I didn’t want to build just any plain stream of messages and text—I wanted to create something that felt warm, personable, and tactile—like signing a real book. To accomplish that, I first did something important: I shut my laptop.

The death of texture

The world around us is full of texture. From the bark of an elm tree to the weave of a linen blanket… even the body of a MacBook isn’t completely smooth. Most digital spaces, in contrast, are textureless. Flat expanses of nothingness, stretching into a grainless void.

Our interfaces used to be more textured. During the heydey of skeuomorphism in the late 2000s, designers prided themselves on being able to craft realistic-looking wood grain, leather, glass, and other effects.

In 2013, Apple released iOS 7, featuring a redesigned user interface which, under Jony Ive, fully embraced flat design, bringing a swift death to the iPhone’s skeuomorphism. The vast majority of digital spaces soon followed suit.

iOS 6 (left) and iOS 7 (right). iOS 7’s flat design effectively killed skeuomorphic design trends across the industry. Images from Ars Technica.

Although the usability of the digital landscape has improved greatly over the past decade, I can’t help but feel like the web lost a little bit of its soul when everything got flattened. So much of the web today feels boring, samey, and soulless.

Real-life objects can live on your website

Let’s push that pendulum back the other direction! A bit, at least. Let’s give the web some soul. Let’s give it some texture.

How do you add texture? You could browse for Photoshop packs and fiddle with layers and blend modes to emulate real life. Or, you could grab some paper, scissors, and markers, and go craft in your living room on a nice Spring day.

The second option is way more fun.

Crafting cards. Stamps from Casey Rubber Stamps in NYC.

I spent an afternoon cutting out same-sized rectangles of card stock and doodling on them with whatever drawing tools I had around. Highlighters, pencil, crayons. Washi tape. Some ORAL stickers I stole from the queer health clinic. Every card is a little bit different.

I scanned in the cards using a flatbed scanner, cleaned up the images in Photoshop, and optimized them for web. Now all these physical objects have a digital home. :)

Tips for bringing physical media into digital UI

Working with physical media is rewarding. Quirks of the medium show up in ways that would require large effort to reproduce digitally—the edges I cut are not quite straight; the lines I drew are not perfectly even. Sometimes the ink smudged. It’s okay! Desirable, even.

But translating media into digital space takes care to show up and perform well. Here are a few tips if you’re thinking of bringing real-life objects into your digital designs.

Know how your layout will flow and reflow

Before starting, ask yourself: will text need to wrap to multiple lines? Will the element grow, or is it a static size? Does the design need to adapt to mobile? The more flexible the size of your elements, the more difficult it may be to craft physical media to support them.

When designing cards for the guestbook, I decided to design around a consistent 4:3 aspect ratio. For this, you can use aspect-ratio in CSS, which has coverage in 94% of browsers used globally.

.notecard {
  aspect-ratio: 4 / 3;
}

Enforcing a static aspect ratio means we need to be thoughtful about how much text a user can enter. How wide is each line of text? How many total characters can the content area support?

We can use the ch unit in CSS to define the maximum width of the text. The ch unit is equal to the width of the character 0 in the selected font, and since we’re using a monospace font where all characters are the same width, we can use ch to display exactly 28 characters per line.

.notecard .content {
  width: 28ch;
}

We want to allow users to draw ASCII art and other fun things, too. To do that, we need to preserve whitespace for entries and prevent long lines of unbroken text from overflowing the container.

.notecard .content {
  width: 28ch;
  /* Preserve whitespace */
  white-space: pre-wrap;
  /* Break long lines of text */
  overflow-wrap: break-word;
}

We can enforce these limits in our HTML for form submission:

<textarea
  name="content"
  placeholder="Leave a message, write a poem, draw some ASCII art..."
  required
  rows="5"
  cols="28"
  maxlength="140"
></textarea>

We can also tell the form to preserve implicit newlines on submission with wrap="hard", which will guarantee that even if we change our CSS in the future or decide to display guestbook entries somewhere else, handcrafted ASCII art will remain intact.

<textarea
  name="content"
  placeholder="Leave a message, write a poem, draw some ASCII art..."
  required
  rows="5"
  cols="28"
  maxlength="140"
  wrap="hard"
></textarea>

There are a few other details to take care of, like showing a warning message when there’s no room left for text, but the above code takes care of the basic setup for a fixed-size, fixed-length textarea.

Use a flatbed scanner

Dedicated scanners are cheap nowadays, and produce better results than photography. There are two types of scanners: CIS scanners have a very shallow focus, while CCD scanners have a wider depth of field. (I used a $60 CIS scanner for this project, but if I needed to buy a new scanner today it would be a CCD!)

I’ve found that 300 DPI is enough resolution for retina displays. Through trial and error, I also learned that putting a contrasting backdrop behind your documents will make it much easier to isolate the subject in tools like Photoshop after scanning.

Use a dark backdrop. A contrasting backdrop makes documents easier to isolate using tools like the magic wand.

Be mindful of color contrast and file size

Image backgrounds make it more difficult to measure accessible color contrast ratios for text on top; don’t make any backgrounds too high-contrast. If you realize a shade you used was too dark, you can adjust contrast settings after scanning your images in. If there are any busy elements in your object, try to position them in a spot where text is unlikely to overlap. For the guestbook, I put the loudest elements in the margins, away from text.

The downside to working with images can be increased bandwidth. Use a command line tool like optipng to losslessly compress files, or a build tool like Astro’s <Image /> to handle it for you. There’s no use in designing beautiful objects if a massive file size will prevent them from ever being seen!

Incorporate some randomness

The real world isn’t often aligned in perfect 90 degree angles; your interface doesn’t have to align to the grid, either. Consider incorporating some variation in how you position elements, for example, by using Astro’s define:vars style directive to pass variables into CSS:

---
// Rotate each notecard randomly between 3 and -3 degrees
const randomRotation = `${Math.random() * 6 - 3}deg`;

// Offset each notecard randomly between 12 and -12 pixels
const randomTranslateX = `${Math.random() * 24 - 12}px`;
---

<div class="notecard">
  <!-- Notecard contents -->
</div>

<style define:vars={{ rotation: randomRotation, translateX: randomTranslateX }}>
  .notecard {
    transform: translateX(var(--translateX)) rotate(var(--rotation));
  }
</style>

Have fun!

Embrace experimentation and the freedom of designing without a screen. There are so many potential areas to bring physical objects into digital experiences. It isn’t always called for or necessary, but for the right moment, a touch of real, physical texture can go a long way toward making an experience that’s a joy to use.

Now go off and draw your own UI. Don’t forget to sign the guestbook before you go.

Shout out to Lean Rada, whose guestbook—discovered through the CSS JOY webring—offered inspiration for the themable index card format. Lean’s even includes customizable fonts, colors, and stickers! Check it out.

Embrace friction

Mon, 08 Dec 2025 17:26:21 GMT

This weekend, I attended a letterpress course at the Center for Book Arts in NYC. I love working with and reading about typography, but until now, most of my interactions with type have been mediated through a digital display. I was thrilled to get physical. To touch the type!

We learned about the Vandercook proof press, an imposing steel machine from the early 20th century. We selected typefaces from the Center’s many cases of lead type. And over the span of two days, each of us set a page of text to print.

Vandercook proof presses. Located at the Center for Book Arts.

Letterpress is slow, methodical work. Instructor Sarah Nicholls says it “reshapes your relation to time.” Every letter, space, and detail is placed individually, entire forms composed by hand. Nicholls uses letterpress as the final step in her editing process—it forces deep consideration of every word’s purpose.

Letterpress workstation. On the left, a case of 18pt Caslon #540 lead type. Above, a reference using the California job case layout. On the right, a metal galley plate and composition stick, where type is being arranged.

Setting each character within the composition stick, you feel the shape of words. Physically, yes, but linguistically, too. There is a poetry to the shapes that form language. I felt this intimately, setting Ursula K. Le Guin’s translation of the twenty-five hundred year-old Tao Te Ching.

As I composed my page, letter by letter, I thought about friction. Friction shapes our relation to a system. It is difficult to set type in letterpress, so I say less, with more intention. It is easy to type on a computer, so I say more. If I wanted to set this blog post in letterpress, it would take me a week or more. Would I use all of these words?

Setting type for print. Blocks are arranged individually on a composition stick, then moved to a galley before being placed and secured on the Vandercook press for printing.

Tools like ChatGPT take friction(-lessness) to a new extreme, where even writing is not required: only a rough impulse about the result you want. What do we lose when we abandon taking time to shape language? What meaning is made from pressing buttons on a text extrusion machine?

New technology often prizes itself on being “frictionless”. But is lack of friction always a worthwhile goal? Thoughtfulness requires time. Learning requires time. Friction, ever obstinate, forces us to slow down. When we slow down, we may discover things that are easy to miss when zooming by at quicker speeds.

In a world that constantly demands we move faster and be more productive, there is joy to be found in doing less, more slowly, with greater intent.

Taoing, from Tao Te Ching by Lao Tzu, translated by Ursula K. Le Guin. Title set in Lydian Condensed Bold, 48pt. Text set in Caslon #540, 18pt.

The penultimate line of “Taoing” ends with an exclamation point. After carefully arranging the preceding sixteen lines, letter by letter, over two days, placing that exclamation point exploded like a firework inside of me.

Bang! I felt it.

I felt it because I was going slow enough to notice.

The Center for Book Arts offers many workshops for letterpress, risograph printing, book binding, and more. I sincerely recommend taking a class if you’re in the NYC area. I will definitely be returning.

Making Genderswap.fm

Sat, 02 Mar 2024 05:40:50 GMT

Background

In 2021, I read the novel Paul Takes the Form of a Mortal Girl by Andrea Lawlor. Early in the book, Paul gushes about his love of gender-swapped covers:

Some covers deliver the age-old simple pleasures of drag—knowledge, the opportunity to investigate the simulacra and make comparisons, that obscure little frisson of dissonance. Take Joan Baez singing “Virgil Kane is my name… like my father before me, I’m a working man” (which, of course, is originally from The Band’s “The Night They Drove Old Dixie Down)” or Cait O’Riordan from the Pogues crooning, “My name is Jock Stewart, I’m a canny gun man” (from the traditional “I’m a Man You Don’t Meet Every Day”). Joan Baez’s contralto can, if you squint your ears, pass as a farm-boy tenor; Cait O’Riordan’s chalky delivery might be that of a rich ponce.

I listened to each cover and original, enamored with how lyrics could completely transform under another artist’s tone, tempo, and gender.

I began compiling Paul’s songs into a playlist, and then I added more of my own. And more. And more. For another two years.

The challenge

As my covers playlist grew, so did the tedium of managing it in Spotify. I kept all covers alphabetized (by hand), and I maintained two separate playlists—one for both covers and originals, and another for covers only.

Difficulties organizing in Spotify. The interface makes it challenging to organize songs within large playlists. (Sorting by title exists, but it’s unreliable here—John Denver’s “Take Me Home, Country Roads” deserves to live beside Judy Collins’s “Leaving on a Jet Plane/Take Me Home Country Roads”.)

After managing this playlist for two years, I decided to build a custom solution to host and catalogue covers. I named it Genderswap.fm.

Laying foundations

This personal project was my first time working directly on the backend. Thankfully, Supabase—an open source alternative to Google’s Firebase—made it easy to get started.

I experimented with alternative data structures and landed on a two table model: one table for songs, and one table for covers, which links two song rows together along with extra metadata about their relation.

Database schema. This is the shape of the data for Genderswap.fm.

I decided to use Svelte and SvelteKit for my application framework. I had previously used Svelte in my build for the NYC Boundaries Map, and the addition of SvelteKit made it easy to manage routing, server-side rendering, and API requests. I set up a Spotify Developer account and used the Spotify Web API TypeScript SDK to make it easy for users to search for and enter songs. I also added Melt UI, a Svelte-based component library, to help build the submission form.

Ideation

For the design, I knew I wanted to allow users to browse by pairs of songs shown together. It wouldn’t be too different from browsing “by album” in any other music tool, but rather than displaying a single album for each result, I’d display original/cover pairs.

From there, users could tap in to view the details of a cover, and listen to the original and the cover side-by-side, with notes about their differences.

Exploratory sketches. Ideating around the display of albums, how to structure the submission form, and how to surface filters. I still hadn’t figured out what I would ask users to tag manually, and what I could tag automatically using Spotify’s API.

Finding a design language

To communicate the way these covers remix sound, reinterpret lyrics, and reconfigure meaning, I established a visual motif to thread its way through the app: two objects, overlapping and askew. Sharing space, but different.

Overlapping visual motif. Intentional overlapping groups the original and cover as a single unit. The cover album is larger and foregrounded for emphasis.

Typography is set in Labil Grotesk, a queer font which topples over itself, unable to rest upright, mirroring the off-kilter elements elsewhere in the app.

Labil Grotesk in use. I love the way the ‘O’ falls over, ready to roll off the screen.

While the topsy-turvy contextual alternates were enabled for page-level headings, I disabled them for smaller text to prioritize legibility.

Little big features

As with all my work, I looked for opportunities to introduce small but meaningful details.

Automated tagging. Covers are automatically tagged with attributes like “sadder” or “more danceable”, and you can search and filter by tag.

Readable URLs and page titles. Share human-readable URLs which accommodate diacritics and non-Latin characters.

“Covered as…” Conditionally see when a cover’s title diverges from the original.

Earlier release prompting. Behind the scenes, the app will search for earlier album releases for your original song. If one is found, it’ll prompt you to update your submission.

Rich social previews. Custom Open Graph images generated using Satori and Sharp display a cover’s title, album art, and tags.

Just the titles. Remaster dates, “(Featured on…)”, “[From the Movie…]”, and other cruft is stripped out, leaving only the artistic title.

Celebrate contribution. Confetti erupts after each new submission. 🎉

Pre-filled name for repeat submissions. Entered names will be pre-filled for future submissions on the same device.

Paste links into search. Title too hard to type? Just copy and paste the Spotify link.

Explore covers, get a random cover, or submit your own.

Outcomes

I didn’t have any massive ambitions for this app—it was mostly a way for me to learn new technology, and see if I could manage my covers library in a way that felt a little more natural. In that sense, it was a success!

After finishing the first version of the app, I emailed it to Andrea Lawlor, sharing how Paul Takes the Form had inspired me. A few days later, I received this reply:

Andrea Lawlor’s reply. You heard it here, folks. The coolest thing ever.

I was overjoyed. Thanks, Andrea. Thanks, Paul.

Genderswap.fm is now showcased on Made with Svelte and the Utopia.fyi Showcase.

Reflections

There are many improvements I’d still love to make to the app. At the top of the list is an in-app audio player. I’d also like better search, and a way to automatically generate and sync the Genderswap.fm database to a Spotify playlist. I track all issues and ideas on GitHub, and contributions are welcome.

I learned a lot building this out. The backend is not as scary as it seems, and I taught myself that it’s possible for me to build a full-stack app from start to finish! There’s still more to learn, and I hope to continue working on this project when I have time.

To build gentler technology, practice trauma-informed design

Thu, 13 May 2021 04:00:00 GMT

When I was sixteen, YouTube outed me. My mom walked into my bedroom one day and hit me with a question that stopped my heart:

“Are you gay?”

She told me that she and my younger brother had used my computer to visit YouTube and saw videos. She wanted to know where the videos came from. She wanted to know if I was gay.

I’d feared this moment for so long, and I wasn’t ready.

A truck with several confederate flags near my childhood home in Horse Shoe, North Carolina.

I grew up in a Southern Appalachian town called Horse Shoe, where I drove past Confederate flags every day on my way to school. I spent most of my early teens trying to “pray the gay away” in earnest. Driven by fear and self-loathing, I repressed any emotion or expression which could’ve brought on the wrath of a high school boy or the scorn of an adult.

As a teenager, the internet was my solace. I didn’t know any queer people in my 600-person school, and I had no adults in my life who were outwardly LGBT+. In the physical world I was closeted and stoic. In the digital world, I found people like me, and it made me feel less alone.

I knew these worlds needed to stay separate. There were real, physical risks if my parents discovered my online activity: they might kick me out, or send me to conversion therapy, or worse. I diligently scrubbed my browsing history, used alternate email addresses, and waited until late at night—when my parents were more likely to be asleep—to watch vlogs and chat.

But it only takes one slip-up. I hadn’t thought about the YouTube recommendations.

A church in Horse Shoe proclaims, “OBEDIENCE IS BETTER”.

I’d planned to come out to my parents eventually. I just didn’t want to do it then, in that way. I wanted to do it on my own terms.

When my mom asked if I was gay, I faced a choice. I could deny it, which might keep me safe for awhile. Or I could tell the truth and pay the price.

Through tears, I told the truth.

Two years ago, I joined Cityblock. Alongside psychiatrists, social workers, and other specialists, I work to provide care to people with complex health needs.

An undercurrent of trauma runs through the populations we serve. To counter this we practice trauma-informed care. Trauma-informed care is a framework for minimizing harm through understanding trauma and its effects and proactively working to prevent re-traumatization.

Rather than asking, “what is wrong with you?” a trauma-informed approach asks, “what has happened to you?”

As I learned about trauma-informed care I began to wonder, what would technology look like if it recognized trauma as a force in all our lives?

Over the past six months, I’ve interviewed care teams at Cityblock to understand how they confront trauma. They’ve shared tips on technique and language, and shared stories. Together we’ve explored how we might design technology from a trauma-informed lens.

Trauma-informed design is the practice of building systems which reduce harm and foster healing

There are six principles for a trauma-informed approach:

Safety
Trustworthiness and Transparency
Peer Support
Collaboration and Mutuality
Empowerment, Voice, and Choice
Cultural, Historical, and Gender Issues

These principles were developed by the Substance Abuse and Mental Health Services Administration (SAMHSA) and the American Psychiatric Association to address in-person care, but we can adapt them to a digital context.

Before that, however, it’s important to talk about what trauma is and how it affects the brain.

Trauma is an experience that overwhelms someone’s ability to cope

Trauma can occur as a result of violence, sexual abuse, physical abuse, loss, terrorism, natural disaster, and other emotionally harmful experiences. It may be a single moment, or a pattern of events spread out over months, years, or generations. It affects anyone.

Trauma affects the way that you view the world and the way that you view yourself. Rob Jordan, Behavioral Health Specialist at Cityblock

Trauma exists as an embodied, measurable force. It rewires neural pathways. It manifests through avoidance, nightmares, flashbacks, anxiety, dissociation, hypervigilance, and intrusive memories.

Tech can frustrate stressed-out brains

Imagine this:

Someone presents you with new information. You register what you’ve been told, but before long, you can’t remember what it was. Was it important?
Images, words, shapes, and motion don’t always appear “present”. They’re somehow detached from reality. You struggle to recall them.
It’s hard to categorize objects. What goes where?
When filling out a form or something that requires accuracy, you often make errors and don’t spot them until you’re told.
Staying focused is a challenge. You often feel unmotivated to start and complete tasks. Small distractions can wreck your concentration.
Tiny things can provoke strong anger or fear or make you unable to move. Later, you may tell yourself that your response wasn’t rational, but this doesn’t prevent it from happening again.

This is life for many people with a history of trauma, and it presents serious obstacles to everyday use of technology.

Minor frustrations for non-traumatized brains may present serious obstacles for traumatized ones.

This happens because extreme stress changes the brain’s structure. It decreases the volume of the anterior cingulate cortex — which deals with attention, error detection, and motivation — and the volume of the hippocampus, which helps encode verbal declarative memory.

On the left: a healthy brain shows most activity (red and white) in the cerebellum. On the right: A PTSD brain shows changes to the anterior cingulate cortex, the amygdala, and the hippocampus. Source.

In addition, the amygdala — the brain’s fear response center—becomes overactive, making higher-level thinking much more difficult.

These changes to the brain are visible in people with PTSD, but PTSD is only one subset of trauma, which affects the brain, body, and spirit in many ways.

Trauma-informed design is accessible design

The physical world can inform our approach to designing digital spaces. In the 1960s, 70s, and 80s, people who use wheelchairs waged a campaign to require cities to build curb cuts—the ramp connecting sidewalks to street-level. Without them, the six-inch drop made cities unnavigable.

The Americans with Disabilities Act was passed in 1990, making accessibility a requirement for all public spaces. It wasn’t long before parents with strollers, postal workers with mail carts, and kids on bicycles realized how helpful curb cuts could be for them, too.

By prioritizing those with the greatest need, trauma-informed design improves life for everyone.

Six principles for trauma-informed design

We can get close to trauma-informed solutions by simply practicing “good design.” Many design patterns exist in direct response to the quirks and limitations of human cognition. Intuitive organization, familiar interaction patterns, intentional use of visual principles, and the ability to offload working memory all make people feel calmer and more in control.

Even small frustrations and cognitive burdens drain our ability to make informed, healthy choices.

“The least frustrating design,” says Rob, “is going to be trauma-informed.”

While researching, I asked friends and family to share moments when technology has hurt them and when it has helped. Their thoughts, anonymized, are quoted in each section below.

Safety

Dating apps automatically pulling info from Facebook has allowed people to find me on other platforms and say, hey, we didn’t match, but *hey*, I *really* liked you.

A band member I follow shared a brutal video on Instagram and I literally felt ill. Like visceral, horrible. I had to swipe up to get it out of my phone’s frame.

Noonlight and iPhone’s SOS feature give me peace of mind knowing I have a modern-day Life Alert built into the thing I carry around with me everywhere.

To help people with a history of trauma, “safety is the first priority,” says Loretta Staples, Behavioral Health Specialist at Cityblock. “Oftentimes, traumatized people do not feel safe in their own body. I try to create a holding environment, one where the person feels not smothered, but contained.”

She continues, “I never say, ‘this is a safe space.’ I don’t have the power to make that declaration.”

The systems that we design should counter abuse, permit making safe mistakes, promote privacy by default, and moderate content to prevent the spread of hate speech and disinformation.

Recommendations:

Conduct abusability testing. “From Zoombombing to discriminatory chatbots, we track abuses across a wide range of platforms,” states platformabuse.org. Building with good intent isn’t enough to stop abuse. But understanding common patterns and mitigations makes it possible to prevent abuse from happening.
Support making (and fixing) mistakes. Humans are fallible and distractible. If someone makes a mistake, provide an easy way to undo or fix it, paying close attention to the tone that’s used to communicate the error. Permanency is stress-inducing; impermanence fosters psychological safety.
Default to privacy. Say there’s third-party integration you share data with. Do you ask for consent from users before sharing their data? Fewer than 5% of people change the default settings, so make sure default sharing settings promote privacy and safety.
Moderate content thoughtfully. In digital spaces, profound harm can come from other users; preventing trauma requires placing limits on what users can say and do. The Santa Clara Principles on Transparency and Accountability in Content Moderation outline three principles for fair content moderation. Additionally, the Forum on Information and Democracy’s Report on Infodemics lists “250 recommendations on how to rein in a phenomenon that threatens democracies and human rights, including the right to health.”

Trustworthiness and transparency

I feel spied on. It’s weird if you show up to, say, a hotel, and the concierge knows all about your personal life. That’s what some products in tech feel like.

Whenever I search something on Google and then I see an ad for that on Instagram, I wonder, if they know that about me, what else do they know? It makes me feel vulnerable and exposed.

The Diagnostic and Statistical Manual of Mental Disorders mentions “a sense of foreshortened future” as a symptom of trauma. Trauma damages trust, and a lack of trust warps the experience of time itself, states a 2014 study. Survivors of trauma often strongly believe that bad things — like dying early, or suffering rejection — are sure to befall them.

“Trust has been violated with many individuals with a history of trauma,” says Rob.

Broken trust is difficult to rebuild. But we can work to promote trust by practicing transparency. Don’t exploit or manipulate people. Don’t ask for unnecessary information. Eliminate black boxes. And let people know ahead of time when you’re planning to roll out big changes.

Recommendations:

Don’t exploit people or the environment. This should go without saying: any technology which depends on the exploitation of people or places cannot be trauma-informed. This includes advertising, which sells our attention without consent.
Avoid deceptive patterns. Deceptive patterns are “tricks used in websites and apps that make you do things that you didn’t mean to, like buying or signing up for something.” They can take a variety of forms, like misdirection, ads disguised as content, or items snuck into your basket before checkout. Common among them? They manipulate people to benefit a business.
Don’t ask for unnecessary information. If you ask for something like “gender” on a registration form, consider first whether that information is essential to know — if it’s not, remove it. If it is, plainly state why you need it and how you’ll use it. Apple has begun requiring developers to disclose privacy information to users in the App Store. App “nutrition labels” will help inform people about what data companies have access to. Do you do the same within your product?
Eliminate algorithmic black boxes. “Why was I shown this?” is a question that anyone should be able to answer. Since Instagram changed the feed from chronological to algorithmic in 2016, people have repeatedly asked to bring back the previous time-based ordering — which so far, Instagram has refused to do. Algorithmic ordering offers Instagram a way to quietly hide and reorder content — but to whose benefit? Without insight into how the algorithm works, it’s impossible to know.
Prepare people for change. Imagine returning home one day to find that your landlord had sold all your furniture, bought new stuff, and arranged it completely differently. This happens in technology daily. If you need to swap out some furniture or move things around, give a heads up. Gradual, incremental change is generally preferable to sweeping redesigns.

Peer support

A trans friend reached out to me for help. They wanted me to report a pre-transition photo of them so it would be taken down quickly.

There are some small Discord servers I’m a part of that are cute and fun, despite all being strangers. Decentralized platforms allow for these subcultures [to form] that don’t have anywhere else to congregate.

If I’m using a piece of technology, peer support is about communicating and working together with people like me to understand and work through any problems I may encounter.

It’s important for tech systems to allow for public critique, emphasize shared humanity, and contextualize data to encourage informed reactions.

Recommendations:

Support peer discussion and public critique. Give people the chance to provide feedback on the technology you build. Developers of electronic health records like EPIC attach gag orders to contracts with hospital systems which prevent doctors from critiquing or discussing problems with the software. Doctors aren’t allowed to post screenshots—even satirical ones—and these intense restrictions can lead to fatal results for patients.
Emphasize shared humanity. On the internet, it’s easy to type things we’d never consider saying to someone in real life. Are there changes you could make to humanize the way peers engage? In 2016, Nextdoor rolled out a new reporting flow which reduced posts containing racial profiling by 75% by requiring reports to be specific. How can you remind people that there’s a person on the other side of the screen?
Contextualize data. Apps like Citizen and Nextdoor have driven a rise in fear about crime, even as crime has fallen to its lowest level in decades. People are superstitious. When presenting data, consider whether the degree of focus on that data matches the degree of the problem in real life.

Collaboration and mutuality

[The Q&A platform] Stack Exchange has a meta discussion board where anyone can post feature requests and leave comments on announcements before a new release. Engaging the community really helps build a strong platform that everyone can help shape.

[3D creation tool] Blender is open source. The community is amazing, and enough people (and corporations) donate that they’re able to pay for full-time staff.

While the previous principle is about enabling people who use your technology to empathize and work together, collaboration and mutuality is about working as equals with the people you’re building for.

“People aren’t data sets,” notes Loretta. “People are highly-edited presentations of self.” And despite the language often used in tech, people aren’t “users”—people are people.

By collaborating with the people you build technology for, solutions improve. You use familiar language, avoid assumptions and judgement, weed out guilt and shame, and recognize that the things you want to do—as a designer, an engineer, or a product or business leader—are not always the things that others want or need.

Recommendations:

Listen and co-create. When interacting with Cityblock members, Social Worker Charlotte Christopher notes the importance of coming up with meaning together rather than prescribing what must be done. “I’ll say, ‘I see a note about depression in your chart,’ rather than, ‘I see you’re depressed.’ Both people are learning, even if it’s on a different level.”
Use familiar, people-first language. Use words that a person uses to refer to themselves. It may not always be technically accurate, but it’s language that’s comfortable and familiar. At Cityblock, I’ve been on a mission to replace every instance of the words “the member” with a member’s preferred name, as a constant reminder of their individuality.
Avoid assumptions and value judgements. When Cityblock updated the list of areas a care team might focus on with a member, we cut out all negative value judgements. For example, “Substance Abuse” evolved to “Substance Use”, and “Poor Housing Conditions” became simply “Housing”. Not only are these labels more respectful, they expand possibilities.
Don’t guilt or shame. Many marketing sites use a tactic called confirmshaming to increase conversion rates, presenting a choice like “sign me up” against “no thanks, I hate saving money.” Don’t do this.
Don’t create false urgency. After hearing the ping of a notification, it’s common for anxiety to spike. What’s this message about? Is this something bad? Can I look at this now? Do I need to respond? Think hard about which notifications are truly urgent. Cut the rest.
Mind “engagement” versus addiction. Dissociation is common in individuals with a history of trauma. Can your product be used mindlessly? Infinite scroll and new content on every refresh make it easy to lose track of time. Intentionally adding friction — like paginating content instead of scrolling — can increase awareness of time spent.

Empowerment, voice, and choice

When I reactivated my Instagram after deactivating it several months ago, every person I ever tagged was re-notified, including my exes.

The ‘so-and-so viewed you’ notifications on LinkedIn don’t tell me much besides someone keeps obsessively looking at my page.

It’s really lovely to be able to say ‘I don’t want to interact with this person’ and make them (sort of) disappear through hiding/blocking them. [There are] lots of people from my childhood I want nothing to do with…

Trauma is often the result of being out of control in a situation. Thus, it’s critical to give people the power to change things—whether that means deleting their account, revoking consent, or adjusting what appears and what doesn’t.

Recommendations:

Support the right to relocate. Can people download their data? Can they delete it from your system at their request? Can they transfer it to a competitor? Avoid vendor lock-in.
Always allow opting out. When designing forms, there may be questions people aren’t comfortable answering. Present the ability to respectfully decline. If anyone ever wants to quit your service or modify the terms they initially chose, let them. “Consent on Monday doesn’t mean consent on Tuesday,” says Charlotte.
Build thoughtful settings and preference panes. Where is the locus of control between the designer and the user? User-controlled settings help redistribute power. Do people have the ability to disable features they don’t want or need, or enable ones which could improve accessibility and comfort? There’s a balance—providing too many settings can overwhelm, too.

Cultural, historical, and gender issues

Pregnancy apps are super normative and make a lot of assumptions. I don’t need to know that my baby is the size of an apple. I need to know where to find a midwife near me, or what to do when this part of my body hurts.

I’m very sensitive to weight loss-centered language with fitness or activity apps. I just want a numberless food tracker!

[Planned Parenthood’s period tracker] Spot On never assumes you identify as a woman, want to get pregnant, have tits, etc. A lot of period trackers make fertility their main focus, so Spot On was a relief.

People from different backgrounds go about the world differently. If people from different backgrounds aren’t a part of creating your technology, you’re going to miss things. You might miss an algorithm amplifying bias, or the impact of metrics on self-worth. Your language might unintentionally exclude certain people.

Charlotte observes, “everybody wants to be known, but nobody wants to be labeled.”

Recommendations:

Build diverse organizations. A 43 year-old Black man, a 67 year-old trans woman, a 32 year-old undocumented immigrant, and a 28 year-old cisgender male all have different lived experiences and relations to trauma. They’ll each offer different insights into how your technology might succeed or fail, and what notions of “success” or “failure” even are.
Watch out for algorithmic bias. If you’re training an algorithm, what data is it based on? Does that data perpetuate current day injustice? A 2019 study found that an algorithm used in health systems across the US was “less likely to refer black people than white people who were equally sick to programs that aim to improve care for patients with complex medical needs.” The algorithm’s dataset included many doctors who systemically assigned lower risk scores to Black patients. Encoding those decisions in an algorithm perpetuated bias.
Beware of vanity metrics. Likes, comments, followers, and other social metrics can weasel their way into measures of self-worth. Negative self-image is one common response to trauma — consider whether you’re quantifying the value of a person, and what the implications of that are.
Avoid seen states and read receipts. Seen states and read receipts can heighten anxiety and hypervigilance by causing individuals to question whether the seeing-of is a response of its own. They take something implicit and private and make it explicit and public. Hypervigilance or the feeling of “being watched” can also decrease the feeling of safety.
Write inclusive, assumption-free language. It’s common for health organizations to use the phrase “women’s health” as a way to talk about things like menstruation, pregnancy, and pap smears. Yet “women’s health” as a label disregards the significant number of trans men who may need to discuss these topics. Is there language you use which makes assumptions about people? See if you can adopt a more inclusive alternative.

Putting theory into practice

Trauma-informed design is difficult work

It’s often easier, both technically and organizationally, to barrel forward with a new feature or product without implementing things like user settings, consent-based workflows, privacy safeguards, and algorithmic transparency.

Technologists have an enormous responsibility to create systems of interaction which respect individuals and promote healing.

When we move fast and break things, sometimes the things we break are humans. This work is difficult because it’s worthwhile.

Design is not enough

This isn’t a framework you can slap on at the end of the project and call yourself trauma-informed. You have to step back and look at the business model itself to ask whether it exploits or perpetuates harm to individuals, groups, or ecosystems. A business model which relies on selling user data is not safe or transparent, no matter how clean the interface is. A business model which exacerbates inequality will also exacerbate trauma.

Trauma-informed design requires asking questions and establishing a dialogue, not prescribing answers. If you’re used to moving quickly, adopting a trauma-informed approach will likely slow you down. This is good. It means you and your team are taking time to answer difficult questions about how your technology affects the well-being of others.

Through trauma-informed design, we can create a future where technology respects our attention. One that’s quietly supportive, not presumptive or over-helpful. One where we’re free to move between platforms without guilt. One where we know our data isn’t sold at our expense. Where we feel safe. Seen, but not watched.

“Mistakes will be made,” Charlotte says. “But it’s important for someone to believe they will be heard.” Keep feedback loops open, co-create meaning, and above all?

“Be more gentle.”

After I was outed, things got difficult for a while. I remember locking myself in my room and sobbing into a pillow and feeling deeply alone. I remember feeling exposed and unprepared.

Compared to other kids, I was lucky. I wasn’t kicked out of the house. I wasn’t taken out of school or sent to conversion therapy. Although this was before a marketing campaign would tell me so, it did get better.

My parents eventually came around. With my sister, my mom attended a protest against Amendment One in North Carolina. A year after coming out, my digital and physical worlds merged more fully: my parents got to meet my first boyfriend, who came to visit from South Carolina. We’d met on those message boards.

Emboldened after a return home from college, I pose beside a church sign in 2015.

I doubt that the designers and engineers working on YouTube in the 2000s expected their recommendation algorithm to out a Southern teen. Yet it did.

What if those YouTube recommendations hadn’t been there? Would history have taken a different course? I can’t know for sure, but I do know that for everything I build now, I want my designs to be trauma-informed.

Special thanks to Ari Rosner, Blithe Parsons, Charlotte Christopher, Jon Marquez, Juliana Ekong, Lon Binder, Loretta Staples, Maria Boncyk, Neves Rodrigues, Owen Tran, Pooja Mehta, Rob Jordan, Taylor Maynard, Toyin Ajayi, and many other friends and colleagues who contributed to this article.