Design Frontend Web App Workflow

Web-app developer's essential workflow to create amazing UIs

Advance your web development skills with this 9-step workflow to create amazing UIs in a very efficient way.

For the last 10 years, I have been working on various web and app projects including leading the development of a rather complex angular web application. Driven by a strong passion for design, I've developed a skillset to create beautiful UIs very efficiently in HTML & (S)CSS. My colleagues used to say I am „scrubbing down" UIs, because of my speed.

I often see junior and mid-level web developers struggling with their approach to create a new UI (or UI element) from a mockup and getting it implemented perfectly. I felt it's a good idea to share my knowledge and wrote down my workflow on how I nail every UI I implement.

The workflow is independent of any coding language or framework. Just focusing on HTML and CSS. Of course a proper (G)UI cannot live without any coded logic, but I'll skip it here to be more generic. I am pretty sure the code for the UI logic isn't a challenge for you anyway. 😉

If you master this workflow and you're „scrubbing down" your next UIs in a high-quality and fast way, your career will definitely advance soon.

But before diving into the workflow, let me put some emphasis on the design of UIs and why the job of a front-end developer is crucial for the success of any customer-facing software product.

Why you should fall in love with design

UI design is the creation of the interface between a human being and a machine. The API is the interface for the developer and the machine. It's the designers job to concept a UI which works for the user. It's the front-end developers job to make this concept come alive and successfully communicate between user & machine.

Great design is not a matter of taste

How complex a UI is allowed to be and who is capable of using it, vastly depends on the use-case and the target group of the product. For some engineers using a command line interface is not a big deal — for non-engineers using a command line tool is a mystery.

Despite the fact, that user interfaces might be different for different groups of people, they all have one thing in common: to make the user achieve her desired outcome — which is never just operating your software.

Besides achieving this desired outcome, a great UI keeps the cognitive drain as low as possible.

The cognitive resources of our brain are limited per day. Wasting this limited resource on friction is harming the user experience, leading to frustration and making people spend valuable life-time on unnecessary things. You probably know the difference between a seemless online shop checkout experience and one where you aren't sure what you bought in the end.

Users don't want to operate your software. They are looking for a desired outcome by using your software. That's why the design and an intuitiv UI are essential to keep the cognitive drain low and give the user more energy to focus on her actually intended activity. This increases the acceptance of your software and your product is perceived as valuable and maybe gets recommended.

Not sure what can be done wrong in "just a simple web UI"? Try to accomplish this flow 👉 https://userinyerface.com

How do you feel now? Just some HTML & CSS has the potential to screw you up big time. Imagine this frustration while you try to buy a new pair of headphones while waiting for the bus. No new headphones I would say and definitely no shop recommendation.

Great design increases the perceived value

This is valid for the product, but this is also valid for you as a developer. Great-looking results and appealing presentations will increase the perceived value of your work.

It's called the perceived value bias. We perceive the value of a product or service based on how it looks or how it's served. Design is more important for the success of your product than you probably think. That extra space, wrong border color, and misaligned text — they all impact your conversion rates.

Creating high quality front-ends increases the perceived value of your product and therefore helps your business succeed.

The UI is your product

The UI is often everything the user is in touch with of your product. Lots of people think Instagram is just an app. All the things happening on servers in the background are easily forgotten. That's different compared to a car, where you see everything that belongs to the car besides the cockpit (the user interface). For services which work via apps it's therefore even more important to shine with a great app. That's likely everything the users will ever assume your product is.

Coming up with a great UI is the designers job. From user research to a tested UI flow. But there is tech needed to make a UI come alive and communicate between user and the API. That's where the front-end developer comes into play.

Let's assume the designer gave you a great mockup. Here is my workflow to make the UI come real.

9-Step workflow to create amazing UIs

Understand your UI
Chunking
Layout
Appearance
Content behaviour
Interaction states
Transitions
Testing & polishing
Clean up

1. Understand your UI

Keep in mind, not every mockup carries all the information of every state of the UI in it. For example, different data situation, screen sizes, interaction effects, transitions, etc. It's your responsibility to build the UI regarding all these uncertainties. Plan these details in advance and clarify open questions with the designer or the team to avoid costly loops later on.

Check the mockup and be aware about the UI in all states and understand all possible actions. Here is a brief list of not-so-obvious things you should be aware of besides the basic functionality and user flow.

Small screens / mobile views
Long, short and missing names & text
Cursor interactions
Animations & transitions
Color themes / dark-mode
Currently hidden elements
Loading and empty states
Validations and confirmations
Permission relevant actions

Annotate mockups — Understand the UI you are starting to develop

Clarified everything? Perfect! Let's head to the next step and break down the UI into manageable work packages.

2. Break it into chunks

A chunk is a scoped piece of development work. Often just a functional module or a UI component.

Breaking your whole UI down gives you a nice checklist to get everything done step by step. Every checked item is a small success. I love working like this. Keeps me motivated for hours.

If you're working in a team, you might be able to share the chunks among your teammates. I try to share tasks only if the expected effort is greater than a couple of days. I feel it's more efficient to iterate, merge and keep everything in sight while not having to sync with too many people.

