The perfect software team has one designer. The designer codes.

Like it or not, the perfect software team works together in the same room.

There is no product manager on the perfect software team.

Let’s say you agree. Let’s also say you have at least some basic technical skills and want to use them to contribute in your day job. Now what? How should designers code? How can you actually get involved in the development process at work?

I can think of several possible entrypoints you might want to consider. These are all based on my own experience as a product designer on cross-functional teams of all sizes that viewed designers working in code as either tolerated, supported, or expected.

Some variables to keep in mind when reading these options and choosing where to start:

• Your own skill and comfort levels — Are you ready to dive in and write production code or are you still learning the ropes?
• The shapes of your teammates — Do you have a strength that can help patch an existing gap?
• The status quo of the team/organisation — Could there be any friction or gatekeeping that hinders your initiative?

I’ve listed them roughly in ascending order of demand on both time and technical skills, though the last two are interchangeable depending on a number of factors.

Pair program

This is by far the easiest way in, and even easier if if the team is already in the habit of pair programming. Just ask to join engineers while they build things.

Pairing is almost always productive and enlightening, but especially so when you’re new to a language or codebase. Ask questions, take notes, and offer what you can. That might be a good eye for detail, design system knowledge, CSS tips, accessibility considerations, or whatever else you’re good at. You can begin to establish your credibility as an asset to the engineering team without even having to touch your keyboard.

With pairing, you don’t have to wait until the work is “done” to find issues with it. Whether implementation doesn’t mean your expectations or your own design falls down when met with stress cases, you can adjust on the fly. It’s more efficient to have these conversations and fix shortcomings as problems are identified rather than let them block development.

Review pull requests

I like to kick off any new project or team by asking engineers to request my review on pull requests that make user-facing changes. It’s a good way to understand how code actually get shipped, and a great way to catch a lot of low-hanging fruit.

Depending on the stack your company uses, it might require a bit of knowledge to be able to read code for components or views and understand how it will look. It’s helpful if changes are deployed to staging environments so you can look at things and suggest changes to the code if you see issues.

If you have a design system where naming is aligned across design and code, you might be able to raise a lot of nits. Are the variables for colour, spacing, etc. the right ones? Did they use correct button variant? Is the copy capitalised properly? Did someone write new copy for an error case and it doesn’t make any sense? Don’t be afraid to get in there and make suggestions.

If you are or get really good in a certain area, you might be able to take more responsibility at this stage of the development process. At Litmus, I was a codeowner for all of our CSS files. Any changes to those files were flagged to me so I always had an eye on things and could jump in if needed. At GitHub, I’m on the codeowners team for Actions; I subscribe to Slack notifications for every new pull request assigned to that team and regularly stop minor mistakes from shipping.

Fix bugs

You’ll never prevent all of them. There were visual bugs in production before you started and there will be visual bugs in production long after you leave. But sometimes they’re almost as quick to fix as they are to document and explain, so it can be effective to do it yourself when you spot them.

Again, common offenders are copy issues, incorrect colours, and spacing misalignments. Those are approachable problems if you understand a bit of frontend code and/or how your design system works. Getting some reps in for creating a branch, making a very easy change, opening a PR, and shipping to production will expand your understanding and build your confidence.

You’ll eventually run into complexity in the code. Maybe you can’t change something because it also affects another area (or you can’t be sure what it affects), or a line of copy is actually generated by some confusing logic, or sometimes you can’t even find the source code for what you’re looking at in the browser. Those are learning opportunities. Stretch yourself to try to make sense of these things, but know when to ask for help and also when to cut your losses.

Scaffold UI

This is one of my favourite ways to work with engineers. Before I even knew how to render a new view in Rails, I would ask someone to create one for me and push it to a branch. Then I’d populate it with actual HTML and UI components, using comments as pseudo code for all of the logic.

Here’s a super basic example.

<!-- If user is signed in -->
<div>
  <p>You’re signed in</p>
  <button>Do something</button>
  <!-- If user is an admin -->
  <button>Do an admin thing</button>
</div>
<!-- If user is not signed in -->
<p>You’re not signed in</p>

You don’t have to know how to make anything work, just how to make it look like it should. This will render all of the elements, but as real logic is layered on, it falls into place. In my experience, engineers who are less interested or skilled in building UI loved this type of collaboration because I took those tasks off their plates and they never had to deal with me raising visual bugs.

As a bonus, the code you write in this way doubles as design documentation. There are communication and efficiency benefits to speaking the same language as engineers and not having to mock up or write out all of the various states and edge cases. Learning to think about implementing designs at this level also gets your brain working like a programmer’s. When you see that logic after it’s translated to actual language syntax (maybe in a PR you’re reviewing), you start to learn how to do it yourself.

