Time is important to us. You could even say that time is extremely important to us. And given the fact that this article is called “The Importance of Time in UX Design,” you probably think that I will discuss the importance of time management. But no. I want to talk about the time that occurs in our brains. This article is about the importance of how time occurs within and is registered by our brains, as well as our system of perception needed to function and perform basic actions.

In this article I will determine:

• How does time affect our perception

• How does our brain function within the confines of time constraints

• How can we use some of these issues to our advantage in UX design

What is our perception of time?

We are constantly faced with issues of time and time management. For example, we know that in order to cook chicken in the oven, we need 1 hour, or in order to get from home to the store at a steady pace we need at least 10 minutes. For us, these numbers are conditional time constants that we use to plan our actions.

“Our brain also has time constants.”

Time constants are moments of doing and behavior that our brains have standardized. So, our brain has these time constants and, unlike the store example, these constants are quite objective for every person. The time of each reaction and each action of our brains has actually been tracked by neuroscientists down to milliseconds. And, in fact, understanding the timing of these reactions is crucial for UX design.

How can brain time rules help in UX design?

Understanding and using the time constants of human perception will not help you create a more effective or beautiful product. However, understanding so-called “brain time rules” will help make your product more responsive to users. If your product is well synchronized with the user’s internal time requirements, then in the end it will be much more important for the user than the product’s efficiency or even layout.

“Understanding and using the time constants of human perception will help make your product more responsive to users.”

To better understand this, let’s look at an example. Let’s say, for instance, that your toaster has broken, and you have decided to take it to an expert repairman to have it fixed. There are two workshops in your area. The first is called “Sensitive workshop.” Here you will receive an order and the repairman will inform you about it, they will say how long it takes to diagnose a breakdown, and then they will say how long it takes to repair and will offer you to refuse the repair service if it does not fit your needs or schedule. The second workshop is called “Very, very fast,” and you heard that the equipment is being repaired really fast there. If you go there and hand your broken toaster to the repairman, he will not say a word to you about whether or not he started repairing your toaster, if it has broken at all, how long the repair will take, and you do not know if you can refuse to have it repaired. So what workshop do you take your toaster to?

In fact, the software can act similarly. For example, one application will copy your document for 30 minutes, but it will tell you that it will do just that much and will offer you the option to refuse to copy, and the second will perform the same action in 10 minutes, but will not tell you about it, and in general it will not interact with you. In fact, the second application does its job more efficiently, but the first will appeal to users much more.

Temporal constants of our brain and their application in UX design

In fact, there are a lot of time constants in the activity of our brain, however, there are only about 20 basic ones, and while we don’t need all of them, some of them are very necessary. We will not delve into the most minimal time constants, but rather focus on the most important.

0.1 second

That is the amount of time in which your brain fixes a causal relationship. Roughly speaking, if you print a document and the time interval between pressing a key and the appearance of a letter on the monitor screen exceeds 0.1 seconds, then the perception of the cause-effect relationship in your brain is destroyed, and you begin to doubt whether you pressed the right button, will likely start to press it once again, and you may also start to get nervous and experience negative emotions.

“Adjust the operating time of your product to the user’s time requirements”

As a result, we can conclude that the program or application should give the user a response to its action within 0.1 seconds. If the program cannot perform the required function, then within 0.1 seconds it should give the user a response that the function is running and show a busy indicator. Thus, the user will save the causal relationship of his actions with the program and will not have doubts.

1 second

This fleeting period of time is very clearly fixed by our brains. Suppose you are talking to a friend reading a book at the same time. Your attention is essentially divided into two streams. And your friend should interrupt his speech for exactly 1 second so that your brain turns 100% of its attention to your friend. If the pause in your friend’s speech is less than 1 second, then your brain will not notice this pause, and you will continue to do what you did. But as soon as a pause crosses the line of 1 second, your brain immediately pays attention to it. To create software, this constant can be used as follows. If the program, during interaction with the user, makes a delay in its activity, which will last more than 1 second, then the program should report it, otherwise, after this second, the user will be surprised and possibly even puzzled.

