3d printed 8-bit trophy still on display in the office from our 2024 team game For remote teams, there’s always pressure to make our rare, in-person time valuable. Spending an hour of a 2-day onsite on a silly game might seem like a waste, but I’ve found that a little competition and abstract problem solving is a great way to help people connect. Every year, I plan some kind of unique, team building game for Sprout Social’s meetups. I kept that streak alive at last week’s onsite and also tried something different: a hands-on empathy exercise that put our Publishing and Mobile teams through a simulated day in the life of the social media managers we build for. ### A Quick History of our Onsite Games It all started with a scavenger hunt. While helping plan a team meetup in 2022, I decided to spend our activity budget on Cashunt’s Chicago Mad Dash experience. We all had a blast running around downtown Chicago, recording videos and taking goofy photos at landmark spots. In 2023, I organized a Spaghetti Marshmallow Challenge, where teams raced to build the tallest free-standing tower out of spaghetti, tape, and string that could hold up a marshmallow. 2024 brought a blind Lego build competition, where one “runner” per team had to study a hidden reference build and relay the instructions back to their teammates from memory. Last year was my favorite so far: an Ewok-themed catapult competition. 2022 Chicago Scavenger Hunt 2023 Spaghetti Marshmallow Challenge 2024 Blind Lego Build 2025 Ewok Catapult Challenge ### 2026 Game Theme: Dystopian Sci-fi? Series poster for Silo on Apple TV As I was trying to come up with an activity for this year’s meetup, I had a much bigger group to plan for. A recent reorg brought four teams with very little overlap together into a single product zone. At the time, I had just started Season 3 of Silo, and that seemed like a perfect theme to build from. I gave randomized teams of 4–6 individuals 30 minutes with a shared kit of cardstock, craft sticks, straws, and dominoes to build a marble run into a paper cup. As an ode to the spiral staircases in each Silo, the build had to include one full spiral (at least 360 degrees of switchbacks) and the marble couldn’t stop moving for more than three seconds or the run was disqualified. https://jasongraphix.com/wp-content/uploads/2026/09/silo-game-playtest.mp4 Video of a game play test I built before the meetup with my daughters. 3D-Printed duck Pez dispenser trophies Instead of building for speed or height, the winner was decided by how _slowly_ they could get a marble from start to the end of their track. When the build time was up, nobody could touch their machines. We walked around to each creation and the team got three marbles to roll. Unlike my tabletop play test, the room we were in had carpet and chairs, so I allowed the teams to incorporate a chair into their design. The prize for each member of the winning team was a 3D-printed trophy I created featuring a gold replica of a “red level relic” from the show, a duck Pez dispenser. Many thanks to @Botcan3d for sharing a model that I was able to build into a trophy. We ended up with six very different marble runs, but only two of them successfully carried a marble all the way to their paper cup and the winning team had a run time of about ten seconds. Everyone got into it, and worked hard together, so it was a great time! Photos from the game and the rules sheet that was in everyone’s supply bags. ### The Empathy Exercise: Feeling the Tool Hopping Friction The other meetup activity I was responsible for last week wasn’t a game so much as a simulation. Having worked on Publishing tools and Mobile apps at Sprout for many years, it’s easy to see our product problems from a builder perspective instead of through the eyes of our users. As AI continues to reshape tech and marketing, the web of tools that people are using around SaaS products is getting more complicated. Watching tasks move across our ClickUp board Regularly exposing our teams to recent user interview clips, session recordings, and other user inputs helps ensure we’re focused on the right problems, and that we understand how people use the features we build. In order to truly empathize with their needs though, I planned an activity to put ourselves in their shoes. We spent an hour LARPing as the social team for a small marketing agency, scheduling social content for eleven social profiles across six networks, for five different fictional clients. Our job was to schedule posts that were planned in a project management system called ClickUp, with assets located in Google Drive and Canva. We’ve run empathy exercises before, but never this complicated. I used Claude to generate 200+ fictional posts, collect image and video content from Pexels, and create the ClickUp tasks. I intentionally added extra chaos by including a brand guide in Google Docs that schedulers had to reference for some of the clients’ individual approval requirements and quirks. Participants claimed posts from the pool, tracked down the required assets, dealt with contradictory client feedback, and scheduled real social posts the way an actual social media manager would, one browser tab and one app switch at a time. In over 30 minutes of dedicated heads-down time, nobody scheduled more than five posts. As I had hoped, it was a gloriously frustrating experience that helped us identify some impactful improvements we could make and taught us a lot about the pain points that really matter to our users.

SkilletSched — Family meal planning synced with Google Calendar

Discover insights, trends, and stories from 40+ design team blogs. Follow along via RSS, LinkedIn, or Mastodon for a steady stream of design inspiration. 🙌 Welcome to the team!

Shared by Jason Beaird on SkilletSched.

Three years ago, I wrote a post about how our family plans meals each week on Google Calendar where I used a data export to surface and share some of our favorite weeknight dinners. Until this month, that was still our planning process. Each week, we’d drop recipes into calendar events, duplicating past meals that worked, adding new recipes that included current sale items and ingredients we needed to use up. It was simple, flexible, and it kept our weekly plan accessible everywhere. Recipes can be shared publicly from SkilletSched, and get a nice link preview when sent via text message or on social. After over 8 years of adding and duplicating recipes, I started asking myself questions that a calendar search couldn’t answer, like: * How many times have we actually cooked each meal? * Are there any old gold recipes that we made a few times and forgot about? * What can we make right now with what we already have? * Can we make grocery planning faster without scanning every recipe? * ~~How to get our middle-schoolers to eat more leafy green things?~~ What we _really_ needed was a database, and that’s what I initially set out to build when I exported our shared calendar data again and started tinkering with Claude Code. After cleaning out a lot of noise and resolving duplicates, I realized we had over 70 unique recipes, several of which we’d made over 40 times. I didn’t want to replace our calendar-based process. I wanted to _augment_ it. As I dug in and started shaping my plan for a progressive web app, I realized I was building something that any household could pick up and use. I purchased the skilletsched.com domain on April 8th and iterated my way to a lightweight, useful, and accessible application. Using my own household as the primary alpha tester, it’s already been a big time saver for managing recipes, planning weekly meals, and creating a shopping list. It also supports 2-way sync with Google Calendar (Outlook and iCal coming soon), so we can still access our meal plans anywhere our family calendar is available. My favorite part of this project has been adding features like a full-screen recipe cook view, public recipe sharing, dark/light mode theming, and even an MCP server for recipe management and meal planning in your favorite LLM. ## Time for a taste test! While it’s shaped around how our family plans, I hope that it’ll make recipe management and meal planning easier for anyone. If you already have some kind of meal planning system (or even if you don’t), I’d love for you to give SkilletSched a try and let me know what works for you, what doesn’t, and what’s missing. Bon appétit!

