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
I haven’t driven a car in decades (New Yorker). But from my pre-New York life, I remember how sun glare could turn a pleasant road trip into a blinding gauntlet. Enter “Sunward,” a uniquely specific demo app my Automattic colleague Peter Westwood just whipped up in Spacefast. Spacefast – for your next idea Sunward – demo app Peter Westwood – software engineer & engineering director Automattic – my work home P.S. Apologies for layout wonkiness. Trying something new. The post Better Day, Sunshine appeared first on Jeffrey Zeldman Presents.
A decade ago, working at a design agency, I lived in fear of one sentence: “this looks nice, can we see a few other options?” I was not an ‘options’ guy. I fashioned myself as Paul Rand, telling Steve Jobs off when he asked for multiple options: “No. I will solve your problem for you and you will pay me. You don’t have to use the solution. If you want options, go talk to other people.”1 But I didn’t have the guts to tell my clients off, so I dutifully designed a few other options.2 Recently, I’ve gotten to work with some of the best designers in the field. Looking at their digital workspace — in Figma, Paper, Claude Design, or something else — I see hundreds of artboards and variants, laid out in a sprawling grid, representing branching parallel universes of design directions. Sometimes I see little panels filled with dials to sweep through the possibilities, enabling a single person to see thousands of combinations in the hope of picking a single, perfect specimen. Lots and lots of options. This makes me feel like an alien. My files are just a few artboards; sure, I tweak and tune the tiny details inside, but I rarely keep the multiverse in view as I do. I’ll give myself a dial here and there, but usually for a single variable that I can’t easily visualize. Am I just a bad designer? Assuming (hoping) the answer is ‘no’, I want to revisit a thread I pull on from time to time: as designers, we’re all just trying to find the right solution in a vast multiverse of possibilities. The solution exists, and we typically know it when we see it. So most of what we call ‘design’ is groping around a dark room looking for a black cat. Different designers take different approaches. Some are changing their approaches with the advent of generative AI, but at the end of the day, design is a search problem. Computer science has worked on search problems for decades. Depending on the particularities of a given search, there are a variety of algorithms and strategies that can result in faster, more direct, or more computationally efficient paths to the solution. We can apply this wealth of research from some of my favorite scientists (looking at you, Claude Shannon) to the design process, to hone our own craft. ‘Search’ has its own formal vocabulary in computer science. I’ve put a glossary at the bottom of the post, and I’ll use dotted underline to link to a definition if you need it. To picture how a search works, imagine a Rubik’s cube. A scrambled cube is the starting state; each turn you can make is a state change, leading to an adjacent state. All the possible combinations of colors on the faces (43 quintillion for a typical 3×3 Rubik’s cube) make up the search space. Searching involves evaluating candidates that can be reached from the current state of the cube; the desired state is the solved cube with each face a solid color. Each possible version of the cube is a state. Each turn is a change that leads to an adjacent state. Now, a few basic search algorithms and how they apply to design: Depth-first search As far as search algorithms go, depth-first search (DFS) is as simple as it gets. Here’s how it works: From the current state, look for adjacent states we haven’t visited. If there is one, move to it. It doesn’t matter which. If there isn’t, go back to the previous state and start from step 1. Repeat until we reach the goal or run out of states. Depth-first search commits to the first change it finds and follows that all the way down before it backs up. Solutions evaluated: 16 In a design sense, this is akin to navigating a hedge maze by picking a random direction at each fork until you hit a dead end. It’s not a very good design process, but it’s a good intro to how these things work. Breadth-first search Breadth-first search (BFS) is just a touch more complicated, and starts looking more like the design process. From the starting state, visit every adjacent state. From each of those, visit every adjacent state we haven’t visited. Keep going, moving one step further from the start each round. Repeat until we reach the goal or run out of states. Breadth-first search tries every single change, then every pair of changes, and so on. Solutions evaluated: 21 Both DFS and BFS are naive algorithms; we don’t proactively evaluate candidates while we search. Both are used on search problems with small search spaces and/or when evaluation is cheap. But many of the most interesting search problems aren’t small or cheap. Take chess, for example; winning at chess is a search problem. But the search space is unfathomably large,3 which is why it wasn’t until the mid-2000s that computers could reliably beat grandmasters. Most product design problems I’ve worked on look more like chess than a Rubik’s cube. Design covers search spaces of hundreds of dimensions — sizing, spacing, hierarchy, color, motion, interactivity, responsiveness, etc. And evaluation is relatively expensive: beyond changing a button or color, we often need to ship something before we truly know it works. There are other algorithms meant for this kind of problem, and they resemble design more and more as they get more complex. Beam search Beam search is the first approach we’ll explore that actually evaluates potential candidates before moving. From the starting state, score every adjacent state. Keep the three best and discard the rest. Score every state adjacent to the three we kept, and again keep only the three best. Repeat until one of the states we kept is the goal, or we run out of states. Beam search scores each option by how many parameters still look wrong, keeping the best three each round. Solutions evaluated: 21 This is called ‘beam search’ because it’s like using a flashlight’s beam to look at new states; the width of the ‘beam’ above is 3. Beam search is the ‘show me some options’ approach that most of my agency work took. It’s limited by the width of the beam: a narrower beam is faster and cheaper, but may miss the best solution at a given step. Now is an important moment to introduce the idea of a heuristic. In most cases, we don’t know we have the ideal candidate until we find it. Given that inescapable fact, we have to pick a test that we think will separate the good candidates from the bad ones. Heuristics usually involve tradeoffs: they can be fast/cheap and error-prone, or slow/expensive and accurate. Here’s the problem: beam search often fails to find the best solution! It depends entirely on the width of your beam and the quality of your heuristic. For example, if the desired state is hiding behind a low-scoring upstream branch, the algorithm might never find it. This can be overcome with an infinite beam, but then we’re just back at a slightly fancier BFS, which is slow and inefficient. When I learned the shortcomings of beam search — that simply checking a few options and picking the best one might not lead to the best solution — my feelings about my option-hungry clients were validated. And yet, designers are still using the beam, because AI has given us a better flashlight: producing a handful of options for a SaaS website used to take a week, and now it takes seconds. The beam has gotten so wide that ‘give me 10 options’ feels like an effective way to prompt AI towards the best design. Still, it’s not how I design. And again assuming I’m not just in the permanent design underclass, I thought maybe there was another algorithm that explains why I tend to explore so few branching paths. A* A* (A-star) is the algorithm behind most route-finding, from maps apps to video game characters. From the starting state, give every adjacent state a score, made up of: The number of changes it took to get there from the start, plus The heuristic: our estimate of how many changes remain to reach the goal. Put them all on a list of states we could visit next. Move to the state on the list with the lowest score. This might not be adjacent to our current state! Score the new state’s adjacent states and add them to the list. Repeat until we’re at the goal. A* scores each possibility as changes made so far plus its estimate of changes left. Partway through, it’s able to revisit previous candidates. Solutions evaluated: 14 This is similar to beam search, but with a few twists: A*’s heuristic incorporates a notion of distance from the goal. A* doesn’t always move smoothly from adjacent state to adjacent state. That last bit is crucial: unlike beam search, A* can go backwards. If the path we’re on moves far from the goal, its score climbs. Eventually a previous candidate looks better and we go back to it. More importantly, how much exploring we do in A* depends almost entirely on the quality of our heuristic. With a perfect estimate, A* goes straight to the solution. A* matches how I design. I’m more deliberate with exploration, only following thoughts until I feel they’re drifting away from the solution. I typically only keep old explorations around if they’re promising; an exhaustive record of every possible variant is stressful. I’ve managed to go the whole essay without mentioning it, but with my A* approach, taste4 does in fact matter; while there are many designers with better taste than I have, what I do have is hard-won by years of designing, and I can use it to sniff out the fastest path to the best solution. Conclusion AI has given us a wider beam, but it hasn’t yet given us a better heuristic. We’re still designing for humans, so we still have a leg up on the robots: we can use empathy, or even our own biases and human shortcomings, to feel out the right solution. Meanwhile, understanding the design process is just as important as ever. This kind of introspection — learning about search algorithms out of despair over my own shortcomings — has added a few tools to my arsenal. There are many variations on these algorithms that may describe your own search process; there are even more exotic variants that may be worth trying on. It might seem reductive to call design a search problem. Where’s the creativity? But with humanity, humility, and curiosity, pursuing the optimal solution with a well-tuned algorithm can help us design faster and more efficiently. Special thanks to Josh Petersel for feedback on a draft of this essay. Definitions Adjacent Two states are adjacent when they’re separated by a single state change. ↩︎ Candidate A state we’re considering. ↩︎ Distance The number of changes that turn one state into another. Usually we measure distance as the least number of changes required to get from one state to another. ↩︎ Heuristic A test we think will separate the good candidates from the bad ones, used because we usually can’t know we have the ideal candidate until we find it. Heuristics involve tradeoffs: they can be fast and cheap but error-prone, or slow and expensive but accurate. ↩︎ Search The process of arriving at a desired state (scoring well on a fixed set of criteria) by evaluating a set of candidates. ↩︎ Search space The set of possible states. We call it a ‘space’ because often there are ‘dimensions’ to search, like the width and height of a shape, and we can make analogies to the dimensions of a physical space. Sometimes these dimensions are literal, as when a wayfinding app picks the best route from point A to point B. ↩︎ State A possible step in the movement from the beginning of a search to the end. We start with the ‘initial state’; as we evaluate candidates we might change our ‘current state’; the end of the process is the ‘final state’ (and may not be the ‘desired state’). ↩︎ State change Also called a mutation. How the system moves between states. ↩︎ Footnotes & References As recounted by Steve Jobs in “Steve Jobs interview about working with Paul Rand,” 1993. ↩︎ The client almost always picked the original (or at least the classic ‘let’s do A with a bit of B and C’). ↩︎ Claude Shannon estimated it at 10¹²⁰. For comparison, the observable universe has about 10⁸⁰ atoms. ↩︎ Say the line, Bart! ↩︎
