Saved

The useful thing about defining good design as a form-context fit is that it tells you where you will find the form. The form is in the context. To find a good relationship, you do not start by saying, “I want a relationship that looks like this”—that would be starting in the wrong end, by defining form. Instead you say, “I’m just going to pay attention to what happens when I hang out with various people and iterate toward something that feels alive”—you start from the context.

The context is smarter than you. It holds more nuance and information than you can fit in your head. Collaborate with it.

If you want to find a good design—be that the design of a house or an essay, a career or a marriage—what you want is some process that allows you to extract information from the context, and bake it into the form. That is what unfolding is.

The opposite of an unfolding is a vision. A vision springs, not from a careful understanding of a context, but from a fantasy

Anything that increases the rate and resolution of information you get from the context will help. And anything that makes it easier for you to act on the context.

A common reason we filter information and become blind to the context is that we bundle things when we think. Thinking about our career, we might think in abstractions like “a job.” But really a career is made up of a bunch of different things like a salary, an identity, relationships, status, a sense of meaning, and so on. It is often easier to find a fit if you unbundle these things, and think about the parts that matter to you individually. Do you actually need more status? Or can you find a better fit if you go low status?

Another common reason the feedback loop of unfolding often works poorly is that people have decided on a solution already. They have turned on their confirmation bias. They have decided that a certain solution is off-limits. Let’s say you are 34 and haven’t found a partner but want kids. If we unbundle this, it is clear that the problem of having a kid and the problem of love are not the same thing, so you could solve your problem by having a kid with your best friend instead. But this feels weird. It is not the vision you have for your life. And it seems dysfunctional. Observe that feeling—it is, perhaps, a part of the context. There is some information there. But to unfold, do not write off any solutions. Leave them all on the table; let them combine and recombine. Many good ideas look bad at first. To increase the rate at which you understand the context, you want to develop a certain detachment. When the context thrashes one of your ideas, you want to say, “Oh, that’s interesting.” It takes practice. But it is worth getting better at. Reality is shy—it only reveals itself to those who, like honest scientists, do not wish it to be something else.

The faster you can collide your ideas against reality, the faster you get feedback.

The school system is centered around visions, not unfolding. You are asked to make decisions about realities that are five, ten years down the line, and you get no feedback on your decisions.

you’re less torn by anxious attachments when you recognize how something must naturally and necessarily unfold.

Knowledge is freedom from getting mad at facts.

Detachment does not mean you don’t care what happens. It just means you don’t care whether a specific thing happens or not. You want to know the outcome of the coin-toss (you care), but you don’t care whether it is heads or tails even if you’ve bet on heads (you’re not attached to a specific outcome). The important thing is that something happens, which means you’ve successfully kept play going, but without keeping score.

Emotional Self-Management: I like to think of this as accepting the emotions you have instead of having emotions about having emotions in an endless stack.

Fear. Not fear, plus anxiety about fear, plus guilt about anxiety about fear, plus shame about displaying guilt about experiencing anxiety about having fear. This is emotional focus. Instead of retreating from an emotion through layers of additional emotions until you find one you can deal with, you experience the actual emotion for what it is.

there are three big categories of barriers. The application barrier, the interview barrier, and the document barrier. And that’s what we spent most of our time iterating on and building a system that could slowly learn about those barriers and then intervene against them.

The application is asking, “Are you convicted of this? Are you convicted of that? Are you convicted of this other thing?” What is that saying to you, as a person, about what the system thinks of you?

Often they’ll call from a blocked number. They’ll send you a notice of when your interview is scheduled for, but this notice will sometimes arrive after the actual date of the interview. Most state agencies are really slammed right now for a bunch of reasons, including Medicaid unwinding. And many of the people assisting on Medicaid are the same workers who process SNAP applications. If you missed your phone interview, you have to call to reschedule it. But in many states, you can’t get through, or you have to call over and over and over again. For a lot of people, if they don’t catch that first interview call, they’re screwed and they’re not going to be approved.

getting to your point about how a website can fix this —  the end result was lowest-burden application form that actually gets a caseworker what they need to efficiently and effectively process it. We did a lot of iteration to figure out that sweet spot.

We didn’t need to do some hard system integration that would potentially take years to develop — we were just using the system as it existed. Another big advantage was that we had to do a lot of built-in data validation because we could not submit anything that was going to fail the county application. We discovered some weird edge cases by doing this.

A lot of times when you want to build a new front end for these programs, it becomes this multiyear, massive project where you’re replacing everything all at once. But if you think about it, there’s a lot of potential in just taking the interfaces you have today, building better ones on top of them, and then using those existing ones as the point of integration.

Government tends to take a more high-modernist approach to the software it builds, which is like “we’re going to plan and know up front how everything is, and that way we’re never going to have to make changes.” In terms of accreting layers — yes, you can get to that point. But I think a lot of the arguments I hear that call for a fundamental transformation suffer from the same high-modernist thinking that is the source of much of the status quo.

If you slowly do this kind of stuff, you can build resilient and durable interventions in the system without knocking it over wholesale. For example, I mentioned procedural denials. It would be adding regulations, it would be making technology systems changes, blah, blah, blah, to have every state report why people are denied, at what rate, across every state up to the federal government. It would take years to do that, but that would be a really, really powerful change in terms of guiding feedback loops that the program has.

when you start to read about civic technology, it very, very quickly becomes clear that things that look like they are tech problems are actually about institutional culture, or about policy, or about regulatory requirements.

If you have an application where you think people are struggling, you can measure how much time people take on each page. A lot of what technology provides is more rigorous measurement of the burdens themselves. A lot of these technologies have been developed in commercial software because there’s such a massive incentive to get people who start a transaction to finish it. But we can transplant a lot of those into government services and have orders of magnitude better situational awareness.