In the winter of 1898, a mechanical engineer named Frederick Winslow Taylor arrived at the Bethlehem Steel Company in Pennsylvania with a stopwatch and a conviction. Taylor had been thinking for years about why industrial work was so inefficient, and he believed he had found the answer: the problem was that the people who _did_ the work were also the people who _decided how to do_ it. Workers brought their own habits, their own rhythms, their own judgment. All of that variation was, in Taylor’s view, waste. His solution was to separate thinking from doing, cleanly and completely. Management would plan the work – the optimal method, the optimal pace, the correct tool for each task. Workers would execute it. He called it scientific management, and over the following decades, it became the template for how industrial organisations structured almost everything they did. Nobody planned for it to also become the template for digital product teams. But when the first agencies and studios needed a process, they borrowed from what existed. And what existed was the industrial model. Plan. Design. Produce. One phase hands off to the next. The designers design; then the engineers build. A specification travels one way, downstream, and something is produced at the other end. The only problem is that building complex digital products is nothing like shovelling pig iron more efficiently at Bethlehem Steel. Yet over a hundred and twenty years later, most of us are still running product teams on a model that was designed for a problem we don’t have. ## Two Lenses # I’ve been in the meeting where this model starts to show its seams more times than I can count – on the design side, the engineering side, and also in the middle where you can see exactly what both people mean and why they still can’t hear each other. A designer walks the team through a carefully designed flow. The layouts are balanced, the visual language holds together, and all the interactions make sense. About four screens in, however, an engineer leans back and says: “That’s going to be complicated.” The designer asks why. What follows is one of those conversations where both people are clearly smart, clearly well-intentioned, yet somehow still unable to land in the same place. The engineer explains the constraint. The designer reframes the intent. The engineer nods. But not quite in agreement – more in the way people nod when they’ve decided to resolve something later, “offline.” The meeting ends. Two weeks later, when the feature ships, it works. Technically. But something got lost between what was designed and what was built. It isn’t wrong, exactly. But it also isn’t quite right. If you’ve seen this pattern enough times, you might be tempted to call it a communication problem. I used to think that, too. Better specs, more detailed annotations, clearer handoff documentation – and the gap would close. But the gap never closed. Because it isn’t only a communication problem. It’s a mental model problem. And the distinction matters, because the fix for one is a better process, and the fix for the other is something fundamentally deeper. Designers and engineers are not only trained differently. They think about the same product through genuinely different lenses – each one invaluable, but also incomplete on its own. A designer looks at a screen and sees composition, hierarchy, and intention. They’re thinking about what a user needs to feel and understand at a particular moment. They hold the whole experience in their head as a kind of narrative: the user arrives here, notices this, does that, and feels – ideally – how the product understands them. Design is about managing perception and guiding attention through space and time. An engineer looks at the same screen and sees structure, state, logic, and constraints. They’re thinking about what happens when the data doesn’t arrive, when the user does something unexpected, when the component needs to work in a dozen different contexts simultaneously. Engineering is about managing complexity and building things that hold up under the pressure of reality. Neither lens is wrong. Both are necessary. But they produce different vocabularies, different intuitions, and – crucially – different instincts about what the right question even is. When a designer says “make it feel lighter,” they have something precise in mind: less visual weight, more breathing room, perhaps a subtle change in transition timing. When an engineer hears “make it feel lighter,” they hear an instruction with no acceptance criteria. What does _done_ look like? The designer isn’t being vague. The engineer isn’t being obstructive. They’re speaking different native languages and assuming, very often incorrectly, that they share one. ## Productive Friction # Here’s the thing, though: this tension, by itself, is not the problem. In the right conditions, it’s actually one of the most valuable assets a team has. Because designers and engineers don’t have the same blind spots. They have complementary ones. A designer optimising for perception and narrative can miss structural fragility – the interaction that feels wonderful but buckles under real-world data. An engineer optimising for robustness can miss experiential quality – the error state that handles every edge case correctly but leaves the user feeling abandoned. When those two lenses collide early enough, each one catches what the other would miss. Quality goes up because the team is running two different threat-detection systems at once. But it goes further than that. When both disciplines stay in dialogue, constraints from one domain become creative inputs for the other. Take the “make it feel lighter” conversation again: if the designer and the engineer actually sit down together, the engineer might say, “I can’t reduce the weight of that component without breaking the layout in three other places – but what if we changed the transition timing instead?” And suddenly there’s a solution that is both structurally sound and perceptually better than what the designer originally had in mind. The constraint didn’t limit the design. It redirected it somewhere more interesting. This is what working with a material feels like: the material pushes back, and the pushback makes the work better. And the negotiation itself has value. When a designer has to explain _why_ something should feel lighter – not in aesthetic terms but in terms of what the user needs to experience at that moment – the thinking gets sharper. When an engineer has to explain _why_ something is complicated – not in jargon but in terms of what the system is actually doing – the architecture gets clearer. The friction is a forcing function for clarity on both sides. As Dave Rupert recently put it, people are not friction – but friction is where good work gets its shape. Two incomplete lenses, brought together early enough and often enough, produce something richer than either would alone. A designer who learns to anticipate structural constraints starts making better decisions. An engineer who learns to see compositional intent starts building with more sensitivity. Given enough shared time and enough feedback loops, the two perspectives don’t merely coexist. They teach each other. The question is whether the process gives them that chance. ## The Fault Line # In most teams, it doesn’t. And this is where Taylor’s inheritance does its real damage. A sequential process – where design finishes before engineering begins, and a specification is the primary bridge between them – does something that is quietly destructive: it takes a manageable cognitive difference and makes it catastrophic. Not by _creating_ the tension between the two lenses, but by _removing_ every mechanism that could make that tension productive. In a sequential process, there’s no shared material to point at. No immediate feedback when a design decision collides with a technical constraint. No moment where the engineer’s question reshapes the designer’s thinking in real time, or where the designer’s intent becomes visible to the engineer before it’s cast into a deliverable. What remains is translation. And translation always loses something. And so, every time a decision falls into the space between design and engineering, it gets made by whoever happens to be closest to it at that moment. An engineer makes a spacing decision because the specification wasn’t precise enough. A designer overrides a component behaviour in a mockup without realising that it is load-bearing elsewhere in the system. A product manager resolves the disagreement by picking whichever option is faster to ship this sprint. These small, local decisions accumulate. The built product drifts from the design intent. The codebase drifts from the design system. And eventually, the team is looking at something that technically works but feels like it was assembled from parts that weren’t quite designed to fit together. Because, in a very real sense, it was. The problem isn’t that people are making bad decisions. (Although we also do that at times.) It’s that the decisions are happening in the wrong place, by people working without full context, in territory they don’t feel entirely responsible for or comfortable in. Nobody put them there deliberately. It’s just what happens naturally when two disciplines work in sequence, each doing their best with what they’ve been handed. And the conventional response – better tooling – doesn’t change this. Zeplin, Figma’s developer mode, Storybook, design tokens, and other tooling around design systems: these are genuinely useful things and I’m glad they exist. They reduce friction at the moment of transfer and provide helpful guardrails. But they make translation more efficient without questioning whether translation is the right model in the first place. The constraints that engineers understand deeply – what the browser actually does, how a component degrades at unexpected viewport sizes, what happens to the layout when real content is three times longer than the copy in the mockup, or what is now possible with the new CSS – these things still don’t flow back upstream until it’s too expensive to act on them. What teams need isn’t a better handoff process. They need fewer handoffs. And they need to address both sides of the problem: the structural process gap _and_ the cognitive perception gap. ## Working in the Material # The structural gap – the one Taylor’s model created – needs a structural fix. And the most effective one I know is also the most direct: bring design decisions into contact with the actual material as early as possible. In 2015, Frank Chimero gave a talk at Webstock called _The Web’s Grain_ and asked a question that I’ve returned to many times since: > “What would hap­pen if we stopped treat­ing the Web like a blank can­vas to paint on, and start­ed treat­ing it like a mate­r­i­al to build with?” When design decisions are made in tools that have no concept of state, of time, of viewport, of the real unpredictability of content, you stop designing for the Web. You design a fiction of the Web. And then you hand that fiction to engineers, who absorb in the process all the compromises and assumptions that were hidden inside the original fiction. Prototyping in the browser changes this – something I’ve written about at length before and which I’m more convinced of than ever. The browser isn’t only where the product ends up. It’s a place to explore ideas and test them. It’s a place to discover edge cases before they become engineering surprises. It’s a place to shape your design directly with the real material: the web platform with all its inherent flexibility and unpredictability. When design decisions are made in the medium where they’ll live, you encounter immediately what the platform supports and what it doesn’t. This is what Jeremy Keith calls declarative design – designing with the grain of the medium rather than imposing control over it. And the products that come out of this process are better for it. They’re more resilient, more accessible, more performant, because the constraints that shape those qualities were present from the start, not discovered after the fact. But here’s what prototyping alone doesn’t solve: it addresses the process gap – the lack of a shared material, the absence of feedback loops – but not fully the perception gap. You can put a designer and an engineer in front of the same browser window and they will learn from each other’s perspectives. But they will still, to some extent, see different things. The lenses don’t merge all of a sudden just because the medium is shared. For that, you need something more. ## The Artist Who Builds # In 1919, twenty-one years after Taylor arrived at Bethlehem Steel, an architect named Walter Gropius founded a school in Weimar, Germany, that was built on a deliberate refusal of everything Taylor stood for. The Bauhaus didn’t separate the person who designed something from the person who knew how to make it. There were no handoffs. Artists and craftspeople learned together, thought together, built together, each one expected to understand both the vision and the material. Gropius wrote: > “The ulti­mate goal of all art is the building!” That ideal was largely lost in the industrialised world. We got Taylor’s model instead, because we craved efficiency, and separating planning from execution looked efficient – at least on a stopwatch. But Gropius understood something Taylor didn’t: the best work happens not when thinking and doing are separated, but when they can’t be pulled apart. When the person shaping the vision also feels the resistance of the material. When understanding how something is made changes your idea of what it should be. I’ve felt this in my own work for years. When I design a layout, I’m already thinking about how the CSS will behave when the viewport narrows and what happens to the rhythm when real content replaces the placeholder text. When I write CSS, I’m not transcribing someone else’s vision – I’m making design decisions in real time, adjusting spacing and proportion and timing based on what the browser is actually showing me. These aren’t two separate activities that I switch between. They’re the same activity seen from two angles simultaneously. And the decisions I make as a result are different – and better – than the ones I’d make if I only held one lens. But it’s not only that the work gets more coherent. Working at the intersection of both disciplines also lets you see possibilities that neither one would reveal on its own. A designer who understands what CSS Grid and container queries can do will imagine layouts that a designer working only in Figma would never conceive of. An engineer who feels compositional intent will reach for a scroll-driven animation or a view transition that a pure engineering mindset wouldn’t prioritise. These aren’t better compromises. They’re ideas that couldn’t have existed without both perspectives being present at once. This is what the design engineering role actually is, at its best. Not a designer who codes or an engineer who has taste, but someone who holds both lenses at once and can think compositionally and structurally in the same moment. Someone who doesn’t translate between design and engineering for the Web because there’s nothing to translate – the understanding is native to both. When that person, a web design engineer, exists on a team, something shifts. The gap between design intent and built reality doesn’t need to be managed with better specifications or smoother handoff tools. It doesn’t form in the same way, because the decisions that would normally fall into that gap are being made by someone with context on both sides. The cognitive difference between the two disciplines – the one that’s real and valuable and never going away – finally has a place where it’s held together rather than split apart. The web design engineer is, in a very real sense, Gropius’s ideal brought to the Web. The artist who builds. The thinker who makes. The person for whom design and engineering are not sequential phases but a single, continuous act of judgment. And judgment, more than anything, is what we need. In a world where AI can increasingly handle execution – writing the boilerplate, generating the component scaffolding, shovelling the pig iron, if you will – what matters most is exactly what the sequential model suppresses: the ability to see both the composition and the constraint simultaneously, to make decisions that are aesthetically sensitive _and_ structurally sound, to develop the kind of cross-disciplinary taste that no specification can encode and no amount of tooling can automate. The interdisciplinary mind isn’t a nice-to-have anymore. It’s the capability that matters most, precisely because it’s the one machines can’t replicate. ## Who Owns This Space? # I don’t want to make this sound like a problem with a simple solution. It isn’t. Otherwise it wouldn’t persist. Organisations are complex, teams have histories, and the design-engineering relationship often carries a lot of accumulated tension. But it’s worth being honest about where that tension comes from. It comes from a structural assumption – that design and engineering are sequential activities, that one finishes before the other begins, and that what passes between them is a specification rather than a conversation. And it’s amplified by a cognitive reality – that the two disciplines are trained and see differently, and that without shared time, shared material, and shared language, those differences compound into drift. The structural problem needs a structural fix: work in the real material, prototype in the browser, make design decisions where they’ll actually live. The cognitive problem needs a different kind of fix: build shared vocabulary, learn from each other, invest in people who carry context across both worlds, create roles where design and engineering aren’t phases but perspectives held by the same mind. Ideally, you address both. The question worth asking is: in your team, who owns the space between design intent and built reality? Who is responsible for making sure that what gets designed is what gets built – and that it’s built for the actual Web, with all its variability, its real content, its real constraints, and its real humans? When you have a real answer to that – a name, a role, a shared commitment – you see the difference in the product. Fewer bugs. Better performance. Stronger accessibility. Less money wasted on rework that shouldn’t have been necessary in the first place. And, most importantly, better experiences for the people who use what you build. Taylor separated thinking from doing because he believed the separation made the work better. Gropius reunited them because he understood it made the work _whole_. On the Web, we get to choose which model we build on. The material is right there and the distance between an idea and a working thing has never been smaller. The person shaping the vision can also be the person feeling the resistance of the material. The one who imagines the layout can be the one who writes the CSS. Maybe that’s how building things for the Web was always meant to be. Design and engineering, as one. ❦ My Newsletter ## Thoughts on designing, building, and _owning_ your corner of the Web. **Own Your Web** is a newsletter about the craft and practice of making things for the Web – as a designer, developer, or both. I share what I've been reading, building, and thinking about: links, tools, books, and the occasional longer thought on the work that matters. Read & Subscribe 2,400+ readers · free · no spam ~