That HTML above might ship like this. Doesn’t seem so unapproachable all of a sudden.

<% if current_user.signed_in? %>
  <div>
    <p>You’re signed in</p>
    <button>Do something</button>
    <% if current_user.is_admin? %>
      <button>Do an admin thing</button>
    <% end %>
  </div>
<% else %>
  <p>You’re not signed in</p>
<% end %>

Build prototypes

It’s not always the most productive design approach, but when it feels useful, I like to create proofs of concept as low fidelity prototypes in CodePen. This can be a fun way to explore options for interactions.

In these examples, my code was written to be thrown away. (Check out that old jQuery.) The visual design isn’t polished and the content isn’t realistic. But it was the quickest way to have every stakeholder understand what the different experiences would feel like so we could discuss them from the same point of understanding.

Prototyping can be whatever you want it to be. I prefer a sandbox, others like a branch in the real codebase. At GitHub, some designers even have a React boilerplate for creating high fidelity prototypes using our design system that feel just like the real product. Because you’re just making a temporary artifact, you have the freedom to use whichever platform and tech stack you’re most comfortable with.

There can be a few gotchas I should note. These will largely depend on the engineering team you work with.

The biggest hurdle you might face is that the organisation is simply not set up to support or allow you having access to code. There are many companies where non-engineers don’t have access to necessary systems and credentials, and requests are met with restrictive policies or at least warranted friction. There’s usually nobody to have your back, either — you might have to keep pressing the issue on your own or through your manager to make progress.

The other is that engineers might be sceptical that someone else wants to be involved. Some orgs are very segregated, and engineering teams can be insular. The best teammates will welcome the interest and help but some might feel like you’re stepping on their toes.

One way to approach both of these hurdles is not asking or telling but showing what you can bring to the team if you’re involved with code. Pair with engineers; build prototypes; use your browser’s inspector to debug issues and share solutions. Earn trust and doors will open.

Lately I am more prone to shutting the fuck up. I don’t know if it’s me or the internet that’s changed since then. Probably a little of both. I definitely feel less of a desire to stay hyperconnected to culture as I age, but social media has also taken a palpable nosedive over the last few years that has rendered it nearly unusable.

…

These are people desperate to be heard but with nothing to say. Who would want such a fate? It reminds me of that line from the first scene of No Country for Old Men. “A man would have to put his soul at hazard. He’d have to say, ‘Okay. I’ll be part of this world.’”

If you spend too much time getting lost in it, it all feels very important. But when you take even the smallest step back, out of this online prison of our own making, you realize none of it actually matters. 

The system was pretty lofi. I just saved the above image on my phone and set a recurring reminder to duplicate it and add data points every week or so with the iOS drawing tool. The better I felt I did in that category that week, the higher the rating. If I dropped the ball, low rating.

The result would look something like this.

I saved all of the images in the same folder which let me scrub through and see the changes over time. Perfect 5s was never the goal — that’s a path to burnout. It’s all about managing the balance. If a rating was low, I knew to pay it some mind and book a dinner date, text a friend, or call my mom. It helped visualise focus and make sure nothing I decided I cared about was slipping through the cracks.

At one point I wrote a web app for this, because of course I did. I could add or remove categories and add sets of values. I used Chart.js to generate the chart. It’d probably make a better iOS app with push notification reminders.

Eventually I stopped doing it. It hit a sweet spot for me between goal setting and habit tracking, but after it trained me to be conscious of balance and progress, it became less useful.

Writing

I’m partially publishing this post as an anchor. I’d like to return to writing more thoughtful and substantial on my own website. I didn’t write a single “article” here in all of 2023, though in absence of Twitter I was fairly consistent (not prolific) with my feed.

I subscribe to the RSS feeds of some people whose writing I really envy. My favourite bloggers are those who make it feel effortless. They post about seemingly random topics and I find it interesting because it’s in their voices. I also like the recurring themes certain people employ. Dave Rupert has a recurring vibe check where he summarises a number of areas in his own life, and I think stealing that type of lightweight structure might work well for me, too.

My two aspirations: write regularly, and make the habit of publishing feel easy.

Running

Consistency is also key to this one. I picked running back up around June of 2023 and I really love it. I’m good at running and it’s always come naturally to me. In the past, though, I’ve always focussed narrowly on bettering my 5K time and I’ve realised this go around that I much prefer endurance over greater distances. I’ve swapped the racing flats for max cushioning and traded in the Spotify playlist for podcasts. My longest run in 2023 was a 31 kilometre (19 mile) round trip from my flat in East London to the Design Museum in Kensington. It’s especially great to be a runner in London because I can take a new route every day and there’s always something interesting to look at.