There’s this starting point thesis: Tech can solve these government problems, right? There’s healthcare.gov and the call to bring techies into government, blah, blah, blah. Then there’s the antithesis, where all these people say, well, no, it’s institutional problems. It’s legal problems. It’s political problems. I think either is sort of an extreme distortion of reality. I see a lot of more oblique levers that technology can pull in this area.

LLMs seem to be a fundamental breakthrough in manipulating words, and at the end of the day, a lot of government is words. I’ve been doing some active experimentation with this because I find it very promising. One common question people have is, “Who’s in my household for the purposes of SNAP?” That’s actually really complicated when you think about people who are living in poverty — they might be staying with a neighbor some of the time, or have roommates but don’t share food, or had to move back home because they lost their job.

I’ve been taking verbatim posts from Reddit that are related to the household question and inputting them into LLMs with some custom prompts that I’ve been iterating on, as well as with the full verbatim federal regulations about household definition. And these models do seem pretty capable at doing some base-level reasoning over complex, convoluted policy words in a way that I think could be really promising.

caseworkers are spending a lot of their time figuring out, wait, what rule in this 200-page policy manual is actually relevant in this specific circumstance? I think LLMS are going to be really impactful there.

It is certainly the case that I’ve seen some productive tensions in counties where there’s more of a mix of that and what you might consider California-style Republicans who are like, “We want to run this like a business, we want to be efficient.” That tension between efficiency and big, ambitious policies can be a healthy, productive one. I don’t know to what extent that exists at the state level, and I think there’s hints of more of an interest in focusing on state-level government working better and getting those fundamentals right, and then doing the more ambitious things on a more steady foundation.

California seemed to really try to take every ambitious option that the feds give us on a whole lot of fronts. I think the corollary of that is that we don’t necessarily get the fundamental operational execution of these programs to a strong place, and we then go and start adding tons and tons of additional complexity on top of them.

Having an opinionated set of tradeoffs exposes your approach to a set of weaknesses. The more you tip the scale on one side, the weaker something else will be. That’s okay! Making those difficult choices is what people pay you for. You should be proud of your compromises. My favorite products are opinionated. They make a clear statement about what they are not good at, in favor of being much better at something else.

The cover immediately sets Ways of Seeing apart from its contemporaries, the book itself begins on the cover. Rather than creating a conventionally appealing cover, Hollis chose to bypass this tradition entirely, instead placing the text and an image from the start of the first chapter straight onto the front, just beneath the title and authors name. This directness has a link with the television series, mimicking how the first episode began with no preamble or title sequence, Berger got started immediately, drawing the audience in with his message rather than any distractions.

Another link to Berger’s presenting style is Hollis’ choice of typeface, bold Univers 65 is used for the body copy throughout, in an attempt to achieve something of the captivating quality of Berger’s voice.

The layout also employs large indents rather than paragraph breaks, something of a Hollis trademark. But this mirrors how Berger had presented on television, there was little time wasted with atmospheric filler shots or long gaps in speech, the message was key and continuous.

The key reason that Ways of Seeing has become iconic as a piece of book design is how it dealt with text and image: the two are integrated, where an image is mentioned in the text it also appears there. Captions are avoided where possible. When unavoidable they are in a lighter weight of type and run horizontally, so as not to disrupt the text. Images are often set at the same width as the lines of text, or indented by the same amount, this democratises the text and image relationship. Occasionally works of art are cropped to show only the pertinent details. All of these features are a big departure from the art books of the time which usually featured glorified full page colour images, often in a glossy ‘colour plate’ section in the middle, completely distanced from where the text refers to them.

Design is not used for prettifying, or to create appeal, rather it is used for elucidating, to spread his message or get his point across as clearly as possible. Be it a point about art and politics, art and gender, the ethics of advertising, the human experiences of a rural GP, or economic migrants in Germany — the design is always appropriate to what Berger wants to say, but does so economically without redundancy.

Even in Portraits: John Berger on Artists published by Verso in 2015, Berger insisted on black and white reproductions, arguing that: “glossy colour reproductions in the consumerist world of today tend to reduce what they show to items in a luxury brochure for millionaires. Whereas black-and-white reproductions are simple memoranda.”

the images in the book “illustrate the essentially dialectical relationship between text and image in Berger’s work: the pattern in which an image shapes a text, which then goes on to shape how we understand that image.”

LLMs will represent a step change in tool support for end-user programming: the ability of normal people to fully harness the general power of computers without resorting to the complexity of normal programming. Until now, that vision has been bottlenecked on turning fuzzy informal intent into formal, executable code; now that bottleneck is rapidly opening up thanks to LLMs.

If this hypothesis indeed comes true, we might start to see some surprising changes in the way people use software: One-off scripts: Normal computer users have their AI create and execute scripts dozens of times a day, to perform tasks like data analysis, video editing, or automating tedious tasks. One-off GUIs: People use AI to create entire GUI applications just for performing a single specific task—containing just the features they need, no bloat. Build don’t buy: Businesses develop more software in-house that meets their custom needs, rather than buying SaaS off the shelf, since it’s now cheaper to get software tailored to the use case. Modding/extensions: Consumers and businesses demand the ability to extend and mod their existing software, since it’s now easier to specify a new feature or a tweak to match a user’s workflow. Recombination: Take the best parts of the different applications you like best, and create a new hybrid that composes them together.

Chat will never feel like driving a car, no matter how good the bot is. In their 1986 book Understanding Computers and Cognition, Terry Winograd and Fernando Flores elaborate on this point: In driving a car, the control interaction is normally transparent. You do not think “How far should I turn the steering wheel to go around that curve?” In fact, you are not even aware (unless something intrudes) of using a steering wheel…The long evolution of the design of automobiles has led to this readiness-to-hand. It is not achieved by having a car communicate like a person, but by providing the right coupling between the driver and action in the relevant domain (motion down the road).