A few weeks ago, I wrote about how I used Claude Code to convert a deprecated Nest thermostat into a photo gallery. That post finished with a happily-ever-after ending and a video demo of the working device installed on a wall. It would have been nice to call it done and just enjoy seeing family memories on the circular screen every time I walked in the door, but I wanted to enable others to create their own mini photo frame. I started working on an installer to transform any old Gen2 Nest Thermostat into an interactive gallery. Building and actually releasing an executable installer ended up being much harder than the original proof of concept build. ## Yes, I bricked it _I’m not a doctor, but…_ My first mistake was assuming I could just package up what I’d built with Claude Code and call it done. The gallery worked great on my Nest, so how hard could it be to make that repeatable? Turns out: _pretty hard_ Most of the gallery code on the proof of concept was iterated on within the device, over SSH. While I was able to whip up an installer pretty quickly with Claude Code, it was clear with each firmware test flash that some assets were left in place from the original POC. I spent a while trying to verify that it would work with a stock thermostat and managed to send the device into a boot loop that prevented it from connecting to wifi (no more SSH access) and eventually even charging. Claude kept suggesting ways to troubleshoot, resisting my assertion that we’d fully bricked it. After a weekend of rebuilds and firmware flashes, we finally pronounced it dead. Together, we had turned a functional photo gallery into exactly what Google wanted it to be when they dropped support, a beautiful little hockey puck of ewaste. 😢 After grieving the untimely loss of my original thermostat gallery, I doubled down and replaced it with a set of two more Gen2s from eBay which I nicknamed Bender and Clank. The idea was to use Bender to get the installer working consistently, and then confirm everything worked as expected with a clean, end-to-end firmware and gallery install on Clank. > View on Threads ## Getting it right (this time) For the original gallery, I manually formatted the images to the required BGRA .raw file format myself and hosted them on an HTTP subdomain that the Nest checked for updates whenever it was activated. It did the job, but wasn’t a very approachable solution to gallery maintenance. I kept that advanced flow around, but simplified the default setup with an Electron app (based on the no longer evil installer) that handles the entire process: USB DFU flashing, image conversion, and SSH transfer. You plug in your Nest, click a few buttons, select photos, and end up with a working photo gallery. The Nest Gallery installer release is now available on GitHub for ARM-based Macs (M1 or later). It’s MIT licensed, fully open source, and you don’t have to understand anything about cross-compiling ARM binaries or NAND partitions to use it. Here’s what you get: * One-time USB flash – No need to reflash the device when you want to update photos * WiFi photo updates – Add jpg or png images via SSH transfer through the Electron app * Carousel navigation – Turn the ring to scrub through photos * Auto-advance – 10-second intervals with smooth transitions * Motion wake – The display wakes when it detects motion * Thermostat toggle – Double-click to switch back to thermostat mode if you want ## Should you actually build one? If you have a deprecated Gen 2 Nest sitting in a drawer and you’re comfortable with the possibility that you might brick it, yes. The installer makes it as straightforward as this kind of hardware hack can be, and there’s something genuinely satisfying about bringing a discarded piece of hardware back to life with a new purpose. If you don’t have a Nest but you’re curious about the code, it’s all there. Feel free to pick it apart, modify it, or use it as a jumping off point for doing something completely different. Claude Code wrote most of what’s there and I had fun keeping it on task and learning way more than I ever expected about 2010s Linux hardware. You can find the full project, installer, and source code at: https://github.com/jasongraphix/nest-gallery