This year I’m not going to set goals for speed or mileage. I don’t care if I run a race. I just don’t want to hit a slump. If I run at least 2–3 hours every week I’ll be happy. If my self-discipline slips and I find my shoes collecting dust, I’ll be disappointed. If you run, too, follow me on Strava for accountability.

New house

Alana and I bought a house! Almost. We’re in the final stages now, just waiting on solicitors to finalise paperwork, and due to get the keys in a matter of weeks. It’s move-in ready, which was important to us for the first home we buy, so there aren’t any major projects on the horizon. I want to replace some carpet with wooden floors ASAP. We’ll paint, obviously. But mostly just superficial improvements, barring any nasty surprises.

We’re planning to work our way through the house and make it our own room-by-room. It’ll be a lot of work and take up a lot of my free time, but it’ll also be rewarding. We’ve saved for years to “get on the ladder.” My goal is to have the interior fully decorated and furnished to the point that we’re really happy with everything by the end of the year.

Career

The vibe at work was pretty gloomy for most of 2023. That had a big impact on morale, even if I grew really close to my team through the uncertainty. Now that we’ve started hiring for a bunch of new roles for the first time in almost a year, it feels to me like we’re finally back to normal.

Frankly, between the layoffs and lack of career progression, I found myself mentally checked out for a good chunk of last year. Despite that, I’m unable to turn off and ended up with positive reviews. I’m also starting the year off by transitioning back into design engineering and moving to a different product area, which I’ll say more about soon.

Goals? Don’t fuck it up. Leave 2024 with a better title and bigger paycheque than I entered with.

Side project

I’ve had some app ideas bouncing around for years. One in particular is a working proof of concept with real users that continue to provide positive feedback and recommend it to others. The only problems are that I hate its current form too much to share it myself, and the codebase is not fit for purpose. I know everybody says these things, but this thing is built fully client-side, using jQuery to grab data from Firebase. It’s really hanging on by a thread.

This is the year I ship it for real. I still think it has legs if done right. And if it doesn’t, I think I have what it takes to learn and pivot. And if I don’t, well, I still think startups are fun. I owe it to myself to give a SaaS an honest try.

Email Geeks

This one’s bittersweet. Since 2016, I’ve helped grow and maintain the Email Geeks community for the email marketing industry. We’re at 21,184 members as I write this. That work has opened a lot of doors for me and introduced me to a lot of people. I’ve given a lot back, too — probably hours a day on average for eight straight years, even if most of those hours were passive. Between the admin, member vetting, content moderation, development of internal tooling, a near legal battle, and the 2020 salary survey, there’s been no shortage of volunteer work. Not to mention all the ideas I didn’t get to.

But it’s been almost two years since I worked at an email-related company. I take the stewardship seriously but that’s not my world anymore. Facing a potentially demanding year with everything listed above, something needs to give. I want to launch the 2024 salary survey, automate what I can to replace myself, and then log out for at least a while.

Bonus: Profile photo

I’ve been using the same headshot everywhere for a little too long and it’s starting to get ridiculous. I’ve been growing my hair for a year and a half. I need to use a new photo.

It made me think of political elections. It’s not uncommon for an underdog candidate to run on a strong and principled platform. They gain a small, dedicated following and when it’s clear they won’t have the numbers needed to win, they endorse a more likely candidate in exchange for that candidate adopting their key policies.

Software isn’t a zero sum industry but there are plenty of cases of startups forcing the big dogs to up their games or adopt certain features that users come to expect.

In 1–2 years, it’ll feel like Facebook did after the moms showed up and young people shifted most of their posting to Instagram.

“You still use Twitter?” “Yeah, it’s the only place I can keep in touch with certain people.” “Oh, that sucks.”

In 2–3 years you’ll log in for the first time in a few months. It’ll be full of brands, a few people you never really knew that closely tweeting inane shit, ads, and the odd “haven’t tweeted in a while — anyone still on here?”

The new owner immediately sacked the entire Human Rights, Accessibility, AI Ethics, Public Policy, and Curation teams. Possibly others. I don’t want to use a Twitter that doesn’t have those things. I’ve already had the guy blocked and his name muted for months.¹ I don’t want to drive his car, I don’t want to use his social media platform, and I don’t want to spend time with people who think he’s okay.