Think about how a spreadsheet works. If you have a financial model in a spreadsheet, you can try changing a number in a cell to assess a scenario—this is the inner loop of direct manipulation at work. But, you can also edit the formulas! A spreadsheet isn’t just an “app” focused on a specific task; it’s closer to a general computational medium which lets you flexibly express many kinds of tasks. The “platform developers"—the creators of the spreadsheet—have given you a set of general primitives that can be used to make many tools. We might draw the double loop of the spreadsheet interaction like this. You can edit numbers in the spreadsheet, but you can also edit formulas, which edits the tool

what if you had an LLM play the role of the local developer? That is, the user mainly drives the creation of the spreadsheet, but asks for technical help with some of the formulas when needed? The LLM wouldn’t just create an entire solution, it would also teach the user how to create the solution themselves next time.

This picture shows a world that I find pretty compelling. There’s an inner interaction loop that takes advantage of the full power of direct manipulation. There’s an outer loop where the user can also more deeply edit their tools within an open-ended medium. They can get AI support for making tool edits, and grow their own capacity to work in the medium. Over time, they can learn things like the basics of formulas, or how a VLOOKUP works. This structural knowledge helps the user think of possible use cases for the tool, and also helps them audit the output from the LLMs. In a ChatGPT world, the user is left entirely dependent on the AI, without any understanding of its inner mechanism. In a computational medium with AI as assistant, the user’s reliance on the AI gently decreases over time as they become more comfortable in the medium.

our truly quirky dimensions are never really grasped by these recommendation algorithms. They have all the dullness of a Demographics 101 curriculum; they sketch our personalities with the crudity of crime-scene chalk-outlines. They’re not wrong about us; but they’re woefully incomplete.

The metaphor suggests precisely what to do: If you want to have wilder, curiouser thoughts, you have to avoid the industrial monocropping of big-tech feeds. You want an intellectual forest, overgrown with mushrooms and towering weeds and a massive dead log where a family of raccoons has taken up residence.

For me, it’s meant slowly — over the last few years — building up a big, rangy collection of RSS feeds, that let me check up on hundreds of electic blogs and publications and people. (I use Feedly.) I’ve also started using Fraidycat, a niftily quixotic feed-reader that lets you sort sources into buckets by “how often should I check this source”, which is a cool heuristic; some people/sites you want to check every day, and others, twice a year.

Other times I spend an hour or two simply prospecting — I pick a subject almost at random, then check to see if there’s a hobbyist or interest-group discussion-board devoted to it. (There usually is, running on free warez like phpBB). Then I’ll just trawl through the forum, to find out what does this community care about?

Here are the adoption curves for a handful of major technologies in the United States. There are big differences in the speeds at which these technologies were absorbed. Landline telephones took about 86 years to hit 80% adoption.Flush toilets took 96 years to hit 80% adoption.Refrigerators took about 25 years.Microwaves took 17 years.Smartphones took just 12 years.Why these wide differences in adoption speed? Conformability with existing infrastructure. Flush toilets required the build-out of water and sewage utility systems. They also meant adding a new room to the house—the bathroom—and running new water and sewage lines underneath and throughout the house. That’s a lot of systems to line up. By contrast, refrigerators replaced iceboxes, and could fit into existing kitchens without much work. Microwaves could sit on a countertop. Smartphones could slip into your pocket.

There are only so many degrees of freedom for users inside of these apps, which makes them simple to use. But this simplicity also strips away so much of the freedom we have during in-person interactions. You can type any message, but typing a message is all you can do. You can call any person, but talking directly into your camera is all you can do once you're connected. Without spatial interfaces, our current software doesn't give us much expressive control.

In social applications, spatial software has at least three advantages. These three advantages often overlap and bleed into each other.Afforded Intuition: Our natural understanding of space makes spatial software easier to use.Expressiveness: In a spatial interface, more degrees of freedom mean users can interact more creatively with software and with each other.Presence: In many spatial interfaces, we can sense other users through the presence of an avatar or figure.

Design Engineers at Vercel blend aesthetic sensibility with technical skills. This allows us to deeply understand a problem, then design, build, and ship a solution autonomously.The team is made up of people with a wide array of skills and a lot of curiosity. We constantly experiment with new tools and mediums. This multidisciplinary approach allows the team to push what’s possible on the web.

Design Engineers care about delivering exceptional user experiences that resonate with the viewer. For the web, this means:Delightful user interactions and affordancesBuilding reusable components/primitivesPage speedCross-browser supportSupport for inclusive input modes (touch, pointers, etc.)Respecting user preferencesAccessible to users of assistive technology

Being part of the Design team gives Design Engineers the autonomy and ability to work on things that would often get deprioritized in an Engineering backlog.

The team puts resources towards polished interactions, no dropped frames, no cross-browser inconsistencies, and accessibility. Examples of design-led projects are:Vercel’s Geist font: A Sans and Mono font. An interactive playground to see every glyph and try the font.Vercel’s design system documentation: An interactive docs playground used by engineers across the company to ship Vercel.Vercel’s Design Team homepage: An exploratory page for testing new web techniques and providing design resources.Delighters in the Vercel Dashboard: Features in the Vercel Dashboard that bring it to life and delight the user.

While no individual is expected to have all the skills, the team collectively is able to execute on ambitious designs because we can:Design in FigmaDesign in codeWrite production codeDebug browser performanceWrite GLSL shadersWrite copyCreate 3D experiences with Three.jsCreate 3D models/scenes in BlenderEdit videos using CGI and practical camera effects

You can see our team’s work across Vercel:Creating and maintaining components for the internal design system used on everything from Vercel.com to the Vercel Toolbar and the Next.js documentation.Websites like the Next.js Conf website and Vercel’s product pages.Product work and docs for Vercel and Next.js.Building proof of concepts for branding and marketing.Improving the accessibility of all Vercel web properties.

the tooling we choose has a profound impact on the work we do, and, in the best case scenario, becomes a standard for how we build products. This is why we put so much care into even the tiniest details in Linear.