Before we dive in, I should let you know that I’m a designer. I have no business hacking firmware to make devices perform jobs they were never intended for, but I do love tinkering with physical hardware. A few years ago, I wrote about building an Arduino LED strip game and followed that post up with another about a Simon clone built with arcade buttons and a 3D printed case. I’ve also taken on some Raspberry Pi projects, a few simpler Arduino builds, and some home automation. All of those were based on existing code and project plans—no compiled binaries or firmware modifications. So, yes, I was way outside my skill set and comfort zone on this project, but that’s how we learn new things, right? _Photo of my Nest booting up with the No Longer Evil firmware installed._ On October 25th, Google officially ended support for 1st and 2nd generation Nest thermostats. I’ve long been a fan of the original Nest hardware, so after replacing our gen2 with a newer smart thermostat, I decided to hang on to that beautiful hunk of e-waste. A few months later, I came across Cody Kociemba’s No Longer Evil project. It’s an open-source firmware that brings deprecated gen1 and 2 Nests back to life by redirecting the device’s traffic away from Google’s servers and providing a web interface for remote HVAC control and scheduling. While I never intended to use my old Nest as a thermostat again, I figured it might be fun to see if I could modify the custom firmware to do something interesting. Installing the NLE firmware involves putting the Nest into DFU (Device Firmware Update) mode and running an installer script over USB. That sounds complicated, but the installation process is well-documented and straightforward. As soon as I saw the NLE logo, I was curious what else I could put on that little circular screen. It’s just a 320×320 IPS display, but the pixel density certainly _looked_ like it might handle a photo reasonably well. For my first experiment, I set out to try finding the NLE logo image and replacing it with a photo. After digging around in the open source project a bit, I worried this was going to absorb more time than I was willing to spend on a silly side project. ## Diving into Claude Code This seemed like a perfect challenge to pair with Anthropic’s Claude Code on, so I re-upped to Claude Pro, opened a Terminal window, and started prompting. With the help of my handy robot assistant, I learned that the display is accessible as a standard framebuffer device at /dev/fb0, which means if you have some raw pixel data, you can just write it directly to the screen. It helped me track down where the .ppm logo file was located in the open source code, convinced me that a BGRA .raw file was a better format for displaying photos on the device, and walked me through gaining root access to upload and display a proof of concept photo that I formatted and resized down to 320px with ImageMagick. _A family photo with Makey fromMaker Faire Orlando seemed like an appropriate proof of concept._ Even though it was tiny, the photo looked great in that circular glass frame, so from there, I decided to try making it work as a photo gallery that cycled through images automatically (and yes, Tynan) allowed for manual scrubbing via ring turn. While I may have been able to figure out how to get the POC photo to display on my own, the rest wouldn’t have been possible without Claude Code. It wrote all of the gallery functionality and helped me set up Docker to compile and reflash the Nest with test builds. I worked with Claude as if I were a product manager—providing feature requirements, validating incremental changes, and giving direction when we encountered technical constraints. And boy, did we encounter some constraints. The Nest Gen 2 runs a Texas Instruments ARM Cortex-A8 processor with a Linux 2.6.37 kernel from 2011. Just figuring out how to get a turn of the ring to swipe photos across the screen took some trial and error, device crashes, and several moments where I was sure we’d permanently bricked it. The first major hurdle was convincing the Nest to give up control of the screen. A process called nlclient continuously redraws the thermostat interface, and a watchdog process prevents you from killing it without forcing a reboot. I was getting frustrated with frequent gallery flickers and crashes when Claude eventually figured out that it could use SIGSTOP to keep the watchdog process alive and prevent the Nest from redrawing. With each successful milestone, I’d remind Claude of another missing aspect of the project. Here’s a sample of what our interactions looked like: The solution to the issue Claude was working through above also required a few iterations. I wanted to be able to add and remove gallery images without having to reflash the device. To do that, I uploaded them to a folder on my site, but there was no DNS resolution, and it also couldn’t pull files over HTTPS. Instead of letting Claude write its own musl-based wget/curl service with HTTPS support, I suggested that I could set up a subdomain without an HTTPS cert to store the photos on. There were several moments like this over the course of the project, where Claude Code was spiraling through a series of Rube Goldberg solutions to the technical constraints we encountered. Sometimes I redirected, and sometimes I let it cook. I’m pretty happy with how it turned out. Here’s a summary of what we built together: * **Auto-advance gallery** – Once the Nest completes its boot sequence, it starts cycling through photos, displaying a new one every 10 seconds. * **Display sleep** – After 5 minutes of inactivity, the screen dims to conserve power. You can tap the button or turn the ring to wake it. * **Horizontal carousel** – Turn the ring and photos slide left or right in real-time, matching the feel of scrubbing through settings on the original Nest UI. * **Motion wake** – When the gallery is not active, the Nest UI is running in the background. When we detect a motion event (AKA, Farsight), we take over the display with a random image from the gallery. If no additional action is taken within 10 seconds, the display goes back to sleep. * **Snap easing** – If you stop turning the ring past the midpoint, the image slides into place with an ease-out animation. * **Lazy Loading** – I initially let the gallery cache up to 40 images (~16MB) in memory at once. While troubleshooting periodic reboots, I learned that we were exceeding the device’s 41MB RAM limit. Now, we store 7 images in memory (3 ahead and 3 before the current image), to keep the scrubbing snappy, loading additional images on demand. * **Web Update** – On each non-motion wake action, the gallery checks an online playlist file, downloads missing images, and removes photos that are no longer on the list. * **Click sound** – The Nest has a tiny piezo buzzer, so with every ring-turn photo transition, you get a satisfying little 8-bit beep. * **Gallery pause** – A double-click on the button switches between the photo gallery and the original thermostat UI. This allowed me to get into settings to check things like wifi connection and device wiring status. To mount the Nest back on a wall, I needed a power source. I learned that a standard 24VAC doorbell transformer (which I found for about $12 on Amazon) plugged into the R and C ports of the base could keep the ~~zombie thermostat~~ Nest alive. I found an ideal display location near an entry door next to the library ladder room. There’s a closet on the other side of the wall with an outlet close enough to run a cord up, through the wall, and straight into the Nest backplate for a clean look. ## The one issue I didn’t solve There’s a _tiny_ flat spot at the very top of the display (maybe 1-3 pixels) that’s visible on lighter-colored photos. You can barely see it in the video, and even the NLE logo photo above from the original firmware flash. Claude tried to convince me that it was a hardware notch, but in the white background of some of the Nest UI screens, all the pixels are lit up to form a perfect circle. I spent an embarrassing amount of time prompting and reprompting Claude to try different pixel offsets and framebuffer pan settings to round out that glitch. While nobody who checks out the gallery will ever even notice the tiny top divit, it makes my eye twitch every time, so I may eventually try again to troubleshoot it. Until then, I’m calling this project done.

