Storytelling for Frontend Engineers

Bob Fanger
5 min readSep 12, 2021


Storytelling is a useful technique for building interfaces and in this article I will show you how to make components speak for themselves.

Let’s say you have been given the following design:

Figma design of a Number Control

You start writing the HTML, CSS and Javascript code and some time later you’ve created the following component:

Interactive Number Component

Is the job done?
Yes, it is, the component is fully functional and it is Good Enough.

Can we improve the component? 👷 Yes we can!

This component contains two buttons, what is a story a button can tell?

“I can be clicked”

It already looks like a button, so it has that going for it, but we can enhance telling the story by letting the button react to hovering the cursor over it.


Here we’ve added hover effects: changing the cursor to a pointer and changing the colors.

A button has another story to tell which is:

“I am clicked”

I believe clicking is one of the most powerful things a user can do. Clicking has so much potential, but the effect of a click is not clearly visible: the web rarely acknowledges them.


Here we’ve added styling for the active state. We have greatly changed the appearance of the buttons by inverting the colors.

Are you done? Yes, you already were, but this is much nicer.

Can we still improve the component? 👷 Yes we can!

To improve the component, we can add animations. Let’s dive into why.

Kinetic energy

In the real world, every movement and change is created by energy, so when choosing easing and timing it’s useful to think about what kind of moment you want to replicate.

Imagine a ball being kicked by a soccer player.

Steve kicking an imaginary ball

If you would animate that ball, you’ll know instinctively which easing to pick:

(You’d instinctively pick the ease-out)

A real ball would be affected by wind, has friction while it bounces on patches of grass and will take quite some time to come to a complete standstill. So when you replicate the motion you want to animate, embrace the digital nature of our interfaces; enhance the speed of movement and use cleaner curves.

Having the animation grounded in reality helps to make the UI feel intuitive. When choosing the easing and duration for an animation try to adhere to the general rule that UI animations shouldn’t be noticeable. I recommend experimenting with concepts like springs, magnetism and small explosions and observe how that affects the feel of the component.

Animations should be felt, not noticed

A click or a swipe has initial energy, and using an ease-out is generally preferred. There are exceptions, for example if you click on the arrow of a dropdown, the arrow itself can be animated using an ease-out, but I’d choose an ease-in-out for the appearing options.

In short: animation allows us to let the users register and feel the impact of their actions.

Why don’t we get back to our component to add animations:

Animated Number Control

Here we have added transition to the hover, a small duration for the mouse-in and a larger duration for the mouse-out. This tells of the willingness to be clicked and that it’s almost disappointed that it didn’t get clicked.

When the user clicks, the colors are inverted instantly and it fades back to hover state. This tells the user that it has been clicked and the fading provides time to let the user register that. It also tells that it received energy from that click and needed some time to adjust back to normal. This communicates what is happening and that the user is in control.

Ok, now we’ve added hints and animations, we’re done, right?

Well… maybe we can still improve the component? 👷 Yes, we can!

So, the buttons are telling their stories, but the component is not just two buttons and input. It’s number control with it’s own stories to tell as well. Like:

“The nummer is incremented”

Odometer animaton

This animation is not needed; users are smart enough to guess what the effect of the [-] and [+] would be, but the effect provides a reaffirmation of what is happening and communicates very clearly what has changed.

The user knows what happened, because they saw it happen: this reduces the cognitive load when using a user interface.

We have also toned down the clicked animation from the previous step (where we inverted color and faded out the click on the buttons) because the user’s attention should go to the number. The button is not the important part and it would be distracting if the button was still animating while the number was already in place.

Don’t tell me we can still improve the component? 👷 Yes, we can!

You can imagine this component might have a minimum or maximum value; or an invalid state; or other stories it wanted to tell. It can be interesting to practice with these questions and build your answers according to the answers you come up with.


Designers are creating the look, frontend engineers are creating the feel.

So next time you’ll get a design for a component, ask yourself the question:

What are the stories this component wants to tell us?