Many complex products often present all features at once, including crypto wallets. Everything is right there, all the time, whether you need it or not. We wanted to take a different approach where the fundamentals would be at your fingertips, but everything else would appear as it became most relevant to you.

We decided to focus on fluidity after observing how static transitions can disrupt the user’s sense of flow and orientation. Staticity can also leave a product feeling lifeless, which we didn’t want. A lifeless product feels like a dead product, and a dead product feels uncared for.

Family's dynamic tray system comprises components housed within trays that can effortlessly expand, contract, and adapt in response to a user’s actions. Trays can appear on the fly and function as a condensed version of the app, with a specific set of constraints and capabilities.

The tray system follows certain rules to function in a way that feels natural. Trays are initiated by the user by tapping buttons, icons, or opening push notifications. They can manifest either as standalone entities on top of any app content, or emerge from within other components like buttons.

To prevent any confusion during transitions, each subsequent tray is designed to vary in height. This makes the progression or change unmistakably clear. This constraint occasionally requires us to rewrite content or tweak the design of a tray slightly to make a transition apparent.

Every tray is equipped with a title that succinctly captures its function or contents, alongside an icon. This icon serves a dual purpose: it allows users to dismiss the tray if it's the initial one shown, or navigate back through a sequence of trays that have been presented one-by-one.

Each tray displayed is typically dedicated to a singular piece of content — like educational text explaining a feature — or a primary action, such as completing a checklist before a transaction.

When deciding whether to implement a tray or full screen flow, we decided to utilise trays for transient actions that don't need to be permanently on display within the app. This can be especially helpful for confirmation steps and warnings, which appear in the right place at the right time.

Trays can also function as the starting point for more elaborate flows that ultimately transition to a full screen format.

One advantage of leveraging trays over full screen flows is the preservation of context. Unlike full screen transitions that can displace users from where they just were, trays overlay content directly onto the current interface.

The compact nature of trays signals to users that each task is approachable. It encourages engagement without the intimidation of a full screen commitment.

Users are guided through actions with the reassurance that they're not veering off course, but rather diving deeper into their current context. This simplifies the user's journey and reinforces the fluidity and coherence of the overall experience.

Imagine seeing parts of a room through an open doorway. From a few metres away, you’re able to catch a glimpse of what’s inside. As you approach and enter, the space and its contents are gradually revealed. Each action by the user makes the interface unfold and evolve, much like walking through a series of interconnected rooms. As a user, I get to see where I’m going as I go there. It’s this dynamic that allows Family to remain simple and keep complexity out of sight and out of mind until required.

Our second principle builds upon similar themes to our dynamic tray system and pushes the concept even further. It envisions the entire app as a constantly evolving space, where any element can theoretically transform into another, given there's a strong enough rationale for the transition.

Similar to our tray system, we aim for a sense of dimensionality throughout the app. Our goal is to create a coherent journey that users are able to follow easily. Every movement feels like a logical step forward to resemble what we experience in physical spaces.

For example, switching tabs in Family includes a flash of directional motion. If you tap on a tab on the left, the transition moves left, and vice versa for the right. This creates a subtle yet helpful sense of space and movement. We fly instead of teleport.

Let’s take the transformation of a chevron in a multi-step flow; something that would typically be static. In Family, we saw an opportunity when transitioning between screens for a simple but effective animation — from an to a . This tiny detail, coupled with the broader view transition, clarifies the navigation action taken. Details such as this contribute to a sense of fluidity throughout the app and quickly compound over time. 1x 0.5x

A pet peeve of mine is when a component already visible on the screen unnecessarily duplicates itself during an animation. If a component occupies a space and will persist in the next phase of the user's journey, it should remain consistent.

This concept of fluidity goes hand in hand with our dynamic tray system. We’re able to create interactions of trays morphing into full screen views, buttons gliding across trays, buttons morphing into trays and back again, and so on. Every interaction feeds into the next.

These interactions aren't easy to create, but the seamless transitions within Family are more than just technical achievements. They're a manifestation of our respect for the user's sense of space and movement within the app.

In contrast, when my banking app displays a glitchy animation while accessing my checking account, it erodes my trust. It makes me question whether the app truly understands what I'm trying to do or if it can execute my actions accurately. With Family, the consistent, smooth interactions communicate a clear message: "I know exactly what you need — let me get that for you…"

Mastering delight is mastering selective emphasis. It’s about knowing where, when, and how to apply magical moments intentionally across a product.