I talked to the team at the National Gallery of Art, including 77-year-old curator Alison Luchs, about “rizzing up the internet with art history.”

In August, Ames and I did something we never thought we’d do – we finally bought a move-in-ready home. Since our first house renovation project in 2005, we’ve gutted kitchens, updated bathrooms, replaced fixtures, tiled, and even added on to the neglected homes we’ve purchased. While our new place is amazing, there’s one DIY project we’ve been talking about since our first walk-through. The house has a large formal dining room with 12′ ceilings, high windows, and a beautiful modern chandelier, making it a blank canvas of a space. Here’s the listing photo: There’s plenty of space between the kitchen and living room for a table already, so we didn’t need a dedicated dining room. What we wanted was a warm, inviting den for reading, homework, and board games. _Library ladder wall we built inthe pulley house._ When we saw that tall, blank wall – the one with the wooden fish in the listing photo above – we immediately thought about the built-in shelves and the rolling library ladder we installed in a loft space at our house in Decatur, Georgia (AKA, The Pulley House). I wanted a similar rolling ladder for the den, and I knew the shelf design would hinge on the ladder rail placement. Before planning anything else, I started searching for a 10′ ladder that would work with the space. All the new library ladders (and most of the used ones I could find) were very expensive, so I set up some alerts on Facebook Marketplace. I ended up finding an old Putnam rolling wood ladder for $100, including the rail. It made my Xennial heart happy that the ladder had a manufacturer date stamp of 1980 and came from the stockroom of a store in the old Lake Square Mall in Leesburg. With a ladder acquired, Ames and I started thinking about the design of the built-in. We wanted some practical, hidden storage, so we decided to go with IKEA kitchen base cabinets at the bottom. After experimenting a bit in the kitchen planner tool, we found that a set of 24″ wide cabinets flanked by 30″ drawer units was the best use of the room width. _We liked the variety of tones in the Acacia butcher block._ For the countertops, we considered engineered quartz to match the kitchen, but thought butcher block would look better in the room when paired with the wooden ladder. We first looked at IKEA’s Vrena countertop, but learned that all of IKEA’s butcher block countertops are now just veneer over MDF. For the exact same price as the Vrena, we chose a solid-wood Acacia Butcher Block from Floor & Decor. The next step was the bookshelves. We needed at least 7′ of height to give us something to attach the ladder rail brackets to. Initially, we planned to fill the wall with shelving, but didn’t want to build them from scratch, and the width of the options we found left a lot of wasted space on either side. We simplified the plan to use just 2 columns of bookshelves, leaving space in the middle for a small TV. Two sets of the standard, 31.5″ wide Billy bookcases with a height extension ended up working great. That was as far as we planned before deciding to take on all of this over our winter “break” and pulling trigger on both the Floor & Decor and IKEA orders. I picked up the countertops myself, and we had the IKEA order delivered for $59. IKEA’s delivery options have drastically improved over the last couple of years, and for that price, it was a scheduled delivery to the room. Having hauled home many kitchen cabinet orders from IKEA over the years, that was sixty bucks well-spent. Amy assembling a base cabinet and the boxes in place with butcher block installed. We started assembling cabinets at the start of Christmas week and had the entire base unit (including drawer hardware and doors) finished before Santa arrived. Even though we don’t plan to prep food on the countertop, we decided to keep it food-safe and finish it with mineral oil, which really brought out the wood’s vibrant colors. Upside Down Billy bookcases, and me nailing trim pieces onto the cabinet fronts. A couple of days after Christmas, we got started again on the bookcases, and Amy discovered a genius hack – flipping the Billys upside down. We didn’t like the 3+ inches of footer on top of the countertop, so we assembled the bookcases with top extension as usual, but turned each unit over. To make it look more built-in, we installed strips of 1×2 trim over each vertical beam, and then a 4″ strip of trim across the top. Those covered up the joint where the cabinets butted together, giving a consistent width across the cabinet fronts. To make the ~4′ space between the shelves where the TV would be mounted a focal point and to hide the TV power cord, we wanted to add a textured panel. Amy found an oak slat wall panel from Home Depot that worked perfectly. We used 4 of the 1×2 strips attached to the wall studs as furring strips to support the panel. Here it is with the trimmed panel dropped in for a test fit. At the top of the panel, we installed a decorative shelf to provide a continuous top for the built-in. That also offered a platform to nail the header trim across the top. While I was working out the trim details, Amy was prepping the ladder. It was a bit of a mess, with 45 years of stockroom grease and grime. After a good scrub with hot water and Dawn, she applied a coat of Howard Feed-N-Wax. If you have any old wooden furniture, this stuff works magic. We had a partial bottle that we’d used on a coffee table a couple of months ago, and wow, did it make that old wooden ladder look like new. Sanding and polishing the tarnished, rusty metal rails made them look great, too! I had a couple ~8′ sections of rail from the old mall and a 14.75′ wide wall to cover, so I trimmed the rails to equal widths and hammered a 3/4″ hardwood dowel into the rail to join the two sections at the center. Getting a rail exactly the width of the room into the room and attaching it to the wall was a logistical challenge. First, I predrilled the top screw holes in each of the 4 mounting brackets into the cabinets. Then, with the brackets and detached ladder rollers hung on the rail, Amy and I carefully parallel parked it through the door and into the den with Mavrie helping out as a spotter. Finally, Amy used a broom to lift one side into position, while I screwed in the other from our folding ladder. It wasn’t an elegant process, but we all let out a cheer once it was safely attached to the wall. Our fearless climber, Adelyn, testing out the ladder and the den at night with top light strip on. Once the ladder was attached to the track rollers, I used it instead of my folding ladder to finish the touch-up painting. We also securely attached the mount and TV to the wall and added a finishing touch to the top, a 32′ GE Cync Dynamic Effects Smart Light Strip, which looped perfectly around the header of the unit to add a colorful glow to the white room in the evenings. We still need to add more books and momentos to the shelves and figure out where things go in the base cabinets, but we’re really happy with how it turned out. All in, our winter break project came in at just over $3k, with most of that going to the base cabinets. Like I did with our office shed from 2020, I put together a rough budget breakdown for our Library Ladder Wall project. I didn’t include the TV and wall mount which we had and I made a bunch of trips to Ace Hardware and Home Depot over the course of the project for minor things like screws, caulk, and a quart of paint that I’m missing here, but this most of it. Item | Cost ---|--- Vintage 1980 Putnam rolling library ladder | $100 IKEA base cabinets | $2,079 Acacia Butcher Block Countertop 8ft, 2 @ $199/ea | $400 IKEA Billy bookcases with height extensions | $436 4′ x 8′ Natural Oak Decorative Slat Wall Panel | $50 1″x2″x8′ Trim Boards (vertical trim) 12 @ $4.93/ea | $59 1″x4″x12′ Trim Boards (top trim) 2 @ $14.78 | $30 12×72 Decorative Shelf (top filler shelf) | $22 Howard Cutting Board Oil | $10 Howard Feed-N-Wax | $11 GE Cync Dynamic Effects Smart Light Strip | $19 Total | $3,216

