Speaking of web layouts…introducing the Magic Hat technique 🎩✨

A recipe for happy designers, happy developers, but most of all, happy users.

Albino Tonnina
6 min readMar 26, 2018

Once upon a time (few weeks ago), I was asked to work on a new product.
Start solo with UI & FE, it’s greenfield, feel free to experiment.” I guess that my response, something like, “all right,” was a bit underplayed.

In case you were born after they stopped doing nice kids movies, this is The Neverending Story, 1985.

Sadly, a couple of long, long weeks later, I didn’t have a clue about how to build an interface for this application.

I said “ok, think, we’re gonna need a header, we’re gonna need a footer, and we’re gonna need a sidebar. That’s all I know. We will then start making pages and we will put the important stuff in the remaining white space, you know, the app, the <main>, the core, the juice, the whatever the user should be playing with.”

Something like the next picture here, right?

This is my canonical idea of a web app

I said to myself: “No! Wrong! I already put myself in a cage and I’m barely prototyping! These flows are too complicated to be packed into these A4/Letter frozen frames,” I said.

“I’m gonna spend ages figuring out the user flows here. Let’s change perspective. Let’s go all the way holistic on this!” I said it out loud this time (I’d gotten a bit dramatic at that point).

I wanted to make something complex look very simple. I wanted to give the user a strong feeling of control. I wanted a smart app and I wasn’t sure I was doing the right thing here.

Procrastination to the rescue!

I was obviously looking at my phone to enjoy a totally deserved break after these intense brainstorming sessions between me and myself.

You know, mobile UIs look so clear compared to the ones I build for web apps. The UX there is just right, the cognitive load is low, the motions are just yummy.

That and React, that’s where this idea of the Magic Hat technique came from. And lots of energy drinks.

The declarative, functional, reactive sides of React, mostly, and the modularity.

🖼 The MUV

I’ve got this image of a Minimum Usable View, a piece of UI that would do just one thing, in isolation, almost pure, like we do in code. Something the user could center with, concentrate on, work with. Something like React components! Smart bricks in a bucket that do one thing that you, or the user, let’s say, can put together.


Two MUVs could be better than one, actually, if they somehow complement each other. Not three, definitely not four — that would be a lot to process for my brain.

Two MUV (Minimum Usable Views), totally made up acronym by the way.

Looks like a one window drill-down UI pattern but with two, ahem, MUVs. 😎

When everything’s on one screen or window, the options at each stage are clear, and the user knows they don’t need to focus their attention anywhere else.

Quite good for user’s cognitive load: there is not much going on inside the screen, just what you want the user to focus on.

Each MUV can and should be designed in almost complete isolation, like a black box: things get in, the data, and things get out, something like declarative intentions. The user expects to do that on the next frame.

Yes, because, like a Linked list, each MUV sets what goes next.

A Linked List, that as its name says, is a linked list of nodes that are represents by a head that is the first node in the list and the tail that is the last one. Each node has a reference/pointer to the previous and the next node.


The thing is that at any given point, the screen is showing you only two related pieces of UI.

The right view is something the user wanted to happen in the left view, which is the right view of a previous left view, which is the right view of a previous left v…
…which is the right view of the first view.

The motions

Naturally, a technique like this really depends on motion. The UX in Motion Manifesto is a must read article.

Of the 12 principles it describes, I think the ones that apply the most are:

3) Parenting: Creates spatial and temporal hierarchical relationships when interacting with multiple objects.

6) Masking: Creates continuity in an interface object or object group when utility is determined by which part of the object or group is revealed or concealed.

By the way, why this name, the Magic Hat technique?

So I can use these two emojis together 🎩✨ . And, well, it’s like that: in a view, the user can pick the next thing to put on screen. It’s pretty much that.

🏖 The code sandbox

First, a basic, basic demo in React to show the mechanics.

🎡 The actual demo

The following one is a little app I put together. I hope it gives you the idea.
From a technical point of view, each MUV is naturally independent so building an app like this is quite trivial, since you build each UI in isolation. The piping in the UI is done by the implementation of this technique (I did one in React). The views get the space they want by the way and they can be styled anyway you like. I like to have mine flex. I love flex.

Check out this link.


Imagine how scalable this could be. Adding a feature (one or more MUVs) would not break any layout. You just pipe in new MUVs and add links so you can open them from any other MUV.

For the user, this should be kinda natural if you think about it. It’s not different from the browser experience with the back and forward buttons. It actually works the same way. It’s the user that creates their own path.
This path would be the list of MUVs that the user chooses to open, a list ready to be persisted or tracked.

🛠 The React library

This is something I would never dream of doing without a UI framework such as React, or Vue, or the next one probably.

Introducing react-magic-hat 🎩✨


⚡🚀 Blazing fast. 60+ FPS hardware-accelerated CSS transforms, using the FLIP technique. Fluid and performant.

🎈Extra light, only 6.5kb and no dependencies.

🧘‍‍Flexible, stateful or stateless (you get both components) and UI-less, you do the layouting and styling.

🎛 Highly configurable, hope you like the API!


This technique aims to reduce the total amount of mental effort that is required to complete a task involving the processing of information (in short, cognitive load). It does this by limiting the amount of UI on the screen in favour of a runtime-like linked list of sequential independent UIs called MUVs (Minimum Usable Views).

I don’t know how much of an app you can make using this technique, or if the previous sentence makes any sense to you, but so far I’ve been satisfied every time I did experiments with it.

We should definitely never stop experimenting and pulling things out of our magic geeky hats 🎩✨

If you like the idea, write me a comment, tell me what you think, and do the clapping thingy if you like!

A special request: I just re-joined Twitter with my account, and I don’t have many friends there. You would make my day if you would follow me :)

Thank you!