10 seconds

Ten seconds is the time a person spends on one short-term task. If a task requires more than 10 seconds to complete, then the brain ceases to perceive this task as one action and tries to break it down into several actions, the duration of which will fit into a 10-second interval. Thus, each short-term action that the user must perform while using your product should take up to 10 seconds and no more. If this action takes 15 or 20 seconds, it would be more expedient to divide this task into two subtasks. In this case, your user will not lose patience and will feel comfortable. For example, in your application, if the user needs to fill out a form or make a certain setting you will need to test how long this action takes and, if necessary, break it down into user-friendly 10-second steps.

100 seconds

About 1.5 to 2 minutes is needed for us humans to make a critical decision in an emergency. This is good, of course, you say, but how will this help us in UX design? Here is the answer.

“Put all the necessary information right under the users’ nose”

If your application, product, or system provides a process in which the user must make a critical decision, then you should take care that all the information necessary for making this decision is as accessible as possible and right before their eyes. After all, the user has 100 seconds to process this information and make a decision, and he will not want to spend a second on its search.

Conclusion

Based on these constants, we can draw certain conclusions. When you create a product, you know what functions your product performs, how complex they are, and how long they will last. Knowing the time frame and boundaries of user perception, you can redistribute resources, use employment indicators and progress indicators, as well as adjust the tasks of your product to the user’s temporary needs, and thus make your product more responsive to the user. This sensitivity and responsiveness, in the end, will be a big plus for you, because users will not experience anxiety and frustration while using the product. This, in essence, is the main task of UX design — to make the user experience as convenient and enjoyable as possible.

Isn’t React for engineers?

I love this question. Because not too long ago, the question was: “Isn’t programming for engineers?”. This implies that we’ve since established that it isn’t. You don’t have to be an engineer to code. And you need “enough code to be dangerous” to greatly increase your potential for complex creative expression.

When designers talk about code, it’s most often in the context of designing interfaces. And the way we think of interface composition is in elements, like buttons, lists, navigation, etc. React is an optimized way to express interfaces in these elements, through components. It helps you build complex interfaces (and even simple interfaces get complex quickly) in an efficient way. By organizing your interfaces into three key concepts— components, props, and state—you can express anything you can think of and get all these things easily:

• Clear structure and rules to help organize your code, so you don’t have to start over at a certain complexity.

• A way to isolate, compose, and re-use parts of your code between projects and across teams in the form of simple components or even complex design systems.

• Good rules to collaborate with others, as everything is built in a similar way.

React is a smart way to organize old interface code using simple concepts and rules. Saying that it‘s only useful for engineers would be like saying that no amateur photographer should ever buy a Leica. If you have the opportunity, why not work with the best tools?

Why does React seem so hard?

I’ve noticed that designers with experience building interfaces in jQuery, ActionScript, or (ironically) Framer Classic tend to struggle with React.

This has little to do with React and everything do to with programming models. The examples mentioned above use an imperative model, while React uses a declarative model. Let me explain the difference…

Imperative model

Much like giving someone step-by-step directions to cook a dish, an imperative model requires you to describe the exact steps to achieve a change.

Declarative model

A declarative model describes changes as before and after and lets the computer figure out the steps in between…much like ordering your custom frappuccino.

As designers, we’re used to working declaratively. Every timeline application where you tween between two states is a fantastic example. You describe before and after, and the computer figures out the tween.

Let’s try to look at this from a programmer’s perspective and build a simple login flow. This is not real or complete code, it just tries to illustrate the difference in approach.

The imperative app uses (fake) jQuery to describe exactly what to change if something happens. This should look familiar if you’ve used it a lot.