We don’t intentionally diminish moments of delight in our less common features — we try to insert delight with varying degrees of ‘intensity’.

We leverage the element of surprise in a few places, such as on the QR code screen in Family. The feature is used just enough to make an easter egg placed here enjoyable rather than annoying. In this instance, the magical moment is hidden in plain sight. When the user taps on the QR code, it triggers a gentle ripple effect.

For features encountered less often, the opportunity to inject delight significantly enhances the user experience. For frequently used features, the value of adding further delight gradually diminishes. While our frequently used features are always crafted to be inherently delightful, it's often the delight in the less utilised features that leave a more lasting impression.

No matter the context, the ‘specialness of a moment' generally decreases with repeated encounters. Eating your favourite candy will get progressively less enjoyable with each piece, etc. (unless they are Nerds Gummy Clusters) Let’s take a very commonly used feature as an example of where doing too much would quickly diminish potential delight. As mentioned earlier, sending tokens is a core feature and something many users do daily. It’s therefore important for it to be efficient and enjoyable, without being overbearing. Our approach here was to focus on the little things. In this case, the commas when inputting a number shift visually from place to place as the number is inputted.

When adding tokens or collectibles to the trash, they visually tumble into a skeuomorphic trash can. Completing the action plays a satisfying sound effect.

Activating stealth mode is accompanied by a gentle shimmer effect when active. This effect signals that although your holdings' values are concealed, they continue to update discreetly in the background.

In all of these features, we're not just trying to entertain the user4. These moments are our way of valuing and rewarding the user's time and emotional investment in Family. They transform something mundane into something memorable.

The true value of Family lies in making every day interactions with the wallet a little easier, a little more seamless, and a lot more enjoyable. This philosophy shapes every aspect of the product.

Make readers want to keep reading to find out how you got to that point. Practically speaking, a full-width banner image with bold colors and appropriate branding, as well as a mockup or two (mirroring your homepage thumbnail) is the most effective. Follow this with a short paragraph of what the project is about and its background. You should also include a list of details such as the project duration, how big the team was, tools used, and most importantly, what your specific role in the project was.

Following this, make your problem statement bold and clear. It doesn’t have to be too formal. Juxtapose this with your solution. This could be a parallel statement, or a combination of words and graphics once again showing your final product, but more specifically highlighting sections or screens that demonstrate how it solves the problem you just stated.

Everything you’ve written up to this point should be enough to give the casual reader a good idea of the project background and what the final product looks like. They’d probably be fine moving on to another page on your portfolio. But for people who want to read more on this case study, make sure to clearly but concisely tell everything that relates to the work that you did. Structure the rest of your case study after the introduction like this: Research — E.g. competitive analysis, interview and survey results, and personas (if any). User flow(s) — Important to give an idea of how the app is meant to be used. Ideation — E.g. information architecture/site map, sketches, low-progressing-to-high fidelity wireframes, usability testing feedback, annotated iterations, and before/after examples. Final design — Complete prototype containing your highest fidelity wireframes. You could walk through a specific user flow, or just showcase different screens. Here is where gifs, an embedded prototype (more on this later), and demonstration videos should be placed. Conclusion — All good pieces of writing need a conclusion to stick the landing. Talk about next steps first, because readers’ minds are still on the prototype. Then, if applicable, mention direct impacts of the work you did, such as specific growth or revenue metrics. Then, give it a personal touch by talking about what you thought of the project, and the lessons learned.

we introduced something new—a concept no one had tried before: We abandoned volume-based pricing, offering unlimited forms and responses for free We created a modern form-building experience—no drag-and-drop, just a beautifully simple interface that works like a text document

Each level gives you completely different information, depending on what Google thinks the user might be interested in. Maps are a true masterclass for visualizing the same information in a variety of ways.

Viewing the same text at different levels of abstraction is powerful, but what, instead of switching between them, we could see multiple levels at the same time? How might that work?

A portrait lens brings a single subject into focus, isolating it from the background to draw all attention to its details. A wide-angle lens captures more of the scene, showing how the subject relates to its surroundings. And then there’s the fish eye lens—a tool that does both, pulling the center close while curving the edges to reveal the full context.

A fish eye lens doesn’t ask us to choose between focus and context—it lets us experience both simultaneously. It’s good inspiration for how to offer detailed answers while revealing the surrounding connections and structures.