LOADMORE showcases unconventional websites for smartphones.

From auto-complete to multi-agent orchestration, AI-powered features are becoming ubiquitous, but are we designing them well? This month, we'll explore the emerging UX patt

## TeamDesign.Team Social Posts I knew as soon as I registered the teamdesign.team domain and started building the site that I wanted to automatically share new posts across several social channels. Currently, new design team stories get cross-posted to LinkedIn, Threads, Bluesky, and Mastodon. In case anyone is interested in automating posts to one or more of those channels, I thought I’d share how I set that up. Thanks to […]

Picture this: You’re in a meeting room at your tech company, and two people are having what looks like the same conversation about the same design problem. One is talking about whether the team has the right skills to tackle it. The other is diving deep into whether the solution actually solves the user’s problem. Same room, same problem, completely different lenses. Article Continues Below Article Continues Below no comments yet ### Share this:#section1 * Click to share on Bluesky (Opens in new window) Bluesky * Click to share on Mastodon (Opens in new window) Mastodon * Click to share on Threads (Opens in new window) Threads * Become a patron Build advanced skills for growing career opportunities. Choose from tracks in content strategy, UX/UI, communication with data, and learning design. A Book Apart: Brief books for people who make websites. This is the beautiful, sometimes messy reality of having both a Design Manager and a Lead Designer on the same team. And if you’re wondering how to make this work without creating confusion, overlap, or the dreaded “too many cooks” scenario, you’re asking the right question. The traditional answer has been to draw clean lines on an org chart. The Design Manager handles people, the Lead Designer handles craft. Problem solved, right? Except clean org charts are fantasy. In reality, both roles care deeply about team health, design quality, and shipping great work. The magic happens when you embrace the overlap instead of fighting it—when you start thinking of your design org as a design organism. ## **The Anatomy of a Healthy Design Team**#section2 Here’s what I’ve learned from years of being on both sides of this equation: think of your design team as a living organism. The Design Manager tends to the mind (the psychological safety, the career growth, the team dynamics). The Lead Designer tends to the body (the craft skills, the design standards, the hands-on work that ships to users). But just like mind and body aren’t completely separate systems, so, too, do these roles overlap in important ways. You can’t have a healthy person without both working in harmony. The trick is knowing where those overlaps are and how to navigate them gracefully. When we look at how healthy teams actually function, three critical systems emerge. Each requires both roles to work together, but with one taking primary responsibility for keeping that system strong. ### **The Nervous System: People & Psychology**#section3 **Primary caretaker: Design Manager**** ****Supporting role: Lead Designer** The nervous system is all about signals, feedback, and psychological safety. When this system is healthy, information flows freely, people feel safe to take risks, and the team can adapt quickly to new challenges. The Design Manager is the primary caretaker here. They’re monitoring the team’s psychological pulse, ensuring feedback loops are healthy, and creating the conditions for people to grow. They’re hosting career conversations, managing workload, and making sure no one burns out. But the Lead Designer plays a crucial supporting role. They’re providing sensory input about craft development needs, spotting when someone’s design skills are stagnating, and helping identify growth opportunities that the Design Manager might miss. **Design Manager tends to:** * Career conversations and growth planning * Team psychological safety and dynamics * Workload management and resource allocation * Performance reviews and feedback systems * Creating learning opportunities **Lead Designer supports by:** * Providing craft-specific feedback on team member development * Identifying design skill gaps and growth opportunities * Offering design mentorship and guidance * Signaling when team members are ready for more complex challenges ### **The Muscular System: Craft & Execution**#section4 **Primary caretaker: Lead Designer**** ****Supporting role: Design Manager** The muscular system is about strength, coordination, and skill development. When this system is healthy, the team can execute complex design work with precision, maintain consistent quality, and adapt their craft to new challenges. The Lead Designer is the primary caretaker here. They’re setting design standards, providing craft coaching, and ensuring that shipping work meets the quality bar. They’re the ones who can tell you if a design decision is sound or if we’re solving the right problem. But the Design Manager plays a crucial supporting role. They’re ensuring the team has the resources and support to do their best craft work, like proper nutrition and recovery time for an athlete. **Lead Designer tends to:** * Definition of design standards and system usage * Feedback on what design work meets the standard * Experience direction for the product * Design decisions and product-wide alignment * Innovation and craft advancement **Design Manager supports by:** * Ensuring design standards are understood and adopted across the team * Confirming experience direction is being followed * Supporting practices and systems that scale without bottlenecking * Facilitating design alignment across teams * Providing resources and removing obstacles to great craft work ### **The Circulatory System: Strategy & Flow**#section5 **Shared caretakers: Both Design Manager and Lead Designer** The circulatory system is about how information, decisions, and energy flow through the team. When this system is healthy, strategic direction is clear, priorities are aligned, and the team can respond quickly to new opportunities or challenges. This is where true partnership happens. Both roles are responsible for keeping the circulation strong, but they’re bringing different perspectives to the table. **Lead Designer contributes:** * User needs are met by the product * Overall product quality and experience * Strategic design initiatives * Research-based user needs for each initiative **Design Manager contributes:** * Communication to team and stakeholders * Stakeholder management and alignment * Cross-functional team accountability * Strategic business initiatives **Both collaborate on:** * Co-creation of strategy with leadership * Team goals and prioritization approach * Organizational structure decisions * Success measures and frameworks ## **Keeping the Organism Healthy**#section6 The key to making this partnership sing is understanding that all three systems need to work together. A team with great craft skills but poor psychological safety will burn out. A team with great culture but weak craft execution will ship mediocre work. A team with both but poor strategic circulation will work hard on the wrong things. ### **Be Explicit About Which System You’re Tending**#section7 When you’re in a meeting about a design problem, it helps to acknowledge which system you’re primarily focused on. “I’m thinking about this from a team capacity perspective” (nervous system) or “I’m looking at this through the lens of user needs” (muscular system) gives everyone context for your input. This isn’t about staying in your lane. It’s about being transparent as to which lens you’re using, so the other person knows how to best add their perspective. ### **Create Healthy Feedback Loops**#section8 The most successful partnerships I’ve seen establish clear feedback loops between the systems: **Nervous system signals to muscular system:** “The team is struggling with confidence in their design skills” → Lead Designer provides more craft coaching and clearer standards. **Muscular system signals to nervous system:** “The team’s craft skills are advancing faster than their project complexity” → Design Manager finds more challenging growth opportunities. **Both systems signal to circulatory system:** “We’re seeing patterns in team health and craft development that suggest we need to adjust our strategic priorities.” ### **Handle Handoffs Gracefully**#section9 The most critical moments in this partnership are when something moves from one system to another. This might be when a design standard (muscular system) needs to be rolled out across the team (nervous system), or when a strategic initiative (circulatory system) needs specific craft execution (muscular system). Make these transitions explicit. “I’ve defined the new component standards. Can you help me think through how to get the team up to speed?” or “We’ve agreed on this strategic direction. I’m going to focus on the specific user experience approach from here.” ### **Stay Curious, Not Territorial**#section10 The Design Manager who never thinks about craft, or the Lead Designer who never considers team dynamics, is like a doctor who only looks at one body system. Great design leadership requires both people to care about the whole organism, even when they’re not the primary caretaker. This means asking questions rather than making assumptions. “What do you think about the team’s craft development in this area?” or “How do you see this impacting team morale and workload?” keeps both perspectives active in every decision. ## **When the Organism Gets Sick**#section11 Even with clear roles, this partnership can go sideways. Here are the most common failure modes I’ve seen: ### **System Isolation**#section12 The Design Manager focuses only on the nervous system and ignores craft development. The Lead Designer focuses only on the muscular system and ignores team dynamics. Both people retreat to their comfort zones and stop collaborating. **The symptoms:** Team members get mixed messages, work quality suffers, morale drops. **The treatment:** Reconnect around shared outcomes. What are you both trying to achieve? Usually it’s great design work that ships on time from a healthy team. Figure out how both systems serve that goal. ### **Poor Circulation**#section13 Strategic direction is unclear, priorities keep shifting, and neither role is taking responsibility for keeping information flowing. **The symptoms:** Team members are confused about priorities, work gets duplicated or dropped, deadlines are missed. **The treatment:** Explicitly assign responsibility for circulation. Who’s communicating what to whom? How often? What’s the feedback loop? ### **Autoimmune Response**#section14 One person feels threatened by the other’s expertise. The Design Manager thinks the Lead Designer is undermining their authority. The Lead Designer thinks the Design Manager doesn’t understand craft. **The symptoms:** Defensive behavior, territorial disputes, team members caught in the middle. **The treatment:** Remember that you’re both caretakers of the same organism. When one system fails, the whole team suffers. When both systems are healthy, the team thrives. ## **The Payoff**#section15 Yes, this model requires more communication. Yes, it requires both people to be secure enough to share responsibility for team health. But the payoff is worth it: better decisions, stronger teams, and design work that’s both excellent and sustainable. When both roles are healthy and working well together, you get the best of both worlds: deep craft expertise and strong people leadership. When one person is out sick, on vacation, or overwhelmed, the other can help maintain the team’s health. When a decision requires both the people perspective and the craft perspective, you’ve got both right there in the room. Most importantly, the framework scales. As your team grows, you can apply the same system thinking to new challenges. Need to launch a design system? Lead Designer tends to the muscular system (standards and implementation), Design Manager tends to the nervous system (team adoption and change management), and both tend to circulation (communication and stakeholder alignment). ## **The Bottom Line**#section16 The relationship between a Design Manager and Lead Designer isn’t about dividing territories. It’s about multiplying impact. When both roles understand they’re tending to different aspects of the same healthy organism, magic happens. The mind and body work together. The team gets both the strategic thinking and the craft excellence they need. And most importantly, the work that ships to users benefits from both perspectives. So the next time you’re in that meeting room, wondering why two people are talking about the same problem from different angles, remember: you’re watching shared leadership in action. And if it’s working well, both the mind and body of your design team are getting stronger. ### Like this:#section17 Like Loading... ### Further reading about Business ### From Beta to Bedrock: Build Products that Stick. “The best way to predict the future is to create it.” ### How to Get a Dysfunctional Team Back on Track Everyone’s a good manager when their team is functioning perfectly. But what do you do when your team screws up? Liam Nugent tells how to face reality when work goes poorly, and shares practical steps to get your team back on track.

AI is killing product-led SaaS. The future is outcome-driven, agentic services that deliver results, not tools. All heil Service-as-a-Service.