Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Luke Mitchell | Product Designer
I have an email address that you’ll find in the footer below this post, I rarely get emails to it, the ones I do get fall into two categories: very, very kind people paying compliments to me about this website; secondly some sort of cold email, usually from a SEO expert explaining that my SEO is shit. Like Eric I am often tempted to email back and see what they would do if I took them up on the offer. The other day I got a cold email that stuck out, here’s what it said: hey luke, this is an out-of-the-blue email but i’m writing on behalf of the small team behind ruks.org: we’ve been (manually!) compiling a big database of design + creative individuals and firms who we think are awesome. if you’re reading this email, that means at some point and somehow, we came across your portfolio and/or your work. (manually. no web scrapers.) for context, ruks.org is just a nice, short domain that we bought a while back, but we’ve decided it stands for the “[r]esource of [u]n[k]nown [s]pecialists.” that is to say, it’s a database of creative talent. we are not venture-backed, and the platform is currently free. it’s a side project of family office, a design studio based in new york. long story short, our spreadsheet of portfolios we had saved got a little unwieldy, and we figured it’d be nice to make the resource public. our hope that it can help route opportunities for work to the inboxes of great creative talent. you can click here to make an account and take a look at your profile. if you would like to correct your profile or would like to recommend that any other creatives be added, please let us know. you can respond directly to this email since this is a manually sent note. all the best, annie swanson at ruks.org + family office What have I just learned? I have been added to a database of other creative people The database has been hand-crafted It was hand-crafted by a small team It was built to offer a resource to the wider community It is currently free, probably not always It does not need to be profitable because it has no outside funding It is called ‘ruks’ The name has a fun back-story It was originally an internal tool used by the small team I can take a look at the entry they’ve created for me This email was sent manually, by Annie I can reply to this email because it was sent manually by Annie The small team is called Family Office Family Office is based in New York And so on… Isn’t that nice? It’s a cold email from a real person, at a real company, in a real place, who have built a real thing, that has a real use. In those four paragraphs I have learned so much, it answered every question and settled every doubt I had in real time while I was reading it. It gives me some decent, optional action items, and it gives me an easy way to ask more questions. It’s very sad that this seems so original and refreshing to me. But let’s not dwell too much on that feeling. Go check out ruks, I’m in it. Thanks Annie.
I was reading Manu’s post about ‘old tech’ and suddenly thought, markdown is really, really good. What is it? Markdown is a markup (get it?) language which aims to make formatting text as easy as possible, while still being easy to read. Markdown can be processed into HTML, which is what the web is made of. It was created by John Gruber and Aaron Schwartz, and released over 20 years ago. It is commonly found in blogging software, content management systems, software documentation, and many other places. This post that you’re reading right now is written in markdown. Most alternatives to markdown are what I call ‘rich text’, which vary quite a bit in how they work, they are often more complex and proprietary. Here’s why I think that markdown is really, really good. You write it Markdown is for writing, and it’s designed to be written. You don’t need to memorise an interface to use markdown, you need to remember a syntax instead, and you can use that same syntax everywhere that you write markdown. In markdown to write add a link to a webpage you type a ‘[‘ followed by the link text, if you’re really lucky whatever you’re typing into is smart enough to close that square bracket for you, then you type a ‘(‘ followed by the URL. Notice you never had to stop typing to add this link, this process is exactly the same wherever you are writing markdown, there is no keyboard shortcuts or special interface to remember. In ‘rich text’ world you would need to stop typing and do a few things. You might need to type your link text then highlight it, then find then whichever button that you need to convert it to a link, then you may need to use whichever interface this particular app uses to add the link for you, they vary wildly. It’s HTML Markdown makes HTML, perfectly standard HTML that any web browser can understand, every single thing that you write with markdown becomes HTML, just like the HTML that you are reading right now. Sadly in the ‘rich text’ world you can never really be sure what you’re going to get. Sometimes your web browser will receive a very sad knotty mess of spaghetti code, that creates all sort of problems, and bugs. You can take it with you Markdown files are plain text files, you don’t need a special app to open or edit them. Markdown by itself has no interface but they are plenty of great apps that can wrap it in one if you like. Markdown files are also tiny, they don’t come bundled with a bunch of proprietary metadata that a specific app needs to understand the file. This makes markdown very portable. You can also copy and paste markdown between different markdown friendly places and nothing bad will happen. I find it very annoying that when I copy text from one ‘rich text’ editor to say, Google Docs nothing is formatted right, so I have to do it all again. You can hack it There are many, many plugins, add-on’s and other ways to add features to markdown. There are plugins out there that will automatically generate a table of contents based on the headings that you write, and plugins that allow you to write and generate footnotes, there’s a world of possibilities. If you want something really specific you can write your own plugin, and something completely custom to markdown if you want. Markdown may be old but I think it’s the best way to write. Markdown is for writing, it makes great HTML, it’s portable, and it’s customisable.
This post originally appeared on thoughtbot.com I was browsing an online marketplace the other day because I was a bit bored, and because I have a unique need to seek out dark patterns. Something caught my eye as I scrolled. Amongst all the other suspiciously cheap items, was a bag for a chicken. Not a bag with a chicken pattern, not a bag shaped like a chicken, no — a bag to carry a chicken. A living chicken. A bag for carrying a chicken. It made me smile as I took a screenshot. After 30 seconds, I went back to scrolling with a blank expression. It wasn’t over. I kept thinking about this thing for days afterward. All I had were questions: Why does this product exist? Why does a chicken need to be carried in a chicken-carrying bag? Where is the chicken going in the chicken-carrying bag? Who is this chicken-carrying bag for? How many chickens does this chicken toting person own? In the absence of the chicken-carrying bag, how do they carry their chicken(s)? How many chicken-carrying bags have been sold so far? How many chicken-carrying bags need to be sold to break even on the initial investment? Who came up with the idea for the chicken-carrying bag? Do they have any first-hand experience with chicken carrying? How do you get the chicken into the chicken-carrying bag? Did the chicken-carrying bag manufacturer test the usability of the chicken-carrying bag? How else did they test the chicken-carrying bag? When did the chicken-carrying bag manufacturer consider the chicken-carrying bag good enough to sell? How did they decide on the fabric to use for the chicken-carrying bag? What does the next version of the chicken-carrying bag look like? How will the chicken-carrying bag manufacturer find out the highest-priority feature to add next? How do I get to a place in my life where my singular focus is improving my chicken-carrying experience? The list is endless… What does this have to do with design? Next time you’re struggling to come up with a question to find out more about something — be it a design problem, a new product pitched by a budding founder, or even another bizarre (to you) product you’ve found online — think of this chicken-carrying bag. You will have plenty. Alternative titles for this post: Why Did the Chicken Cross the Road in a Bag? This £5.17 Item Revolutionised My EDC For Sale: Chicken Bag, Never Worn (OK, one more question, is the chicken wearing the bag?) 5 Chicken Accessory Trends for 2025
I often use the analogy that when we design for print, what are we doing over and over again? Doing proof prints. Why then when designing websites (or apps) are we not getting in to the browser as quickly as possible, rather than creating interactive pictures of websites in Figma? This is where you can stand out as a designer by learning to code. I’m not talking about writing production code with developers here. Hell, maybe in the future, but I’m talking getting a good understanding of How Things Work™ and using that knowledge to blast your web and app design skills into the stratosphere. Andy’s post is an excellent guide and list of resources, it’s also one of the best summaries of why you should at least understand how the things you build for work, and some very good reasons to learn to code as a designer, it’s an ancient argument but in 2024 it might just make you stand out enough when some of our work can be spat out in 30 seconds by AI. With design tools further commoditising and sanitising expected creative output, the time for designers to be able to stand out is very much here. I think for some, learning to code is a good route for that. Please give this a try if you’re a new (or not so new) designer.
I have been collecting bookmarks for quite a while, as you read this there are 1052 of them, which shocks me, they really build up fast. What I haven’t done yet is explain how I collect them and how they end up on this site. Ethos Describing my ethos properly is probably another post by itself, but if I find something delightful, engaging, interesting, beautiful or useful it will probably make it into my list. One rule that I do have is that I can only add something to the list once, which can be a bit limiting if somebody does a great redesign of their website. Sources I have a few places that I find my bookmarks, the best one being the many RSS feeds that I am subscribed to. My favourites are: Things to click SC 2.4.4 Sidebar Meanwhile I often browse a few websites that I have saved as Safari bookmarks. Some of my favourites are: Typewolf Minimal Gallery Collosal Savee It’s Nice That I also find a few of my bookmarks by scrolling Mastodon, and sometimes my lovely coworkers will share something in Slack that I find interesting too. Sometimes I even just stumble upon things by myself, if you can believe it. Method I usually spend a Sunday morning browsing through all my feeds, websites and accounts to find new links to bookmark, it’s a bit like reading the Sunday newspaper. I use my trusty iPad to do this. Once I find a link to bookmark I will store it in Drafts to work on later. I will also keep note of the place I found the link, so that I can credit them. When I next find time and I’m working at my desk I will sort through my links in Drafts and begin adding them into my extra-special-custom-made CMS. The first step is to open the Raycast extension I built, it allows me to enter all the bookmark details and save them to a database as a draft, to be edited or published later. A few notes on the extension: I can grab the current Safari tab URL and title by tapping a keyboard shortcut, which saves on copy-pasting. If I check ‘url as title’ the extension will crunch the URL into a nicer format: https://www.example.com becomes example.com. It will save the form as a draft if I need to do something else in the background. Later I can open the other Raycast command which I use to manage the bookmarks, and publish them. In the screenshot below you see that it displays all the saved content with handy indicators for unpublished bookmarks. From here I can tap a keyboard shortcut to publish or delete the drafts as needed. Once published the new bookmarks will appear on the bookmarks page the next day – I publish my website every morning, automatically. Back-end The bookmarks system backend is a simple app written using Hono, which is a more modern equivalent to Express (which is how the first version was built). It makes it easy to write a CRUD style API to list, create, edit, and delete bookmarks. The API is hosted on cloudflare as a serverless worker. For a database the bookmarks system uses cloudflare D1, which is a nice wrapper around SQLite. Front-end As I’ve shown above I add, publish, and edit bookmarks using Raycast. This website is built with Eleventy, my favourite way to build a website. Eleventy makes it easy to grab the bookmarks data, adding a JavaScript file to the data folder that exports an object is all that is needed. Once the data is fetched I then display the bookmarks using a Nunjucks template for the markup. No client side JavaScript is exported, just plain HTML. That’s pretty much it. That’s my DIY approach to collecting links a putting them on this website. You can browse all the bookmarks at /bookmarks, you can also find the RSS, and JSON feed to subscribe to them on that page too.
More in design
If you work in software (as a designer, developer, PM, or any adjacent role), you’re probably aware of just how much AI has changed the way code is created. And if you’re an engineer, you’re definitely feeling the downstream impacts of AI’s speed. Way, way more code is being written. But the way we review code hasn’t changed that much. But if you’re not familiar, code review is a step in the software development process where developers look at code before it gets shipped. It’s been a cornerstone of engineering teams’ workflows for almost as long as there have been engineering teams. AI coding has turned code review into a bottleneck; a human can only look at so much code, so reviews have started taking longer, and each engineer’s review backlog is growing exponentially.1 AI code review tools have stepped into the breach, eliciting an earnest grumble from developers: AI reviewing AI-written code is like a student grading their own test. Execs don’t have much sympathy, though. We can move faster, so we should. So teams are stuck in a traffic jam, trying to figure out how to review code faster, without sacrificing quality. I’d like to argue that the source of this problem is more fundamental than speed vs. quality. We’re in this situation because somewhere along the way we swapped one question for another. Code review was always meant as a verification step: does the code produce the outcome we want? But it’s a hard question to answer, so we started asking an easier one instead: is this good code? Let’s go back to the original question. Code review should get better at verifying outcomes — faster, yes, but more accurately, and for the system as a whole, not just single lines of code. What is code worth? The premise of code review is that code can be good or bad, and that bad code can be turned into good code, and that good code is important. This is a sound premise. Bugs are obviously bad for business. But we’ve made an attribute substitution: we decide whether code looks good as a stand-in for whether the software works. Engineers use mental shortcuts to determine the goodness or badness of code. They range from very well-documented patterns (use guard clauses to return early, use pure functions where possible) to vibe-based ‘code smells’ (magic numbers, deep nesting). But these aren’t written in stone. They are debated and re-evaluated constantly. Even if there are inviolable definitions of good code, writing good code isn’t guaranteed to result in valuable software products. Sometimes, it works out that way; before Facebook bought it, WhatsApp kept its codebase lean enough that 35 engineers could serve 450 million users.2 But there are far, far more examples of software succeeding despite being written poorly: Undertale would never have passed a single code review (almost all of its dialog was one giant switch statement), but became one of the most beloved games of the past decade. Good code does not strictly equal good software. Code itself has no intrinsic value. So what are we actually reviewing when we review code? Verifying There’s just no substitute for actually running the code and verifying that it does its job well. I don’t mean unit tests, or even integration tests, but running the code in total, a full end-to-end test. Doing this at scale for large applications is difficult. At an org with hundreds of AI-enabled engineers, you likely have thousands of pull requests a day. Spinning up and breaking down complete copies of your entire application (likely, application cluster) is time- and resource-intensive. Even if you do manage it, verifying under realistic conditions may be completely infeasible (imagine simulating the activity that Stripe handles — 1.75% of global GDP). Which is to say that you won’t know if your code works or not until it’s in users’ hands. Traditional code review has two outcomes: You are confident enough that the code works well enough to ship it You are not confident enough that the code works well enough to ship it Verifying your code under the most realistic scenario possible (i.e., yolo, straight to production) has three: You are sure the code works, and it’s already shipped. Good job! You are sure the code doesn’t work, so you improve the code until it works You don’t know because the system failed in an interesting way. Instead of confidence, you have information, and can use it to improve the system. Verifying a major change by shipping it is risky, but the closer you can get to it, the more your review is actually worth. Feature flags, canary releases, observability and CI/CD — the stuff of modern devops — have all been commoditized to the point where it’s cheap to build in the safeguards that make the yolo approach tractable (even at Stripe scale). Stop reviewing code3 You’re probably doing code review for the wrong reasons. Let AI do the work of making code better: tracing code paths, finding, and fixing obvious issues. And if it’s a student grading their own test, so what? AI can make the code better. People can check if it works. Invest in the tools to verify your code in realistic conditions, deploying it directly to users if possible. Use your own eyes and brain to see it working, or see it not working. Learn from the difference, share what you learn with your team, and build feedback loops that improve the system the more it fails. And eventually the failures will become rare and incredibly interesting. Footnotes & References GitHub saw 1 billion commits in all of 2025; by April 2026 it was seeing 275 million a week. ↩︎ Cade Metz, “Why WhatsApp Only Needs 50 Engineers for Its 900M Users,” Wired, September 15, 2015. ↩︎ Of course, there are situations where safety means protecting human lives or massive economic outcomes, and reviewing code is the only safe option. The IRS shouldn’t ship updates to the code it uses to disburse tax refunds without reviewing the code. Waymo shouldn’t ship updates to its self-driving cars’ algorithms without reviewing the code. But you probably aren’t working for the IRS or Waymo. And if you are, get in touch ;) ↩︎
If you think about it, there is *a lot* of software that hasn’t been built across hundreds of industries because our best paid designers and engineers were occupied with building social networks and ad networks. "The best minds of my generation are thinking about how to make
Weekly curated resources for designers — thinkers and makers.
“Side Two” LP in progress. At 14 songs, it is nearly complete. I expect to release it before the year’s end. The post Another Saturday, Another Song. appeared first on Jeffrey Zeldman Presents.
Asking users to watch AI carefully is doomed to failure | Adaptive authoring of content that changes depending on the reader | A cluttered experience kills user focus | To predict patients’ treatment preferences, discussing medical dilemmas beat both survey responses and the patients’ own spouses | Measure outcomes, not vanity metrics | User satisfaction depends on expectations | Spotlight the main features and keep specialized options backstage | Allow users to paste passwords | Ambient AI works in the background to proactively surface relevant information during meetings | Writers don’t know what to ask, so AI should speak first, softly | Information pollution: cheap to publish, expensive to read | Give users bigger images when they want to zoom to see details | Past work must have a name so it can be found