Often these chunks aren't on the same structural level of your UI. They are more nested in the DOM.

Break mockup into chunks — Braking the UI into chunks

It might be you are starting already on a level where breaking something down isn't necessary at all. Let's say when you're developing a new switch button — breaking it further down doesn't help anyone.

The order in which you start implementing the chunks isn't important. I like to go down the tree or from outside to inside. Starting from the main layout and then moving from section to section . I feel that I have more control of the overall progress this way.

3. Layouting

Every tiny UI element is layouted somehow. The layout is simply the structure of the DOM elements which make up the UI element. It's the nesting, positioning and sizing of every rect and their relation to each other.

It's an important step and I've seen many developers feel uncomfortable at it. If you master this step, you're getting really fast it scrubbing down amazing UIs.

The goal is to create a clean, function-oriented, easy-to-understand DOM structure with all necessary layout styles to achieve the intended look & behaviour.

I have two (dependent) principles here:

Question every element

Get the cleanest DOM structure possible. Remove all unnecessary elements. But be aware of the second principle to not merge everything together.

Every element has ideally only one purpose

Every DOM element has to be there for one specific reason. Try to avoid putting too many reasons into the same element. This makes the DOM hard to understand and is error prone when you start reusing the component.

Typical example: A button is never responsible for its position. The position needs to be determined by an invisible structure around the button. The button itself is just there to be a reusable button.

As described in step 1, it's critical to understand the UI you are building, so you are designing the optimal structure. Keep the following questions in mind.

How should everything behave when resizing?
Where are scroll areas?
Which sizes are dynamic which are fixed?
Where should animations appear?

Think before creating!
Get a rough idea about the layout in your mind and play through all the cases and open questions. Decide on the layout mechanism (flex, absolute, grid, table, etc.) and identify the challenges you are probably going to run into.

Switch button rect layout — From mockup to rect structure

Therefore, you need to know your building-blocks by heart! If there is one thing in HTML + CSS you should know really well then it's your layouting options. What are the available DOM elements you can use to create your structure and how do they behave?

These are the CSS + HTML layouts you should know by heart:

Display properties (block, inline, inline-block)
Flex layouts
Grid layouts
Positioning (relative, absolute, static, fixed)
Transforms (scale, translate)
Overflow behaviours
Width & height sizings

I put all the essentials I use for layouting into the following cheat sheet. It's definitely not complete, but it contains 98% of the basics for layouting I normally use. (download PDF)

If you have a rough idea like: „I am going to use a flex-box layout here, so these elements can all stretch according to the screen size" then you can start writing your first line of HTML. I normally follow these 4 steps:

Create the first div containers and then move from outside to inside — from rough to detail.
Apply CSS classes and some high-level comments. Comments are far easier to read and give you a rough overview of the chunks in the DOM.
The comments and class names need to explain your structure. Take a second here. The next developer will thank you. You can use syntax patterns if you want —or just be consistent.
Finally, apply the styles to your classes. Don't make them look nice, yet. Focus only on positioning, display, sizing, overflow, z-index, etc. If you have troubles writing styles blindly, use a dummy border around all elements to see what you're doing.
Important: Don't use any hacks! if you catch yourself using a hack, stop and think about a cleaner solution. Hacks in layouts are a terrible idea. Never use inline styles. Styles should always be in the styling files, otherwise you run into troubles with the specificity of your styles.

Awesome! Now you have the base layout with an easy-to-read structure and all necessary classes in your CSS file.

4. Appearance

The next step is to make everything look as intended. Move from one element/class to the next and apply the styles.

If you are using a design system (like bootstrap) use the predefined classes and variables to get a consistent looking UI. It's always worth to double-check if it really makes sense to use a pre-defined class here or if you end up doing a ton of overrides which is always a bad idea.

I recommend using design system classes for dedicated layout chunks and for often used stylings like shadows, backgrounds, text colours, font-sizes, borders and spacings.

If you don't use any design system, don't worry. But it's a good idea to build a set of classes that do the above mentioned basic stylings and can be reused everywhere. This will save a lot of time and code size.

Very often you can export the styles from design inspect tools. I like to use Zeplin for example. Mockups are created in Sketch and being shared with the developers via Zeplin. An inspect mode lets you check all spacings and extract the styles.

Try to never use colours directly in hex format #ff0000 in your style classes. Changing a color later is becoming a complex process. It's better to declare the colours centrally and use SCSS or CSS variables instead.

During the styling you might find some missing DOM elements or maybe some restructuring is necessary. This usually happens and is no problem at all. Just remember to add or change proper class names and to avoid hacks at any time!

It's OK to look how to create inset shadows, etc. when needed. No need to feel ashamed. It's always good to know what possibilities you have, so having broad knowledge about styling possibilities is beneficial. But you're getting there anyway over time.

5. Content behaviour

Content behaviour is an important but often neglected step in the UI creation. Your data may not always look like in the mockups. If you forget to take measures for e.g. too long names, your UI might look broken. This should be avoided by any means. Remember, a buggy UI lowers also the overall perceived quality of your product.