Even if the dust settles and my personal Twitter experience remains fine, it’s already exhausting. Constant stream-of-consciousness “announcements” and uncertainty around new features or policies that may or may not be implemented isn’t fun or interesting. I don’t have any desire to make mid- to long-term bets on someone else’s company or my daily online life. As someone said (in a tweet), it took only one week for him to entirely destroy the userbase’s trust. It seems like the only people having fun on Twitter right now are trolls with illustrated profile photos. I get the sense that’s going to continue to be the vibe.

So where to next?

Social media has always been a large part of my online life. As a kid I used guestbooks, chatrooms, and message boards. In my teens I was an early adopter of the some of the earliest profile sites with dumb names like like RateMyInfo and What The Dilly. They were mostly full of weirdos like me; when the normal people at high school finally found MySpace, we entered a different era. I went online to get away from everyone but eventually they found me. Still, I did Facebook, did Instagram, and I’ve been on Twitter for almost 15 years.

A few people have asked me if I’m going to use Mastodon next. It seems like that’s the go-to lifeboat, at least for my tech-inclined social and professional circle. I’m just not drawn to it. Mastodon is like Twitter but more complicated and worse in almost every way. It’s possible I might start syndicating posts there if it reaches critical mass and seems interesting enough, but I’m not rushing over.

I asked myself why I would join another social media platform right now and I simply had no good answer. “Everyone else is doing it” isn’t enough. Right now I’m just looking forward to having my time and attention back.

Designing at GitHub, I plan and track my work using issues and projects. I create mockups and prototypes in Figma. Maybe I record some Loom videos. I share those issues, files, and videos in Slack messages and channels. I also pluck out bits to share on Campsite. Each of these products has its own commenting system.

I receive each of their notifications in different ways:

• Slack and Figma via Slack
• Loom and Campsite via email
• GitHub via our internal-only macOS app¹

This gets super messy. Any time I share work, I open myself up to comments from multiple sources through multiple channels. Commenters are blind to each other’s input, the feedback invariably gets repeated, and context and decisions are explained over and over. More time can be spent relaying the side conversations back and forth than moving work forward.

Additionally, some products implement comments in a way that aren’t as fit for actual discussion. If comments don’t have anchor links I can reference elsewhere, can’t support branched discussions (threads), and don’t put notifications into my critical path², I treat those as input-only. People can look at my thing and tell me something that I’ll make note of, but I’m probably not going to reply there.

All of this usually leads me to explicitly tell people where I want them to provide feedback: “Here’s a Loom video and the Figma file, but please leave your thoughts in this Slack thread.”

I generally prefer Slack for feedback intake because it’s low-friction for everyone involved. I can easily broadcast bite-sized updates where people are already looking and it’s conducive to making quick decisions — especially small ones. It also allows everyone to see all the other feedback on that topic and quickly get just enough context.

The downside to using Slack is that my thread is just another unread channel indicator and just another message in the feed. It can be difficult to solicit sincere engagement. Easy come, easy go.

For each major piece of work, I also maintain a long-running GitHub issue to track my entire design process. All decisions, feedback, TODOs, and iterations are documented here as work progresses and the project evolves. If someone leaves a comment elsewhere, I even collect and quote their feedback on the relevant issue and link out to it as a reply to their original message. The issue is the source of truth.

It should be easy for anyone else — from a product manager collaborating with me now to another designer in 5 years — to read the description and comments from top to bottom and understand not only what I did, but why I did it, what else I tried, and the feedback that shaped it all. It feels like writing a case study in realtime.

Then they automated the warehouse workers, and I did not want universal basic income—because I was not a warehouse worker.

Then they automated the artists, and I did not want universal basic income—because I was not an artist.

Then they automated me—and there was no one left to provide universal basic income for me.

I once read someone’s take that the way people remember you professionally is determined 50% by the time you worked there and 50% by how you leave. I think it’s probably more like 75/25 but I like the premise and took it to heart during my notice period over the past few weeks. I did my best to prompt everyone for questions, answer them all, and leave thorough handover notes. I even hosted a tutorial workshop for the entire product engineering team to create a design system component with ViewComponent.

I’ve kept thinking the past few weeks about the git blame legacy I’d leave behind. Will some new hire be in there in 2024 wondering what the fuck Dylan Smith was thinking when he did it like that? I hope not, but that’s what The Prime Directive is for I guess. It’s a good thing I’ve coded with this in mind from day 1; the last however many days is far too few to late to do much about it.