Even when doing concept work, you often need to focus your efforts. The design concept should feel like an exciting evolution of the product.

I didn't adhere to a specific method during the exploration phase, but typically, each day I designed a complete set of screens and flows. One day might be dedicated to designing the Inbox view, while the next day I could focus on the roadmap and projects. Other days, I explored upcoming product features. During this process, I experimented with different iterations of the sidebar, visual styles, and colors, and then linked the screens together as a prototype to assess their functionality.

Through this process, I generated hundreds of screens and was able to narrow down a few major directions that resonated most. Around this time, I began sharing the screens with other designers and people within the company to gather feedback and additional insights.

Ultimately, we settled on the main design direction, and I created a few views to showcase it

We started with the concept design Karri had originally imagined, but it wasn’t fully figured out and needed some additional design work. We didn’t know how we would bridge the previous UI design with the new style or if the new design could support all of our application states and options. We were able to make some changes off the bat, such as updating the color system, while other changes had to be punted to later on, such as the different headers you come across while navigating the app.

It’s easy for the scope of UI redesign projects to blow up. Before we got too far down any one path, we needed to get some confidence on the right option to keep everyone focused. So we ran some stress tests (or crash tests if you want to be dramatic) before going into implementation and iterating with engineers. We tested three main focus areas: the environment, the appearance, and the hierarchy.

Our app runs on Electron, so our navigation needed to work not just on macOS and Windows as a native app but also in any browser. That meant that previous/next navigation buttons, history, and tabs needed to be easily removable to work with browsers. We tested a lot of options, from very condensed to more spacious configurations. I often relied on Apple standards, which also helped get close to the feeling of a native app.

I also spent time aligning labels, icons, and buttons, both vertically and horizontally in the sidebar and tabs. It was definitely a challenge given the amount of UI elements we have on this tiny surface. This part of the redesign isn’t something you’ll immediately see but rather something that you’ll feel after a few minutes of using the app.

Karri mostly worked with opacities of black and white during his explorations, which really helped him get results quickly and helped me understand the relationship he had in mind between the elements and their respective elevation and hierarchy. As our system relied on a set of variables, I worked with Andreas on our software engineering team to polish and iterate on both the core variables and the operations we apply to them to generate our aliases for surfaces, texts, icons, and controls.

A while back, we rebuilt the system for generating custom themes in Linear, using the LCH color space instead of HSL. LCH has the benefit that it’s perpetually uniform, meaning a red and a yellow color with lightness 50 will appear roughly equally light to the human eye. This makes it possible to generate more consistently good-looking themes, regardless of which base colors are used.

Yes, the theme generation system also supports a contrast variable which defines how contrasty a theme should be. This allows us to automatically include super high-contrast themes for users who need it for accessibility reasons.

Linear relies on a set of structured layouts that support the navigation elements and content. It integrates additional headers to store filters and display options, side panels to display meta properties, as well as the actual display: list, board, timeline, split, and fullscreen.When I joined the project, Karri had already gathered most of the app's views and their respective states, so I was able to run all of my tests quite effectively. I mostly worked by type of view (list, board, split, etc.) as I found it easier to focus and ensure that every decision worked in all cases.

We divided the project into five milestones:Stress tests: Following the series of explorations made in November 2023, we tested if the direction felt right in the main views of Linear: Inbox, Triage, My Issues, Issues List, Project, Cycles, Roadmap, Search.Behavior definitions: As the direction was refined, we documented and defined the behaviors of the main components of the app: sidebar, tabs, app headers, and view headers.Sidebar and chrome refresh: We implemented the first bits of the refresh on the sidebar, tabs, and view headers. We also improved the appearance and contrast of our theme for light and dark modes. We used a feature flag to allow for internal testing at this stage.Private beta: We started rolling out the new design in Private beta to get initial feedback. Once we felt comfortable, we began rolling out the changes to a percentage of workspaces each day.GA: We released the new UI to all workspaces.

We knew that in order to move quickly and ship our work successfully, we needed to dedicate time and team resources to it. We couldn’t treat it as a side project.

Each afternoon, we divided the coding portions into groups of two engineers while designers iterated on other parts of the project, building a pipeline for us to work from. This daily back-and-forth between designers and engineers helped us get the first working version of the new UI by the end of the week

Next, we worked on the Inbox. We redesigned notifications to be more centered around the notification type and emphasized the faces of your teammates. We simplified headers and filters to improve the overall navigation. We also reviewed comments alignments and harmonized the look of our buttons with the new themes.

We started using Inter Display to add more expression to our headings while maintaining their readability and kept using regular Inter for the rest of the text elements.

The challenges start from the fact that it's never a good time to do a redesign. It's hard to make it a priority. It's difficult to calculate the ROI on it. And if you run your product with A/B testing, every global redesign will tank the metrics in the short term.

The real need for redesigns often comes when you have created a successful product and it has evolved with the market and users over time.

We ship small changes daily, and something major almost every week. Every year, it's almost like a new product. This incremental way of building the product is hugely beneficial, and often necessary — though it unbalances the overall design, and leads to design debt. Each new capability adds stress on the product's existing surfaces for which it was initially designed. Functionality no longer fits in a coherent way. It needs to be rebalanced and rethought.

If your product evolves fast, you should be paying this debt every 2-3 years. The longer you wait and the more successful your product becomes, the more you will have to untangle.

Slowly the user sentiment and perception might start turning negative and you might start looking like a dinosaur incumbent. This leaves an opportunity for some nimbler player to come along and compete in your market. Companies often try to address this with brand refreshes, but if you don’t refresh the product, nothing truly changes about the experience.

While the design debt often happens in small increments, it’s best to be paid in larger sweeps. This goes against the common wisdom in engineering where complete code rewrites are avoided. The difference is that on the engineering side, a modular or incremental way of working can work as the technical implementation is not really visible. Whereas the product experience is holistic and visual. You cannot predict which path the user takes. If you update just one module or view at a time, the overall experience becomes more disjointed. Secondly, if your goal is to reset and rebalance the whole product UI and experience, you have to consider all the needs simultaneously. An incremental approach doesn’t let you do that.