Imagine you’re reading The Elves and the Shoemaker by The Brothers Grimm. You come across a single paragraph describing the shoemaker discovering the tiny, perfectly crafted shoes left by the elves. Without context, the paragraph is just an intriguing moment. Now, what if instead of reading the whole book, you could hover over this paragraph and instantly access a layered view of the story? The immediate layer might summarize the events leading up to this moment: the shoemaker, struggling in poverty, left his last bit of leather out overnight. Another layer could give you a broader view of the story so far: the shoemaker’s business is mysteriously revitalized thanks to these tiny benefactors. Beyond that, an even higher-level summary might preview how the tale concludes, with the shoemaker and his wife crafting clothes for the elves to thank them.

This approach allows you to orient yourself without having to piece everything together by reading linearly. You get the detail of the paragraph itself, but with the added richness of understanding how it fits into the larger story.

Chapters give structure, connecting each idea to the ones that came before and after. A good author sets the stage, immersing you with anecdotes, historical background, or thematic threads that help you make sense of the details. Even the act of flipping through a book—a glance at the cover, the table of contents, a few highlighted sections—anchors you in a broader narrative.

The context of who is telling you the information—their expertise, interests, or personal connection—colors how you understand it.

The exhibit places the fish in an ecosystem of knowledge, helping you understand it in a way that goes beyond just a name.

Let's reimagine a Wikipedia a bit. In the center of the page, you see a detailed article about fancy goldfish—their habitat, types, and role in the food chain. Surrounding this are broader topics like ornamental fish, similar topics like Koi fish, more specific topics like the Oranda goldfish, and related people like the designer who popularized them. Clicking on another topic shifts it to the center, expanding into full detail while its context adjusts around it. It’s dynamic, engaging, and most importantly, it keeps you connected to the web of knowledge

The beauty of a fish eye lens for text is how naturally it fits with the way we process the world. We’re wired to see the details of a single flower while still noticing the meadow it grows in, to focus on a conversation while staying aware of the room around us. Facts and ideas are never meaningful in isolation; they only gain depth and relevance when connected to the broader context.

A single number on its own might tell you something, but it’s the trends, comparisons, and relationships that truly reveal its story. Is 42 a high number? A low one? Without context, it’s impossible to say. Context is what turns raw data into understanding, and it’s what makes any fact—or paragraph, or answer—gain meaning.

The fish eye lens takes this same principle and applies it to how we explore knowledge. It’s not just about seeing the big picture or the fine print—it’s about navigating between them effortlessly. By mirroring the way we naturally process detail and context, it creates tools that help us think not only more clearly but also more humanly.

people mix up two very different types of pivots and that it’s important to differentiate which path you’re on: Ideation pivots: This is when an early-stage startup changes its idea before having a fully formed product or meaningful traction. These pivots are easy to make, normally happen quickly after launch, and the new idea is often completely unrelated to the previous one. For example, Brex went from VR headsets to business banking, Retool went from Venmo for the U.K. to a no-code internal tools app, and Okta went from reliability monitoring to identity management all in under three months. YouTube changed direction from a dating site to a video streaming platform in less than a week. Hard pivots: This is when a company with a live product and real users/customers changes direction. In these cases, you are truly “pivoting”—keeping one element of the previous idea and doubling down on it. For example, Instagram stripped down its check-in app and went all in on its photo-sharing feature, Slack on its internal chat tool, and Loom on its screen recording feature. Occasionally a pivot is a mix of the two (i.e. you’re pivoting multiple times over 1+ years), but generally, when you’re following the advice below, make sure you’re clear on which category you’re in.

When looking at the data, a few interesting trends emerged: Ideation pivots generally happen within three months of launching your original idea. Note, a launch at this stage is typically just telling a bunch of your friends and colleagues about it. Hard pivots generally happen within two years after launch, and most around the one-year mark. I suspect the small number of companies that took longer regret not changing course earlier.

ou should have a hard conversation with your co-founder around the three-month mark, and depending on how it’s going (see below), either re-commit or change the idea. Then schedule a yearly check-in. If things are clicking, full speed ahead. If things feel meh, at least spend a few days talking about other potential directions.

Brex: “We applied to YC with this VR idea, which, looking back, it was pretty bad, but at the time we thought it was great. And within YC, we were like, ‘Yeah, we don’t even know where to start to build this.’” —Henrique Dubugras, co-founder and CEO