The anticlimax of ending one job sat alone in my home office² was offset some by receiving a laptop and calendar invitations for my new job. One of those calendar invitations caused a bit of a panic, though. I have to get on Zoom and hold my passport to prove that I am who I say I am… but I haven’t seen my passport since I last travelled abroad in November 2019. I’m convinced it’s in my flat someplace and that I’ll eventually find it in a pocket or bag or in the bottom of a drawer, though I’ve spent hours searching with no luck. A last-minute passport replacement was my only option.

Luckily I was able to nab an appointment just two hours from the time I checked the booking site on Monday afternoon. I rushed to the Post Office for an application form, filled it out back at home, and realised I needed a guarantor. Knocked on my neighbour’s door as he was leaving and he was nice enough to give me his passport so I could fill in the necessary details. I had two passport photos sitting in a drawer so I grabbed those and rushed off toward Victoria on the tube. I made it with minutes to spare.

When I handed the employee at the desk my photos she told me immediately they were too large. Canadian size, I realised, from renewing that passport a couple of years ago. My heart sunk but immediately jumped back up when she said there were photo booths down the hall I could use and then hurry back to her desk. Let’s just say I was not planning on having my photo taken that day, and definitely not for a document I’ll be showing border guards any time I want them to let me into their countries for the next decade. I’d been growing a “playoff beard” during my notice period and also not slept the previous few nights…

The passport was delivered on Saturday. I start my new job on Tuesday as planned.

The only good thing to come out of the boredom is that I found this history trivia game. You’re presented with a card displaying the title and main image of a Wikipedia article and you have to decide where it should be placed on a timeline relative to the previous cards. My best streak is 15.

I met Neil for lunch on Friday. We’ve lived within walking distance for about five years and somehow never got around to seeing each other in our own area for some reason. I wanted to go to The White Hart but they weren’t serving food so we settled for the Nando’s next door.

After lunch we walked down Whitechapel Market to Ambala. I got a box of my favourites: pistachio barfi, gulab jamon, and jalebis. Neil had never tried Indian sweets before so he played it safe and got the same. Then we walked back east and stopped in to Rinkoff Bakery, just because I never had, before parting ways. The afternoon stroll was a nice reminder to explore my own neighbourhood more often.

Friday evening I met Mike in Exmouth Market. I drove a Zipcar because I try to avoid the tube whenever the COVID numbers are particularly high. In retrospect, this was silly because we spent the rest of the night in busy pubs. Driving through Farringdon and Clerkenwell at 5pm on a Friday highlighted just how big of an impact the pandemic has had on certain parts of the city that rely on office activity. There was little traffic and few people.

I’ve been out for drinks a handful of times since March 2020 (but could probably count how many on both hands). This felt like the first proper night out though. Usually we’d opt to go somewhere less busy, sit outside, and stay in one place all night. This time we moved around a lot and wandered through Clerkenwell on our whims. We went from The Exmouth Arms to Mikkeller to Pivo to The Slaughtered Lamb ² to 1920, where we finished off the night with some pool.

The first thing I notice is the general look and feel of the marketing site. It’s not super unique on today’s web — dark mode, Tailwind UI, Linear sort of vibe — but it does stand out in the email industry where most sites and products look like shit, frankly.¹ They’re apps you have to use, not apps you want to use. Parcel feels different right out of the gate.

Parcel’s biggest strength, though, is that Avi seems to be employing good product practices. He’s super close to his users and embedded into communities where they hang out. As a result, he’s giving them not only features they want but also things they didn’t even realise they need. Listen, learn, ship, repeat.

Another thing working in Parcel’s favour is that they’re a small team (two people building it?) in a fresh, clean codebase. They can move fast. I’ve seen someone make a feature suggestion and it shipped within hours. I can’t think of another product or tool serving email development in this way right now and it’s a huge competitive advantage.

One double-edged sword to consider is that there’s little to no competition in this area right now. Most email tools specifically for developers that I can think of are free and/or open source, and way smaller in their ambitions. Many of the paid products have taken investment and moved upmarket to focus on enterprise and, necessarily, more valuable marketing personas.

Solid startup pattern:

- Find any company "moving up into the enterprise"

- Build a similar product for the startups that will be frustrated by the mayhem that causes

John Cutler

The space is underserved, but what matters is why. I do wonder if the potential market for something like this is too small. Parcel’s Pro plan, the cheapest paid tier, is $24 per user per month. That’s 417 users to hit $10K MRR, a common milestone for bootstrapped indie SaaS companies. 417 doesn’t sound like a lot but…

Email developers and designers are notoriously late adopters.² Many designers still Photoshop or even InDesign instead of modern, purpose-built UI software. Developers still use Dreamweaver and haven’t adopted best practices like version control.³ If we haven’t hit a point where most email practitioners are using industry standard tools, I worry about Parcel being able to attract a critical mass of paying users.