I’ve never seen redesigns successfully executed without the CEO behind it. While design might have a seat at the table generally, they are usually not able to convince everyone around that table. Only the CEO can push through all the excuses and give the latitude to a project touching all of the surfaces the product needs.

The way to get the CEO involved is to tie a design reset into a larger company shift or directional change. For example, if a company is looking at a new product, or major new feature, a redesign project can be a way to imagine how it might look or feel. This can be the justification for why you need to spin up the team (and at the same time, you can make a case for updating the rest of the product experience).

Organizations are often quite stuck in their views and ways of doing things, making them less enthusiastic about something new. When I was at Airbnb, the mobile redesign project was a way to shift the company to become mobile-first. It set the tone and got the message across to the whole company that mobile was happening and that it was happening now. While it looks like an obvious change in hindsight, there were many arguments against it at the time and it took a lot of convincing. Switching to think about mobile meant the design and features had to be rethought to work in that platform.

While Linear is a smaller and younger company, we’re also undergoing a shift. The product vision has widened from a simple issue tracker to a purpose-built system for product development. We are now moving into planning workflows that naturally come before the building or execution phase of building products. This product evolution creates new future needs from the product design, and we have to make space for it.

When you realize that a design reset is needed for your product, how do you actually get started with the project? You start with a standalone team to explore the new concept design and create something the company can rally around.The auto industry has a practice of building “concept cars”, where they explore the next version of the car freely and boldly without considering practicality. A concept car sets the direction, but usually is not expected to land in production because it’s too impractical or costly to manufacture.

A secret I've learned is that when you tell people a design is a "concept" or "conceptual" it makes it less likely that the idea is attacked from whatever perspective they hold or problems they see with it. The concept is not perceived as real, but something that can be entertained. By bringing leaders or even teams along with the concept iterations, it starts to solidify the new direction in their mind, eventually becoming more and more familiar. That's the power of visual design.

Design Engineer is the latest label we're chucking onto the pile of obfuscatory design titles alongside interface designer, interaction designer, software designer, web designer, product designer, design systems architect, UI/UX designer, UX engineer, UI engineer, and front-of-the-front-end engineer.

Throwing this extra label onto the pile feels necessary though. Design engineer captures something simple, important, and worth distinguishing: a person who sits squarely at the intersection of design and engineering, and works to bridge the gap between them.

They're people who know how to run a design process to decide how something should work, look, and feel, and have the engineering chops to implement it. They can quickly iterate on ideas by cycling between design exploration, research, and live code. The skillset is ideal for prototyping, exploratory interaction design, and building robust design systems.

Most from a small set of companies like Vercel, Linear, The Browser Company and Replit, known for their attention to interface design detail and slick product interactions, who are clearly encouraging and cultivating design-engineer hybrids.

People are incentivised to only share their sexy, shiny, flawless creations, rather than their messy process or shameful failures. Some of the especially tedious and labourious work isn't easily shareable, such as advocating for robust design systems and cleaning up legacy code.

I am not under any illusions that these public works constitute the entirety of what design engineers create or spend all day making. I'm sure some spend their days “aligning stakeholders,” buried under a mountain of strategic documents and trapped by heirarchical approval chains. Say a small prayer for them.

Muse as a brand and a product represented something aspirational. People want to be deeper thinkers, to be more strategic, and to use cool, status-quo challenging software made by small passionate teams. These kinds of aspirations are easier to indulge in times of plenty. But once you're getting laid off from your high-paying tech job, or struggling to raise your next financing round, or scrambling to protect your kids' college fund from runaway inflation and uncertain markets... I guess you don't have time to be excited about cool demos on Twitter and thoughtful podcasts on product design.

I’d speculate that another factor is the half-life of cool new productivity software. Evernote, Slack, Notion, Roam, Craft, and many others seem to get pretty far on community excitement for their first few years. After that, I think you have to be left with software that serves a deep and hard-to-replace purpose in people’s lives. Muse got there for a few thousand people, but the economics of prosumer software means that just isn’t enough. You need tens of thousands, hundreds of thousands, to make the cost of development sustainable.

We envisioned Muse as the perfect combination of the freeform elements of a whiteboard, the structured text-heavy style of Notion or Google Docs, and the sense of place you get from a “virtual office” ala group chat. As a way to asynchronously trade ideas and inspiration, sketch out project ideas, and explore possibilities, the multiplayer Muse experience is, in my honest opinion, unparalleled for small creative teams working remotely.

But friction began almost immediately. The team lead or organizer was usually the one bringing Muse to the team, and they were already a fan of its approach. But the other team members are generally a little annoyed to have to learn any new tool, and Muse’s steeper learning curve only made that worse. Those team members would push the problem back to the team lead, treating them as customer support (rather than contacting us directly for help). The team lead often felt like too much of the burden of pushing Muse adoption was on their shoulders. This was in addition to the obvious product gaps, like: no support for the web or Windows; minimal or no integration with other key tools like Notion and Google Docs; and no permissions or support for multiple workspaces. Had we raised $10M back during the cash party of 2020–2021, we could have hired the 15+ person team that would have been necessary to build all of that. But with only seven people (we had added two more people to the team in 2021–2022), it just wasn’t feasible.

We neither focused on a particular vertical (academics, designers, authors...) or a narrow use case (PDF reading/annotation, collaborative whiteboarding, design sketching...). That meant we were always spread pretty thin in terms of feature development, and marketing was difficult even over and above the problem of explaining canvas software and digital thinking tools.

being general-purpose was in its blood from birth. Part of it was maker's hubris: don't we always dream of general-purpose tools that will be everything to everyone? And part of it was that it's truly the case that Muse excels at the ability to combine together so many different related knowledge tasks and media types into a single, minimal, powerful canvas. Not sure what I would do differently here, even with the benefit of hindsight.

