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.

Many case studies read to me like school homework: they knew what the answer and the process were “supposed to be” according to the textbook, so made up the story to fit. In reality, as you point out, it’s never smooth and linear. It’s messy and loopish. If you’re doing a good job, you rarely end up with anything remotely like you anticipated when you started out.

abandon your dogmatic and idealistic view of the design process, and keep learning about how flexible, messy, and beautiful it is.

I don’t speak about the “ideal” design process for a simple reason: it doesn’t exist. Design is never linear, and all projects are unique. The point is to show and explain your path from the kick-off to the final result in the portfolio.

If you tell a story, include the details and the things that didn’t work and how you adapted to overcome the problem, the design manager will empathise with you. For the five minutes it takes to read your case study, they’ll be in your shoes. It’ll remind them of all the times when they had similar problems and it’ll make them appreciate you and your struggles as a designer.

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.

At Tokyo Disneyland, for example, you can create elaborate in-reach prop displays that will never, ever be disturbed or broken by guests — rules are rules. (By the same token, I once got politely yelled at there for ducking under a chain to shortcut a completely, 100% empty line. I absolutely had to walk through the entire, empty switchback. And that’s fair, I was breaking the rules!) Whereas here in America, if your prop is not literally bolted down, it’s likely to show up on eBay / Van Eaton within the week.

honestly, a lot of it, I think, is just that some designers are amazing at imagining things, but not as amazing at imagining them surrounded by the universe. That beautiful thing you’re working on, it lives in a window on your monitor tucked under a title bar, and that’s as tricky as it gets. What if you can’t imagine your thing in its final context? What if you aren’t great at predicting human behaviors other than your own?

good design isn’t just beautiful and incredible and boundary-pushing, it also remembers what it means to be human.

However the most controversial step I’ll be taking is removing a few of the functions. This usually gets pushback from most product managers as for them “features == sales”. The problem with this thinking is that it assumes a) all features are used and b) extra features has no negative impact.

TikTok looked at what makes their content unique. Applying an OOUX mindset, the most interesting object is the “post” populating the feed. Two things stand out. First, the videos are very short, with only a couple of seconds of runtime. Which meant the usual distinction between browsing and watching made little sense. Second, opting for a truly mobile experience, their videos would be portrait mode. This meant users could browse and watch in the same orientation, one video at a time. The design decision to merge the browse and watch experience into one stream with autoplay broke all kinds of conventions. Yet, by doing so, it created a unique and engaging experience that is even borderline addictive.

Tinder understood that the selection moment is what makes them unique. They wanted to provide a quick and easy method for their key interaction to decide if a user is a match or not.

Games felt like they were about sparkles and tension. Great app UX is about minimalism and simplicity. Fortunately, I found Raph Koster, the author of A Theory of Fun. Raph is known as a “Game Grammarian” and deeply deconstructs how games are made.

Another more modern example is this landing page for PayPal. Notice how the page clearly invites you to choose. Are you a “Personal” user or a “Business” user? As you mouse over each section, the story unfolds, expanding your choices, offering you things you can easily understand and identify with. Each branch has a clear call to action. This is a beautiful story telling sequence that pulls you in and gets you to become an active part of the on-boarding process.

There are clearly 3 distinct versions of jumping going on here: Initial jump. Simple button pressLong jump. Long button pressLanding jump. Timed jump What’s so interesting here is that there is only one ‘thing’ you’re learning: jumping. But by stressing subtle aspects of how to jump, the game builds up variations of it. A basic jump gets you over things, a long jump can “open” and landing a jump can “attack”. A boring app designer like me would assume you’d need 3 different verbs/buttons for this but Super Mario does this with a single “Jump” action.

APPSEach feature is in isolation, how it is done usually has little relation to other features (other that using a style guide).GAMESBuild a game through a single, mechanic that grows in expressive power by adding modifiers like time, special keys, or timing.

APPSJust throw in a bunch of features into a pot.GAMESUnderstand everything is a journey. Work hard to make everything a closely connected arc of events that help the user create a narrative that matches the overall story.

APPSAssume users are at a constant skill level.GAMESUse hints constantly and patiently to move users to the next level.

APPSTend to offer users a large toolbox and let them figure out how to get started.GAMESHave a clear understanding of the journey and say “Start here first”.

The Mac took a very hardware driven concept, turning on your computer, and turned it into theater. Yes it had the boot sound, but it then showed a promise, a compromise of the final desktop and as it booted, ‘inflated’ that promise with the final working model. Why people loved the Mac is often misunderstood. I’d claim that it’s this dedication to taking people on a carefully crafted story, one which allowed users to craft a compatible narrative, that is at the heart of this devotion.

To win the level you must first cross the street. To cross the street requires that you move the frog. To move the frog requires that you understand joystick timing. Each of these sub levels have their own feedback considerations: Street: the cars movementFrog: How it moves, how far it jumps each timeJoystick: Direction and speed of movement (it’s quite slow actually) Games understand that each of these levels has their own set of feedback, motivation and learning that must take place. This level of deconstruction, in a 30 year old game no less, blew my mind. Games were complex! They really paid attention to detail. There was a lot here to understand.

The computer example here is desktop menus. “Selecting a menu item” is actually a fractal cascade of skills where you first start horizontally browsing the menu bar, with a click, you shift into a vertical mode but keep the same basic highlight approach. For hierarchical menus, you need to understand the graphic hint that there is something deeper and then navigate over to reveal and then select that menu. Anyone who has taught beginning computer users the menu system knows how hard it is to master hierarchical menus. It’s takes practice to find, reveal and track over to that menu. There is a fractal cascade of skills required.

Raph has a great quote in his book for this: “Fun is just another word for learning”. In order to have fun, you must learn. I find this inspiring as app design wants your users to learn but we’ve rarely appreciated this could be fun. Games understand that in order to learn you must start thinking in layers. Begin with a basic skill and slowly add more, getting better one layer at a time.