Even if people do learn about it and love it, there’s another challenge: email developers are at the bottom of the marketing department ladder. They’re seen as a cost centre, not a profit centre, serving email design which serves email marketing which serves marketing in general. Email marketing departments do often get budget for software, but that doesn’t necessarily trickle down the same way developers reporting into an engineering department get spoiled. Can potential Parcel users make a compelling case for why they need a $24/mo subscription when their managers think whatever free code editor they’ve been using is good enough?

I can’t help but think that, on another timeline, Parcel’s biggest threat would be a decent set of email-focused extensions for VS Code and developers’ willingness to try them. Instead, because no one else is building that reality, it’s a huge monetisation opportunity if they can just sell to enough customers.

I don’t know what Avi’s ambitions are but I can imagine companies waving cheques at him this year, depending on those companies’ strategies and how keeping email developers engaged might play in. A sticky, lovable product for that persona has an undervalued impact on word of mouth and bottom-up product adoption in marketing departments. And, as above, once email devs get comfortable with a tool they often stick with it.

If I was a larger email company right now, I’d start thinking about inviting Avi to a Zoom call or two. But if I was Avi, I’d probably decline serious talks for the time being to explore a path to profitability. There’s a solid bootstrapped SaaS company to be had here, in a space with a great community that takes care of their own.

I’ve watched the first few videos and his style of teaching clicked for me immediately. The way he explains theory, keys, and scales in relation with the fretboard was eyeopening. For example, I now know these are the A Major and A Minor scales:

|-----------------|-----------------|
|-----------------|-----------------|
|-----------------|-----------------|
|-----------4-6-7-|-------------5-7-|
|-----4-5-7-------|-------5-7-8-----|
|-5-7-------------|-5-7-8-----------|

These scales can be moved anywhere on the fretboard to be played in different keys, always starting on the note the key is named for. I already knew or could tell which notes and chords work and sound good together — I have a good ear — but never could have named which key I was playing in. I’ve been a trial and error player. Knowing (or being able to deduce) the key and which notes are in the scale feels like a cheat code.

On Friday I walked Louis to the vet to get his annual vaccinations. While I was in the waiting room, a man walked in with an injured squirrel in one of those big Tupperware bins. The receptionist gave a bit of a non-answer when he asked how they would treat the squirrel. Then he asked how long they might take; if they wouldn’t be too long, he could bring the squirrel back to where he found it. At this point the receptionist gave a look and a head shake that made it obvious the squirrel wasn’t leaving the vet’s office alive.

I spent a bit of time one morning to take care of some housekeeping on my website. I’m slowly but surely making my site feel like more of an online home for myself, with writing and features beyond just a professional presence. This week I sorted out a box-sizing bug with my blockquote elements, improved the styling of my notes list, and fixed up the width of media in posts. I also added the ability to use a featured image on posts that will display as a larger Twitter card (summary_card_image) which I’d not previously bothered with. That‘s especially useful because I’m going to add more pictures to these weeknotes posts moving forward.

Here are a couple of photos I took this week.

We got our first HelloFresh delivery this week. We’ve been in a bit of a rut dinner-wise, cycling through the same 6–8 meals. I wasn’t sure what to expect in terms of quality. I was especially worried the food would taste bland, as many British recipes I’ve cooked have, but we were pleased with everything. I’ve also found a bit of relaxation in the act of cooking, the same as I get from focussing on brewing coffee or handwashing dishes. (That’s probably just the break from screens.)

Another delivery was my new Oura ring, a Christmas gift. Its sensors monitor vital signs and provide health insights through a companion app. I’ve gone back and forth for a few years about getting an Apple Watch for some of its fitness features like activity goals and heart rate monitoring but I’ve been put off by having a notification vector even more attached to my body than my phone. The ring is a nice alternative and I like the stats and reminders so far. I never would have fancied myself a ring-wearer, though, and it’s quite large so it’s taking some time to get used to (read: embrace a ring as part of my personal style). I might copy someone online who gave their shiny ring a dulled, brushed finish with some light filing.

I was going to include something about how I was listening to a podcast² while cycling to the barbershop and my AirPod fell out of my ear on Hackney Road and got run over by a car before I could pick it up. There’s really not much more to the story though. The aftermath photo got all corrupted and glitched out when I transferred it from my phone.