Muse built a lot of its reputation on being principled, but we were maybe too cautious to do the mercenary things that help you succeed. A good example here is asking users for ratings; I felt like this was not to user benefit and distracting when the user is trying to use your app. Our App Store rating was on the low side (~3.9 stars) for most of our existence. When we finally added the standard prompt-for-rating dialog, it instantly shot up to ~4.7 stars. This was a small example of being too principled about doing good for the user, and not thinking about what would benefit our business.

Growing the team slowly was a delight. At several previous ventures, I've onboard people in the hiring-is-job-one environment of a growth startup. At Muse, we started with three founders and then hired roughly one person per year. This was absolutely fantastic for being able to really take our time to find the perfect person for the role, and then for that person to have tons of time to onboard and find their footing on the team before anyone new showed up. The resulting team was the best I've ever worked on, with minimal deadweight or emotional baggage.

ultimately your product does have to have some web presence. My biggest regret is not building a simple share-to-web function early on, which could have created some virality and a great deal of utility for users as well.

In terms of development speed, quality of the resulting product, hardware integration, and a million other things: native app development wins.

After decades working in product development, being on the marketing/brand/growth/storytelling side was a huge personal challenge for me. But I feel like I managed to grow into the role and find my own approach (podcasting, demo videos, etc) to create a beacon to attract potential customers to our product.

when it comes time for an individual or a team to sit down and sketch out the beginnings of a new business, a new book, a new piece of art—this almost never happens at a computer. Or if it does, it’s a cobbled-together collection of tools like Google Docs and Zoom which aren’t really made for this critical part of the creative lifecycle.

any given business will find a small number of highly-effective channels, and the rest don't matter. For Heroku, that was attending developer conferences and getting blog posts on Hacker News. For another business it might be YouTube influencer sponsorships and print ads in a niche magazine. So I set about systematically testing many channels.

a more powerful aim is to develop a new medium for thought. A medium such as, say, Adobe Illustrator is essentially different from any of the individual tools Illustrator contains. Such a medium creates a powerful immersive context, a context in which the user can have new kinds of thought, thoughts that were formerly impossible for them. Speaking loosely, the range of expressive thoughts possible in such a medium is an emergent property of the elementary objects and actions in that medium. If those are well chosen, the medium expands the possible range of human thought.

Memory systems make memory into a choice, rather than an event left up to chance: This changes the relationship to what we're learning, reduces worry, and frees up attention to focus on other kinds of learning, including conceptual, problem-solving, and creative.

Memory systems can be used to build genuine conceptual understanding, not just learn facts: In Quantum Country we achieve this in part through the aspiration to virtuoso card writing, and in part through a narrative embedding of spaced repetition that gradually builds context and understanding.

Mnemonic techniques such as memory palaces are great, but not versatile enough to build genuine conceptual understanding: Such techniques are very specialized, and emphasize artificial connections, not the inherent connections present in much conceptual knowledge. The mnemonic techniques are, however, useful for bootstrapping knowledge with an ad hoc structure.

What practices would lead to tools for thought as transformative as Hindu-Arabic numerals? And in what ways does modern design practice and tech industry product practice fall short? To be successful, you need an insight-through-making loop to be operating at full throttle, combining the best of deep research culture with the best of Silicon Valley product culture.

Historically, work on tools for thought has focused principally on cognition; much of the work has been stuck in Spock-space. But it should take emotion as seriously as the best musicians, movie directors, and video game designers. Mnemonic video is a promising vehicle for such explorations, possibly combining both deep emotional connection with the detailed intellectual mastery the mnemonic medium aspires toward.

It's striking to contrast conventional technical books with the possibilities enabled by executable books. You can imagine starting an executable book with, say, quantum teleportation, right on the first page. You'd provide an interface – perhaps a library is imported – that would let users teleport quantum systems immediately. They could experiment with different parts of the quantum teleportation protocol, illustrating immediately the most striking ideas about it. The user wouldn't necessarily understand all that was going on. But they'd begin to internalize an accurate picture of the meaning of teleportation. And over time, at leisure, the author could unpack some of what might a priori seem to be the drier details. Except by that point the reader will be bought into those details, and they won't be so dry

Aspiring to canonicity, one fun project would be to take the most recent IPCC climate assessment report (perhaps starting with a small part), and develop a version which is executable. Instead of a report full of assertions and references, you'd have a live climate model – actually, many interrelated models – for people to explore. If it was good enough, people would teach classes from it; if it was really superb, not only would they teach classes from it, it could perhaps become the creative working environment for many climate scientists.

In serious mediums, there's a notion of canonical media. By this, we mean instances of the medium that expand its range, and set a new standard widely known amongst creators in that medium. For instance, Citizen Kane, The Godfather, and 2001 all expanded the range of film, and inspired later film makers. It's also true in new media. YouTubers like Grant Sanderson have created canonical videos: they expand the range of what people think is possible in the video form. And something like the Feynman Lectures on Physics does it for textbooks. In each case one gets the sense of people deeply committed to what they're doing. In many of his lectures it's obvious that Feynman isn't just educating: he's reporting the results of a lifelong personal obsession with understanding how the world works. It's thrilling, and it expands the form.

There's a general principle here: good tools for thought arise mostly as a byproduct of doing original work on serious problems.

Game companies develop many genuinely new interface ideas. This perhaps seems surprising, since you'd expect such interface ideas to also suffer from the public goods problem: game designers need to invest enormous effort to develop those interface ideas, and they are often immediately copied (and improved on) by other companies, at little cost. In that sense, they are public goods, and enrich the entire video game ecosystem.