$("button .login").onClick(() => {
 $("form").attr("enabled", false)
 $("body").append($("div.spinner"))
 doLogin((success, username) => {
 if (success) {
 $("form").remove()
 $("div.spinner").remove()
 $("body").append($(`Welcome back ${username}`))
 } else {
 $("form").attr("enabled", true)
 $("form.error").text("Could not login")
 $("div.spinner").remove()
 }
 })
})

$("button .login").onClick(() => {
 $("form").attr("enabled", false)
 $("body").append($("div.spinner"))
 doLogin((success, username) => {
 if (success) {
 $("form").remove()
 $("div.spinner").remove()
 $("body").append($(`Welcome back ${username}`))
 } else {
 $("form").attr("enabled", true)
 $("form.error").text("Could not login")
 $("div.spinner").remove()
 }
 })
})

The declarative (fake) React code describes the three different states of the app: logged_out, logging_in and logged_in. It seems to completely re-render your app at every change, but the trick is that under the hood it figures out all the differences and only updates those so that everything stays as fast as possible.

function App({ state = "logged_out", username = null }) {
 if (!state === "logged_out") {
 return <Login />
 }
 if (!state === "logging_in") {
 return <Spinner />
 }
 if (!state === "logged_in") {
 return <div>Welcome back {username}</div>
 }
}

I hope these examples have illustrated why the declarative model makes a lot of sense for building interfaces. It does require a bit of a mind-shift if you have gotten used to the imperative model, but it’s ultimately worth it.

What is application state?

Now state can refer to many things. Animators see it as a visual configuration at a specific moment in time, explicitly defined. Web designers think of it as events that trigger a CSS class like hover, press, or loading.

But React was defined by engineers and they think of state as the current internal state of your application, which is defined as what you see on the screen. So in other words, state is all the variables that make up your application. Let’s look at some visual examples.

Let’s assume this card is my entire app for now. To draw it with real data I need 7 variables in total: profile_image_url, name, handle, tweets_count, tweets_images following_count and followers_count.

So if I were to describe the state in JavaScript it would look something like this:

{
 profile_image_url: "koen.jpg",
 name: "Koen Bok",
 handle: "@koenbok",
 tweets_count: 5869,
 tweets_images: ["motion.jpg", "switch.jpg", "react.jpg"],
 following_count: 2181,
 followers_count: 11400
}

You see that these variables let me make every possible combination for this card. Much like a cold email template with variables Hello #{first_name} let’s meet for coffee.

But a full application state has way more things; from dynamic views to login fields. So let’s zoom out a little and look at an entire application state for a Twitter app.

Suddenly, there’s a lot more going on. Navigation tabs, logins, feed with loading, search etc. But nothing really changes in our approach. The state just becomes more extensive. Let’s look at what we would need to add to the above to describe the full Twitter interface state:

{
 logged_in: true, 
 selected_tab: "feed", 
 search_query: null, 
 tweet: null, 
 feed_loading: false, 
 feed: [
 { id: 123, name: "Ryan Florence", tweet: "React gave me..." ... },
 { id: 456, name: "Krijn Rijshouwer", tweet: "Say hello to" ... },
 ]
}

You can see how these are all the variables that we need to show the application, neatly stored together. If we were to now write some interface code, it would look something like this (for simplicity’s sake, I’ve left some things out):

function Twitter(state) {
 if (!state.logged_in) {
 return <div>Login: <input /></div>
 }
 const feed = state.feed.map(item => (
 <div>{item.name}: {item.tweet}</div>
 ));
 return (
 <div>
 <button enabled={state.selected_tab !== "feed"}>Feed</button>
 <button enabled={state.selected_tab !== "notifications"}>Notfications</button>
 <button enabled={state.selected_tab !== "messages"}>Messages</button>
 {state.feed_loading ? <div>Loading</div> : feed}
 </div>
 );
}

This is obviously an extremely simplified version, but if you have built prototypes before this should look really familiar. We really cleanly separated state and interface logic.