In other bad luck news, I threw my dog’s flying disc into a tree on Tuesday. Honestly, I’m surprised it took this long. The woman walking away in the bottom right corner of the photo laughed out loud when she saw it happen. I think that’s why I was so determined to get it down. After a few tries, I managed to sling Louis’s lead through the middle while jumping, then pull it off the branch. The woman was long gone.

Some media consumption

I found this 1h42m on Disney’s FastPass system super interesting. It’s a massive deep dive on queue theory as it relates to Disney’s theme parks, which I’m now even more sure I never want to visit. Heads up that I had to watch the video in three sessions because it’s so dense.

The Chat Pile song “Crawlspace” popped up on my Spotify recommendations this week and caught my ear for its lyrics and vocal delivery. The song is written from the perspective of an Oklahoma City police officer painting a picture of his life: “I’m in the garage working on my abs. Swanson in the microwave. Single dad.” The last third… gets dark. Turns out all their lyrics are like this, often inspired by real people and events. Reminds me of a macabre Pissed Jeans.³

The <kbd> HTML element represents a span of inline text denoting textual user input from a keyboard, voice input, or any other text entry device.

As a very basic example, you might write some code like this:

To copy text, highlight it and press <kbd>⌘</kbd> + <kbd>C</kbd>.

I like any HTML element that is semantically specific and unambiguous in its usage; <kbd> fits the bill perfectly. It’s such a meta HTML thing that it probably won’t surprise you to learn it was standardised in HTML 2.0 in 1995.

What I like most about <kbd>, though, is how well it lends itself to interesting visual styles. It usually represents a single key on a keyboard. Physical and virtual keys are little squares and rectangles. If all you do is add a border to it, you’re most of the way there. Even though I very rarely actually get to use this element on my site, I wanted to dress it up as a bit of an Easter egg.

To steal the code below, highlight it and press ⌘ + C on Mac or Ctrl + C on Windows.

(Note this code uses some CSS custom properties specific to my codebase that might look a bit odd but are hopefully named in an understandable way.)

kbd {
  // Set up custom properties for colours so we can switch them in dark mode
  --kbd-color-background: var(--color-background-primary);
  // These interpolated variables reference a SCSS map of HSL-based greys
  --kbd-color-border:     #{color(grey, 80)};
  --kbd-color-text:       var(--color-text-primary);

  // In dark mode, a straight-up inversion doesn’t work for
  // the “physical” key look so they need to be adjusted
  @media (prefers-color-scheme: dark) {
    --kbd-color-background: #{color(grey, 55)};
    --kbd-color-border:     #{color(grey, 25)};
    --kbd-color-text:       #{color(grey, 14)};
  }

  // Match the page defaults in light mode but
  // switch to a light-ish grey in dark mode
  background-color: var(--kbd-color-background);
  color: var(--kbd-color-text);

  // Round off the corners like physical keys have
  border-radius: 0.25rem;

  // Add a simple border
  border: 1px solid var(--kbd-color-border);

  // A sharp shadow (with no blur) really gives
  // the old school keyboard look
  box-shadow: 0 2px 0 1px var(--kbd-color-border);

  // Remove the text cursor — totally optional
  // but I wanted it for my hover effect
  cursor: default;

  // By default, browsers style <kbd> with a monospace typeface
  font-family: var(--font-family-sans-serif);

  // If we do all this with the default font size
  // (mine is 18px on desktop) it’ll look massive
  // and bump into lines above and below
  font-size: 0.75em;

  // Remove any extra space so I can accurately tweak the padding
  line-height: 1;

  // Make narrow numbers and letters look less odd
  min-width: 0.75rem;
  // `min-width` doesn’t work on inline elements
  display: block;
  // Keep the characters centred when narrower than the `max-width`
  text-align: center;

  // Seemed to look more key-like with more horizontal padding 🤷
  padding: 2px 5px;

  // These two lines pull the whole element up now that they’re
  // bottom-heavy due to the `box-shadow`. This looks better
  // against the cap height of regular paragraph text.
  position: relative;
  top: -1px;

  // This is my favourite part of the whole thing. The key gets
  // “pushed” down and the shadow gets reduced so it looks like
  // it might when typing on a physical keyboard.
  &:hover {
    box-shadow: 0 1px 0 0.5px var(--kbd-color-border);
    top: 1px;
  }
}

I want to add a colour theme toggle. My site already has light and dark modes, and automatically switches based on the visitor’s operating system settings using prefers-color-scheme. But some people — for reasons related to visual impairment, readability, or just aesthetic preference — want to change the theme on a case-by-case basis.