Many video games make most of their money from the first few months of sales. While other companies can (and do) come in and copy or riff on any new ideas, it often does little to affect revenue from the original game, which has already made most of its money In fact, cloning is a real issue in gaming, especially in very technically simple games. An example is the game Threes, which took the developers more than a year to make. Much of that time was spent developing beautiful new interface ideas. The resulting game was so simple that clones and near-clones began appearing within days. One near clone, a game called 2048, sparked a mini-craze, and became far more successful than Threes. At the other extreme, some game companies prolong the revenue-generating lifetime of their games with re-releases, long-lived online versions, and so on. This is particularly common for capital-intensive AAA games, such as the Grand Theft Auto series. In such cases the business model relies less on clever new ideas, and more on improved artwork (for re-release), network effects (for online versions), and branding. . While this copying is no doubt irritating for the companies being copied, it's still worth it for them to make the up-front investment.

in gaming, clever new interface ideas can be distinguishing features which become a game's primary advantage in the marketplace. Indeed, new interface ideas may even help games become classics – consider the many original (at the time) ideas in games ranging from Space Invaders to Wolfenstein 3D to Braid to Monument Valley. As a result, rather than underinvesting, many companies make sizeable investments in developing new interface ideas, even though they then become public goods. In this way the video game industry has largely solved the public goods problems.

It's encouraging that the video game industry can make inroads on the public goods problem. Is there a solution for tools for thought? Unfortunately, the novelty-based short-term revenue approach of the game industry doesn't work. You want people to really master the best new tools for thought, developing virtuoso skill, not spend a few dozen hours (as with most games) getting pretty good, and then moving onto something new.

Adobe shares in common with many other software companies that much of their patenting is defensive: they patent ideas so patent trolls cannot sue them for similar ideas. The situation is almost exactly the reverse of what you'd like. Innovative companies can easily be attacked by patent trolls who have made broad and often rather vague claims in a huge portfolio of patents, none of which they've worked out in much detail. But when the innovative companies develop (at much greater cost) and ship a genuinely good new idea, others can often copy the essential core of that idea, while varying it enough to plausibly evade any patent. The patent system is not protecting the right things.

many of the most fundamental and powerful tools for thought do suffer the public goods problem. And that means tech companies focus elsewhere; it means many imaginative and ambitious people decide to focus elsewhere; it means we haven't developed the powerful practices needed to do work in the area, and a result the field is still in a pre-disciplinary stage. The result, ultimately, is that it means the most fundamental and powerful tools for thought are undersupplied.

Culturally, tech is dominated by an engineering, goal-driven mindset. It's much easier to set KPIs, evaluate OKRs, and manage deliverables, when you have a very specific end-goal in mind. And so it's perhaps not surprising that tech culture is much more sympathetic to AGI and BCI as overall programs of work. But historically it's not the case that humanity's biggest breakthroughs have come about in this goal-driven way. The creation of language – the ur tool for thought – is perhaps the most important occurrence of humanity's existence. And although the origin of language is hotly debated and uncertain, it seems extremely unlikely to have been the result of a goal-driven process. It's amusing to try imagining some prehistoric quarterly OKRs leading to the development of language. What sort of goals could one possibly set? Perhaps a quota of new irregular verbs? It's inconceivable!

Even the computer itself came out of an exploration that would be regarded as ridiculously speculative and poorly-defined in tech today. Someone didn't sit down and think “I need to invent the computer”; that's not a thought they had any frame of reference for. Rather, pioneers such as Alan Turing and Alonzo Church were exploring extremely basic and fundamental (and seemingly esoteric) questions about logic, mathematics, and the nature of what is provable. Out of those explorations the idea of a computer emerged, after many years; it was a discovered concept, not a goal.

Fundamental, open-ended questions seem to be at least as good a source of breakthroughs as goals, no matter how ambitious. This is difficult to imagine or convince others of in Silicon Valley's goal-driven culture. Indeed, we ourselves feel the attraction of a goal-driven culture. But empirically open-ended exploration can be just as, or more successful.

There's a lot of work on tools for thought that takes the form of toys, or “educational” environments. Tools for writing that aren't used by actual writers. Tools for mathematics that aren't used by actual mathematicians. And so on. Even though the creators of such tools have good intentions, it's difficult not to be suspicious of this pattern. It's very easy to slip into a cargo cult mode, doing work that seems (say) mathematical, but which actually avoids engagement with the heart of the subject. Often the creators of these toys have not ever done serious original work in the subjects for which they are supposedly building tools. How can they know what needs to be included?

As for a Hall of Shame thing? That would be the slow but steady encroachment of single-window applications in MacOS, especially via Catalyst and Electron. The reason I gravitated toward MacOS in the first place is the same reason I continue to use it: it fits my mental model of how an operating system ought to work.

In the first approach, the primary interface affordance is an input that directly (for the most part) instructs an AI model(s). In this paradigm, people are authoring prompts that result in text, image, video, etc. generation. These prompts can be sequential, iterative, or un-related. Marquee examples are OpenAI's ChatGPT interface or Midjourney's use of Discord as an input mechanism. Since there are few, if any, UI affordances to guide people these systems need to respond to a very wide range of instructions. Otherwise people get frustrated with their primarily hidden (to the user) limitations.

The second approach doesn't include any UI elements for directly controlling the output of AI models. In other words, there's no input fields for prompt construction. Instead instructions for AI models are created behind the scenes as people go about using application-specific UI elements. People using these systems could be completely unaware an AI model is responsible for the output they see.

The third approach is application specific UI with AI assistance. Here people can construct prompts through a combination of application-specific UI and direct model instructions. These could be additional controls that generate portions of those instructions in the background. Or the ability to directly guide prompt construction through the inclusion or exclusion of content within the application. Examples of this pattern are Microsoft's Copilot suite of products for GitHub, Office, and Windows.

they could be overlays, modals, inline menus and more. What they have in common, however, is that they supplement application specific UIs instead of completely replacing them.

There are certain design principles you can apply to this like composition, hierarchy, color theory, and so on, but to the regular consumer, it’s the gestalt of all your design decisions that ultimately makes an emotional connection. We know emotion is so much of what drives purchasing behavior so the more nebulous goal of visual design is often pulling those levers in just the right ratio to elicit a desired connection to your product.