Things seemed to go well at the beginning. Due to the pandemic and the objective challenges of the traditional Brick & Mortar business, the business operated by Nike Direct (the business unit in charge of DTC) was flying and justifying the important strategic decisions of the CEO. Then, once normality came back, things slowly but regularly, quarter by quarter, showed that the separation line between being ambitious or being wrong was very thin.

In 6 months, hundreds of colleagues were fired and together with them Nike lost a solid process and thousands of years of experience and expertise in running, football, basketball, fitness, training, sportwear, etc., built in decades of footwear leadership (and apparel too). Product engine became gender led: women, men, and kids (like Zara, GAP, H&M or any other generic fashion brand).

Consumers are not so elastic as some business leaders think or hope. And consumers are not so loyal as some business leaders think or hope. So, what happened? Simple. Many consumers - mainly occasional buyers - did not follow Nike (surprise, surprise) but continued shopping where they were shopping before the decision of the CEO and the President of the Brand. So, once they could not find Nike sneakers in “their” stores – because Nike wasn’t serving those stores any longer -, they simply opted for other brands.

Until late 2010s, Nike had been on a total offense mode (being #1 in every market, in every category, in every product BU, basically in every dimension), a sort of military occupation of the marketplace and a huge problem for competitors that did not know how to react under such a domination. The strategic focus was only one: win anywhere. The new strategy determined the end of the marketplace occupation. Nike opened unexpected spaces to competitors, small, medium, or large brands (with exception of the company based in Herzogenaurach, that – as they usually do - copied and pasted the Nike strategy and executed it in a milder format).

One of the empiric laws of business says that online, the main lever of competition is “price” (as the organic consumer funnel is built on price comparison). The proverbial ability of Nike to leverage the power of the brand to sell sneakers at 200$ began to be threatened by the online appetite for discounts and the search for a definitive solution to the inventory issue. Gross margin – because of that – instead of growing due to the growth of DTC business, showed a rapid decline due to a never-ending promotional attitude on Nike.com

Nike has been built for 50 years on a very simple foundation: brand, product, and marketplace. The DC Investment model, since Nike became a public company, has been always the same: invest at least one tenth of the revenues in demand creation and sports marketing. The brand model has been very simple as well: focus on innovation and inspiration, creativity and storytelling based on athletes-products synergy, leveraging the power of the emotions that sport can create, trying to inspire a growing number of athletes* (*if you have a body, you are an athlete) to play sport. That’s what made Nike the Nike we used to know, love, admire, professionally and emotionally.

What happened in 2020? Well, the brand team shifted from brand marketing to digital marketing and from brand enhancing to sales activation.

shift from CREATE DEMAND to SERVE AND RETAIN DEMAND, that meant that most of the investment were directed to those who were already Nike consumers

as of 2021, to drive traffic to Nike.com, Nike started investing in programmatic adv and performance marketing the double or more of the share of resources usually invested in the other brand activities

the former CMO was ignoring the growing academic literature around the inefficiencies of investment in performance marketing/programmatic advertising, due to frauds, rising costs of mediators and declining consumer response to those activities.

Because of that, Nike invested a material amount of dollars (billions) into something that was less effective but easier to be measured vs something that was more effective but less easy to be measured.

To feed the digital marketing ecosystem, one of the historic functions of the marketing team (brand communications) was “de facto” absorbed and marginalized by the brand design team, which took the leadership in marketing content production (together with the mar-tech “scientists”). Nike didn’t need brand creativity anymore, just a polished and never stopping supply chain of branded stuff.

He made “Nike.com” the center of everything and diverted focus and dollars to it. Due to all of that, Nike hasn’t made a history making brand campaign since 2018, as the Brand organization had to become a huge sales activation machine.

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.

We are simultaneously woefully mired in legacy problems and yet poised for a big leap forward.

As filmmakers, a powerful step forward is merely to recognize that there exists a special skill set unique to a proper color scientist that has little to no overlap with the important but different expertise of a colorist, an on-set digital imaging technician, or a workstation engineer.

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.

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.

Multilevel analysis findings confirmed that daily monitoring was negatively associated with daily felt trust, which in turn had a negative impact on subordinates' daily well-being in both contexts. Furthermore, we found that monitoring variability intensified the negative relationship between daily supervisor monitoring and subordinates' daily felt trust in the newly introduced remote working context, although not in a more stable context. We discuss the theoretical implications of our findings and derive a research agenda to study the daily dynamics of monitoring and its implications for organizations.