How to Think Like a UI Engineer

Aniket Paul
Apr 15 · 6 min read

I was recently having a discussion with my friend (a seasoned backend engineer) and I casually said, “It will not take me much time to learn how to code in a backend programming language” 😝. To which he surprisingly replied, “While that is true given you already know how to code, what will take time is to think like a backend engineer coz that is learnt/gained with experiences and hours and hours of debugging sessions and getting numerous code errors.

That got me thinking - What if this is the same challenge that is faced by many developers/engineers who are just starting with UI development. They might just not know how to think like a UI engineer…
On that note let’s start this article.

In this article, I’ll share how I approach creating a UI application or a feature.
I do not claim this approach to be ironclad nor to be something unique that I have created; this is just a way how I design my UI application.
Small Disclaimer:
1. I will be using ReactJS for my example, but this should not stop you from tweaking it a little and implementing it in your framework or library.
2. Basic knowledge of State and Props in React is a prerequisite.

It’s my TV unit wanted something real :P

Let us assume we have received this design from our Experience designers. How do we approach it?

Step 1: Create a mental model
Our first exercise would be to start by creating components in mind. That is, identify smaller components that you would create when you code. Components that would exist together (under the same root) and would be displayed together. How to do that? Start by breaking the design into sections like this.

Container Segregation

In the image we can see I have created 4 sections,
Container Components A, B, C and D.
Idea is, when I will start writing my code, I will start by creating 4 containers and render them together as that would give me the entire design.

Now, with Hooks we don’t need Containers and Presentational components to be separate and we will also maintain that but it becomes easier to explain when we separate them specifically.

Step 2: Identify common components
Self-explanatory - look for smaller components which can be reused. They could be in your component folder and Containers will import them, pass props to them and determine how they look and react to user actions. Let’s take a closer look.

Component visualisation

As the image suggests, we will have to create three components and then reuse them in our Containers.
Components:
1. Cabinet: Can be vertical or horizontal.
2. Drawer
3. EmptyBox: Can be lit and big or small.

Container component:
1. A will use Components, Cabinet which is horizontal and EmptyBox which is lit and bigger.
2. B will also use Components, Cabinet which is Vertical and EmptyBox which is lit and small.
3. C will use Components, Drawers and EmptyBox which is big and not lit.

How will these components behave differently? Simple, using Props.
Let us consider the component EmptyBox. It will accept the props light and size and render accordingly, i.e., if we pass
<Emptybox lights={true} size={“big”}/> will render BlueBox Component in Container A.
<Emptybox lights={true} size={“small”}/> will render the small BlueBox Component in Container B.
<Emptybox lights={false} size={“big”}/> will render BlueBox Component in Container D.

Step 3: Start state management early.
Once we have an idea on how to structure our components, comes the important part, State management. (If you want to understand what is State management and how to implement one please take a look at this article. I wrote it some time back explaining State Management of ReactJS Apps Using useReducer and useContext). It’s one thing we definitely need to sort out before we start writing our code or else, as our application grows, it will become impossible to structure it or maintain it later.

I like to design the components around the global State. The intent is to get all component actions to modify the global state via dispatches, which in turn will trigger re-renders and show the desired effect on these components.
Let us consider a use case to understand this better.
Use Case: On clicking a component, we will Zoom In the container or else it will remain in Zoom Out state .
Based on what we have seen so far i.e how the individual components behave and what the use case is, this is how I will structure my components.

As shown in the image above, we have identified what will be in our local state and what will be read from Global state.
But how to decide this? I follow this rule: Properties that are responsible for only manipulating the behaviour of an individual or specific components/containers should be part of the local state. Properties which can be shared across all components, which determine how the product as a whole should behave should be in Global State.
For our example, props like light, size and cabinet directions(vertical and horizontal) are part of the local state as they determine how Components inside Containers should render.
We keep only zoomedInComponent in Global state. Coz that is a prop that can be used by all the components. So now that we have established this, let’s see how our Components will behave.
As mentioned in the image above in point c, onClick we will trigger a dispatch with zoomedInComponent value. Once that modifies the Global State, all components subscribed to it will re-render having the updated state of values from Global State. For eg. if ComponentA was clicked then the Global State value of zoomedInComponent will become “A” which when read by ComponentA in the next render would make it zoomIn or Expand. Other components will remain in their status quo unless clicked upon.

Step 4: Deciding where to keep actions/effects i.e functions
This will come up once you start working with many chained components inside a component or Container. What happens is, we will be always tempted to add functions on root level and drill them down to child components via props.
As our project size and features increases, the root component also bloats proportionally making code very hard to maintain and read.
The policy I follow is to ask a few questions:
1. Is this function of any use to the component where it’s getting added? If not can we place inside the component where it’s actually used.
2. Is this function going to be one of those utility functions that will be used by multiple components? In that case won’t it be wise to place it in a utility file?

These decisions can be made only when we have structured code following the above 3 steps. One thing we should remember is, due to state management implementation, state and dispatch is now available to all components. Which results in making data and the power to manipulate it available in all levels. This is massive as it makes the components more independent and allows us to avoid prop drilling wherever possible.

Finally Step 5: Coding
Well we are all aware of this step. But I would suggest to start this step only when you have sorted out the first 3 Steps, coz Step 4 and 5 go hand in hand .
Following the coding patterns, writing clean code, adding test cases and etc. are some of the most common instructions that we are all aware of and we should always keep in mind while coding. I won’t add much to this section as I’m sure the people who are reading this article are more than proficient in this part and I will leave this topic for another article 😝.

So that’s about it! It’s all that I wanted to share. This article is just the tip of the iceberg when it comes to thinking like a UI engineer. There are lots of other aspects that we have to think about when we actually start to code. But this article is aimed at serving as a starting point for your application design.
Hope you found some value out of it. In case you feel I should add or edit anything, feel free to post that in the comments I would be happy to take in your feedback.

Thank you n Happy Coding!!

Geek Culture

Proud to geek out.

Sign up for Geek Culture Hits

By Geek Culture

Subscribe to receive top 10 most read stories of Geek Culture — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Geek Culture

A new tech publication by Start it up (https://medium.com/swlh).

Aniket Paul

Written by

Been working on JS for the last few years. At present I’m a SSE at Intuit focusing predominantly on UI. www.linkedin.com/in/aniket-paul-0400279a

Geek Culture

A new tech publication by Start it up (https://medium.com/swlh).

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store