And now comes the magic moment (I hope). For me, this is the point where React really started to click. Look at the code again and notice how… simple it all is. Think about when you were building something similar in jQuery or Flash. You were likely writing a ton of:

$("#feed").click(function() {
 $("#feed").attr("enabled", true)
 $("#notifications").attr("enabled", false)
 $("#messages").attr("enabled", false)
})

They all change the page a bit and update the state. But where is the state? It’s embedded in the page, and built up over time through all the functions that cause it to change. So when you eventually run into an unexpected state (and you will) it’s really hard to easily get an overview of the state, let alone reason or reproduce it so you can debug.

React always forces you to cleanly separate state and update it at once. That way you can write extremely simple code and avoid many bugs. It’s an extremely pleasant way to work. And it’s the main reason React (and other declarative component frameworks) are dominating.

To fully close the loop, let’s see how engineers look at (and talk about) this. This part isn’t needed to get work done, but it does seems like a pity to get this far and not also try to explain some of the very-accurate-but-deliberately-hard-sounding engineering terminology. Don’t worry if you don’t get this part (or don’t care).

So if you just take the Tweet function and completely empty it out you get:

function Tweet(state) { return output } 

Or even more simplified in a mathematical notation:

Your application is a function of your state. Every time you insert the same state, you get the exact same output. You always render your entire app as a whole, so it’s extremely easy to reason about and React makes sure it’s still fast through only actually updating the changes.

If you want to go deeper on this concept I recommend Pure UI by Guillermo Rauch .

What are props and state?

This is likely the most often asked React question because it confuses so many people. But it’s honestly very simple, especially if you know some HTML. Before getting into the theory, let me show you using code. I’ll start with props because you almost always need props, but you definitely don’t always need state.

<img src="test.jpg" width="100px" height="100px" />

This element has three props: src, width and height. In HTML you would call them attributes. Programmers often call these properties; React just shortened it to props. That’s all there is to it.

Let’s say you would write your own special square image element in React, you get these passed in so you can use them:

function SquareImage({ src, size }) {
 return <img src={src} width={size} height={size} />
}
<SquareImage src="test.jpg" size="100px" />

So props are just the attributes of your components. You use them to configure your components and it’s how components get values passed in from the outside. This last part is the key difference with state.

Because sometimes your component only needs values within the component itself. That sounds weird but think, for example, about a hover state that changes text. The component itself responds to the hover state, and changes its own text.

function Hovercraft() {
 const [text, setText] = useState("Craft") 
 const mouseOver = () => setText("Hover")
 const mouseOut = () => setText("Craft")
 return <div onMouseOver={mouseOver} onMouseOut={mouseOut}>{text}</div>
}
<Hovercraft />

No outside values required, so we’re not using props, just state. It just needs a text value and that is only changed by the component itself. You can obviously mix props and state as needed.

Hooks and State

Hooks are a hip name for things you can do in a component. The most common one that you will run into is useState. It allows the component to remember some value, and update when it changes. The syntax may look a bit scary at first, but it’s really not that hard.

const [scale, setScale] = React.useState(1)

What this does is it sets the scale variable to the value 1. Much like:

So why all that other stuff? Well, when you change this scale in the future, you want to ensure the component changes with it, so it needs to update itself on the screen. In short, for React to know the value is updated, it needs a hook.

This is where the React.useState(1) comes in. It lets React know:

• Hey React! You want to keep an eye on this value here.

• Oh by the way the default value for it is 1.

React: no problem! I’ll keep track of it. Here you have two things back:

• The current value for scale (which is 1 if you never changed it).

• A function to update the value so that I know about it too, called setScale.

So the complicated looking const [scale, setScale] is just needed because React gives you back two things instead of one, and this little shortcut is a nice way to give them both names. You could actually write the exact same code without the shortcut like this:

const hook = React.useState(1)
const scale = hook[0] 
const setScale = hook[1] 