The typical way of handling this is to offer a toggle. For example, clicking a 🌙 icon will switch from light to dark and a ☀️ icon will do the opposite. Pretty straightforward. Articles that describe how to implement these toggles will tell you it’s also good practice to keep the visitor’s preference in localStorage once they’ve clicked a button. This is usually implemented to always take precedence over the OS-level setting, and that’s where it starts to unravel for me.

In theory, yes, learning what people want and giving it to them is good. But I think this persistent approach puts too many assumptions into what that button press actually means. Was the visitor telling you “always give me dark mode no matter what” or were they telling you “give me dark mode for now”?

Let’s say it’s the evening. Your operating system’s auto dark mode hasn’t kicked in yet. You visit a website and find the light background is a little too much. You hit the toggle and get a more readable dark mode. You come back to the same site the next morning and you’re still stuck in dark mode. That stinks.

So now I’m wondering what the best UX is for these things. Here are the options as I see them.

1. Don’t give the visitor a choice. Serve a theme based on their operating system setting every time. This will sometimes not be what they want and they will be unhappy.
2. Never remember the visitor’s choice. Serve a theme based on their operating system setting and allow them to override it, but only for that page or visit. They will have to change the theme manually on each subsequent visit if the auto theme is again not what they want.
3. Always remember the visitor’s choice. Serve a theme based on their operating system setting, allow them to override it, then always default to that theme no matter what. They may be served the “wrong” theme for their context on subsequent visits and have to switch back.
4. Remember the visitor’s choice for a period of time. Serve a theme based on their operating system setting, allow them to override it, and default to that theme for the next n hours, days, or weeks. This may have a better chance of getting it “right” next time.
5. Allow the visitor to unset their choice. Serve a theme based on their operating system setting, allow them to override it, default to that choice, but let them switch back to “auto.” Adrian Roselli’s website does this and it seems to account for the downsides and stress cases quite well.
6. Just ask the visitor. Serve a theme based on their operating system setting, allow them to override it, and ask whether they want that theme all the time or just right now. This introduces a tiny bit of friction — perhaps at the wrong moment — but would have the most accurate results.

I’m going to think about this for a while before I decide what to build.

Am I missing a better approach? What’s the best theme switching experience you’ve seen on the web? Email or tweet at me.

I think our design system is hitting its “tweens.” It’s still immature in a lot of ways — this has been a concerted effort less than 12 months — but we’re now experiencing both growth spurts and growing pains. Finding out some decisions we made aren’t quite fit for purpose or didn’t account for unforeseen scenarios is natural but that doesn’t make dealing with it any easier.

This adds a new factor to prioritisation. We were previously balancing three main areas of work:

1. Foundational work to enable us (like the solidifying our colour system, etc.)
2. Designing and building new components
3. Refactoring production code to use components

Now there’s a fourth competing concern, or a 3B: Addressing shortcomings of our components.

By that I mean not only updating them to be more appropriate for new design work — while considering the constraints of existing implementations — but also updating them in production.

We’ll need to decide when it’s the right time or important enough to make something better, and when to make do with what we have. And that’s too complex for one person to decide alone; those decisions and tradeoffs need to account for design priorities, engineering priorities, and capacity across both sides.

Design systems are not easy.

Parkinson’s law tells us that “work expands so as to fill the time available for its completion.” This certainly rings true with my own calendar. Most meetings scheduled for half hour take half an hour or longer.

What if calendar software didn’t require us to define meeting durations or end times? What if the only expectations attendees had were start times and agendas?

My hypothesis is that by removing meeting end times and thus minimum lengths, most meetings would end sooner than they otherwise would have been scheduled to.

Some meetings will run longer. Maybe those ones should have been longer in the first place. Maybe they highlight the need for increased communication between the attendees in general. Maybe they replace where there otherwise would have been multiple meetings or prevent the need for follow-up meetings.

My quick design above leaves at least a few unanswered questions.² If I was in the design crit where this was presented, I’d be asking:

• If someone else tries to schedule a meeting at the same time, does it cause a conflict?
• Should meeting attendees be shown as “busy” to other users trying to schedule conflicting meetings?
• How long should they be shown as busy for? A fixed block of time or some fuzzy time period?
• Is there a default “busy” length for meetings without fixed lengths? Can it be overridden?
• What does this look like on non-Google Calendar services users might have connected, like the iOS Calendar app?
• Can we accommodate situations when a meeting has a known minimum length but total time needed is flexible?

Nothing in product is ever as simple as it seems.³ Still, considering the amount of minutes that could be saved every day across every company using calendar software, this feels like a worthy problem to consider solving. The solution could have significant impact on productivity and, following that line, perhaps even even GDP.

If you liked this, I have more thoughts on improving meetings.