ven something as foundational as increasing white space in your design can instantly improve a customer’s perception of your brand’s worth when it’s done intentionally.

almost all clients agree that they need better look and feel in their digital experience, that they are looking to add some type of emotional signal that’s missing. But when it comes time to accept changes that address those problems, I’ve had several instances where clients are resistant to solutions that depart too significantly from what they’re already comfortable with. Usually that reservation is overcome when I correlate the visual changes to the ways in which the user experience is improved and the resulting impact on business performance. There will be also times when a client expresses to us that they’ve never been satisfied with their brand or website and they point to competitors that evoke certain emotional qualities that they are aspiring to capture. In those cases it’s quite rewarding to be able to translate those more nebulous feelings into concrete terminology that gives us specific visual principles to bring in or improve on.

The importance of user-centricity, demands a broad-based view of where design can make a difference. We live in a world where your smartphone can warn you to leave early for your next appointment because of traffic, and your house knows when you’ll be home and therefore when to turn on the heat. The boundaries between products and services are merging into integrated experiences.

Our research suggests that overcoming isolationist tendencies is extremely valuable. One of the strongest correlations we uncovered linked top financial performers and companies that said they could break down functional silos and integrate designers with other functions. This was particularly notable in consumer-packaged-goods (CPG) businesses, where respondents from companies that were top-quartile integrators reported compound annual growth rates some seven percentage points above those that were weakest in this respect.

By Katharine Schwab4 minute ReadOver the last year, Ideo’s philosophy of “design thinking“–a codified, six-step process to solve problems creatively–has come under fire. It’s been called bullshit, the opposite of inclusive design, and a failed experiment. It’s even been compared to syphilis.Ideo as an institution has rarely responded to critiques of design thinking or acknowledged its flaws. But at the Fast Company Innovation Festival, Ideo partner and leader of its Cambridge, Massachusetts, office Michael Hendrix had a frank conversation with Co.Design senior writer Mark Wilson about why design thinking has gotten so much flack.“I think it’s fair to critique design thinking, just as it’s fair to critique any other design strategy,” Hendrix says. “There’s of course many poor examples of design thinking, and there’s great examples. Just like there’s poor examples of industrial design and graphic design and different processes within organizations.”Part of the problem is that many people use the design thinking methodology in superficial ways. Hendrix calls it the “theater of innovation.” Companies know they need to be more creative and innovative, and because they’re looking for fast ways to achieve those goals, they cut corners.“We get a lot of the materials that look like innovation, or look like they make us more creative,” Hendrix says. “That could be anything from getting a bunch of Sharpie markers and Post-its and putting them in rooms for brainstorms, to having new dress codes, to programming play into the week. They all could be good tools to serve up creativity or innovation, they all could be methods of design thinking, but without some kind of history or strategy to tie them together, and track their progress, track their impact, they end up being a theatrical thing that people can point to and say, ‘oh we did that.'”

“If you make something rigid and formulaic, it could absolutely fail,” he says. “You want to rely on milestones in the creative process, but you don’t want it to be a reactive process that loses its soul.”

“There is a real need to build respect for one another and trust in the safety of sharing ideas so you can move forward,” Hendrix says. “Knowing when to bring judgments is important. Cultures that are highly judgy, that have hierarchy, that are rewarding the person who is the smartest person in the room, don’t do well with this kind of methodology.”

There are a multitude of viable culprits behind this revenue drop. Robson himself pointed to the pandemic and tightened global budgets while arguing that “the widespread adoption of design thinking . . . has reduced demand for our services.” (Ideo was, in part, its own competition here since for years, it sold courses on design thinking.) It’s perhaps worth noting that, while design thinking was a buzzword from the ’90s to the early 2010s, it’s commonly met with all sorts of criticism today.

“People were like, ‘We did the process, why doesn’t our business transform?'” says Cliff Kuang, a UX designer and coauthor of User Friendly (and a former Fast Company editor). He points to PepsiCo, which in 2012 hired its first chief design officer and opened an in-house design studio. The investment has not yielded a string of blockbusters (and certainly no iPhone for soda). One widely promoted product, Drinkfinity, attempted to respond to diminishing soft-drink sales with K-Cup-style pods and a reusable water bottle. The design process was meticulous, with extensive prototyping and testing. But Drinkfinity had a short shelf life, discontinued within two years of its 2018 release.

“Design is rarely the thing that determines whether something succeeds in the market,” Kuang says. Take Amazon’s Kindle e-reader. “Jeff Bezos henpecked the original Kindle design to death. Because he didn’t believe in capacitive touch, he put a keyboard on it, and all this other stuff,” Kuang says. “Then the designer of the original Kindle walked and gave [the model] to Barnes & Noble.” Barnes & Noble released a product with a superior physical design, the Nook. But design was no match for distribution. According to the most recent data, Amazon owns approximately 80% of the e-book market share.

The rise of mobile computing has forced companies to create effortless user experiences—or risk getting left behind. When you hail an Uber or order toilet paper in a single click, you are reaping the benefits of carefully considered design. A 2018 McKinsey study found that companies with the strongest commitment to design and the best execution of design principles had revenue that was 32 percentage points higher—and shareholder returns that were 56 percentage points higher—than other companies.

There are four signs your idea has legs:People pay you money: Several people start to pay for your product, ideally people you don’t have a direct connection toContinued usage: People continue to use your prototype product, even if it’s hackyStrong emotion: You’re hearing hatred for the incumbents (i.e. pain) or a deep and strong emotional reaction to your idea (i.e. pull)Cold inbound interest: You’re seeing cold inbound interest in your product

Every prosumer collaboration product, including Figma, Notion, Coda, Airtable, Miro, and Slack, spent three to four years wandering in the dark until they stumbled on something that clicked.