What if the text is suddenly much longer or empty?
How does it look on small screens?
What happens when I resize this element?

Set the necessary styles to handle all these cases properly.

Here is a brief checklist:

Check if the scroll behaviour is correct on small screens or long content.
Check if the resizing behaviour is like intended.
Check how your text behaves when it gets longer and shorter.
Check how the UI looks without any or very little data.

A very often used class for me is the truncation of the text:

.truncate { white-space: none; overflow: hidden; text-overflow: ellipsis; }

Yeah, you made it! If you don't move, it already looks pretty done. Unfortunately, it isn't. Don't dare to tell anyone you're done and move to the next chunk. This separates a good FE developer from a great one.

6. Interaction states

Remember the cognitive drain game? Interaction states just help! How confused people were when they introduced the motionless traffic light buttons in Germany: "Have I pushed it? I better slap it hard a second time to be sure."

Interaction states give the user the necessary feedback to feel in control of using the UI. To make it feel natural and ensure a usage without doubts and thinking.

There are basically 4 important states. Whenever you have interaction elements, check which of the states you need to implement.

:hover
Indicating that there is a mouse action and which action/gesture.
"Yep, you can pick up this object."

:active
Indicating immediate success when clicking or touching.
"Yep, you clicked it. You've seen it. Not jammed."

:disabled
Indicating clicking or touching won't do anything.
"Nope. Try, but you already know it won't work."

:focus
Indicating you are ready to type or hit return to trigger the action.
„If you type now, you'll type in here."

7. Transitions & animations

Wherever an element changes its appearance or position, use a transition. A jumpy non-transition is not feeling natural and the change is often not detectable. Feels just like a flickering somewhere on the screen. Feeling natural means less cognitive drain, that's what we are looking for.

Designers will often pre-define the transitions. But there might still be hidden transitions a designer has maybe not thought of. Then it's up to you to clarify or just use a proper transition.

Transitions in CSS consist of a duration and effect curve.

The length of the duration should depend on the "transition size". Big elements should take longer than smaller ones.

Use easing curves so the transitions feel more natural.

"But which transition should I use? Ease in, ease out, a custom Bézier curve, plain linear?"

It really depends. There is not one right way of doing it. In case the designer hasn't defined a frame-perfect animation for you, go with the most suiting for your specific transition. Ask yourself, how the object would move in real life if it were physical. Does it behave like a bouncing ball? Rubber-band? Opening or closing a drawer? Pushing or kicking something away?

For more complex transitions, use keyframes. For simple ones, default easing and cubic bezier do the job perfectly. To get a feeling for different transitions, how they feel and what effect is associated with them, check out this site
👉 https://easings.net/ and play around a little.

A good tool to create cubic Bézier curves is 👉 https://cubic-bezier.com/.

It's commonly best practice to tell the browser which property the transition will affect. E.g. transition: opacity 100ms ease-in; when only the opacity is changing.

Don't be afraid to google everything when you create a transition. It's also worth to iterate and experiment while implementing. You feel when it's natural and cool — it's hard to say what is right or wrong.

Animations are cool and very important! I think it is way worse to forget a transition than spending an hour too long on it. I am pretty sure iPhones are such a big hit because every transition and animation is perfect in iOS.

8. Testing & polishing

It looks like you're already done, but are you really? Have you checked everything?

A key skill you should develop is to detect all nitty-gritty design flaws in your implementation. This is something designers are excellent at. To reduce feedback loops it's good advice to train your eagle eyes to detect design and technical issues.

Look out for:

Inconsistencies
Wrong or missing spacings, colours, fonts, shadows
Missing effects, transitions, states
Browser issues
Unwanted changes, transitions, flickering on layout changes
Double check against the mockups

To build your eagle eyes takes time & practice. Look at mockups and UIs more mindfully and you'll become better at it over time.

A good training is this one 👉 https://cantunsee.space/

Polishing sometimes takes 2–3 days when I've created a completely new module with lots of functionality. I always find so many small issues… 🙈

Done. Everything feels great. Now it's time for some housekeeping. You will thank me later.

9. Clean up

Cleaning up is alway a good idea to prevent your code from getting messy over time. Nobody wants to own or maintain messy code.

Independent of the technology you are working with, it's always good to split your UI into multiple components. Some technologies like Angular are already encouraging you to do so. This enables you to work with small code files.

During the process of writing styles and iterating over the DOM structure during the development, I often find orphan classes and DOM elements in my files. I can really recommend cleaning these up at the end. Delete unused stuff and check for a proper, readable nesting and naming.

It's also wise to double-check again, if no color codes are used in your styles (see step 4).

Also double-check your file names. A file name needs to be according to all conventions and self-explanatory. This makes it easy to find your UI components in the future and increases the maintainability of your code base.

Wohoo! Done. Create a pull request. Be proud of yourself. Show off — nothing to fear. Your UI is great!

Here is btw. the Codepen of the toggle button I've used as my example.

I hope you liked this article! 👏

I am really happy to hear your opinion or feedback on the workflow. Feel free to reach out to me or leave a comment.