Whew, ok. I hope just enough info for you to now just use the shortcut. The last thing we need to look at is how to change the scale value with setScale. Let’s do that with a full example:

function MyComponent() {
 const [scale, setScale] = React.useState(1)
 return <Frame scale={scale} onTap={() => setScale(2)} />
}

Pretty easy; if you tap the scale gets set to 2 using setScale and React updates the component. To finish off, I’ll show you almost the same but now a little bit more explicit using the function notation I used before. This is mostly a preference, you can pick what you like better. Additionally, this example will increase the scale by 0.1 every time you tap.

function MyComponent() {
 const [scale, setScale] = React.useState(1)
 function onTap() {
 setScale(scale * 1.1)
 }
 return <Frame scale={scale} onTap={onTap} />
}

A little more code, but a little simpler looking maybe. Again, up to you. But I like this. Here is a pretty great intro if you like to learn more about hooks and build something real.

Class or function components?

There are two ways to define components in React: functions and classes. Until the recent React Hooks release, class-based functions gave you more features for your components. But thanks to React Hooks they can now both do everything, so most people stopped using class-based components.

class KoenComponent extends React.Component {
 render() {
 return <div>Hello world!</div>
 }
}
function KoenComponent() {
 return <div>Hello world!</div>
}

We built the new Framer library on React Hooks because it it simpler and ensures that beginners won’t have to learn about classes, this, etc right off the bat. It’s quite elegant really.

TLDR; use functions and learn about Hooks if you plan to get more advanced with React.

What are overrides again?

In Framer X, when you’d like to add code to canvas elements (defined as anything you draw that isn’t code), you have to use overrides. You can find overrides in the properties panel under code. Just select any object and attach the override you want. You can edit the overrides by clicking Edit Code where you’ll find that we’ve included a bunch of examples by default.

Overrides essentially allow you to modify the props before they get set in the preview. So if you have a frame of the canvas with background: white and an override like so:

import { Override } from "framer"
export function ChangeBackground(): Override {
 return {
 background: "yellow",
 }
}

…then the input from the properties starts off as a white color, but changes to yellow as the override gets applied.

Feeling confident about that? Let me show you what overrides look like in code (don’t worry if you don’t get this, it’s just helpful to understand).

function Canvas(props) {
 Object.assign(props, ChangeBackground(props))
 return <Frame {...props} />
}

Dynamic Overrides

Good news—overrides can also be dynamic. This means they get the properties that you set from the canvas are passed on, so you can use them as an input and modify them. Here’s an example that always moves a frame 50px down from its original position:

import { Override } from "framer"
export function ChangeTop(props): Override {
 return {
 top: props.top + 50,
 }
}

Events

You’ll most likely want to use overrides for interactive work so let me quickly walk you through some cool examples. These use animation functions from our API: whileHover and animate.

import { Override } from "framer"
export function Hover(props): Override {
 return {
 whileHover: { scale: 1.2 },
 }
}
export function RotateClick(props): Override {
 const [rotate, setRotate] = React.useState(0)
 return {
 onTap() { setRotate(rotate + 90) },
 animate: { rotate },
 }
}

Between components

In order for components to communicate in a way that one animates when you click another, you’ll need a way to share data between components (also see state). Framer provides you with a simple Data object that does just that. It holds your data and tells your components to update when you change it.

Let’s create a very simple project that rotates a rounded square when you click on a yellow button. They will both need an override and we’ll call those Button and Rotate.

import * as React from "react"
import { Override, Data } from "framer"
const data = Data({ rotate: 0 })
export function Button(props): Override {
 return {
 onTap() {
 data.rotate += 90
 },
 }
}
export function Rotate(props): Override {
 return {
 animate: { rotate: data.rotate },
 }
}

As you can see, they both use the data object. The Buttonoverride modifies it on a tap, and that causes the Rotateoverride to animate to its new value.