Forem: Menai Ala Eddine

Visual Hierarchy : Definition

Menai Ala Eddine — Sun, 07 Mar 2021 11:56:47 +0000

As a front-end engineers, we may not give a deep focusing to UX Design, but understanding the basics will help us to discuss and improve the workflow between us ( Front-end engineers ) and UX/UI engineers.

In this article, we will take a look at the Visual Hierarchy and its importance in the UI Design.

Have you ever encountered a busy web apps where the UI Patterns ( elements ) are competitive or unordered?

If yes, I'm sure that you struggled to get your task done, or even where to start if its your first usage.

These web apps have a lack of visual hierarchy, but what's the definition of Visual Hierarchy?

The Visual Hierarchy is the organization of UI Patterns in the page or the screen which guides users eyes to the most important element and controls the delivery of information for the end users.

We can create the visual hierarchy by using:

1. Color and Contrast.

2. Scale.

3. Proximity.

1. Color and Contrast

Applying bright colors for important items, and less saturated colors for lesser important items.
Use heavy-weight typefaces to attract attention
Don't use too many colors which makes users overwhelming. It would be better to use between 2 to 3 colors.
Don't use many contrast variations. This will lead to competitive elements.

2. Scale

Bigger elements stand out and attract users's eyes.
Use less then 3 variations for the size.

3. Proximity

Implicit and explicit grouping help us discovering the content easily.
Give much space between the UI elements.

Ask yourself these questions before you design

Menai Ala Eddine — Mon, 19 Oct 2020 09:58:24 +0000

Before you start designing any feature, I recommend to ask yourself these questions:

→ Who are my users?

→ What are my users trying to accomplish?

→ How do my users think about what they’re trying to accomplish?

→ What kind of experiences do my users find appealing and rewarding?

→ How should my product behave?

→ What form should my product take?

→ How will users interact with my product?

→ How can my product’s functions be most effectively organized?

→ How will my product introduce itself to first-time users?

→ How can my product put an understandable, appealing, and controllable face on technology?

→ How can my product deal with problems that users encounter?

→ How will my product help infrequent and inexperienced users understand how to accomplish their goals?

→ How can my product provide sufficient depth and power for expert users?

Why you should create design systems, not pages?

Menai Ala Eddine — Sun, 27 Sep 2020 13:01:40 +0000

In my second year of computer science study, our web development teacher gave us a home challenge which is creating a simple dynamic web application with HTML, CSS3, JavaScript, PHP, and MySQL.

In fact, I was not a big fan of PHP and MySQL because I like to show people what I made and by nature, people love the appearance of the thing. Most of the time I was looking for a way to let my classmates and our teacher say Wow! How could you build it? Thank you to JQuery of course.

In the past, before I start any web project, the first step I get used to doing is browsing a template that fits the domain or the personality of the application. I was spending sometimes a day making the decision.

Obviously, finding the right template was not a thing to think about it, but customize and edit the source code based on my needs was the hardest challenge for me.

Before I download the template, I was checking the number of pages, the weight of each page, the structure of CSS3, and the complexity of JavaScript code. Indeed, I was facing a big problem with extending the template by creating my customizable pages that look consistent with others even I use its CSS3 classes.

I was asking myself:

→ How long will that page take to build?
→ How will it look consistent with other pages?
→ How can I extract the components and build a new page with them?

I was considering the page as an isolated, uniform thing. The fact is the components or the elements that make that page consistent is the uniform, isolated, and quantifiable thing.

The image above describes my mindset about web elements. On the left, It's the monolithic design and in the right, it's the modular design.

Modular Design

Brad Frost released a book called: The Atomic Design. When you read this book you'll discover how Brad Frost explained the web design inspired by the world of Atoms. What're matters for us now, is how to create modular user interfaces that become maintainable in the future.

Making your UI modular means breaking the large and complex visual explorations into smaller chunks, called elements or components, which save us time and make the user interfaces more consistent.

With the rise of new methodologies for architecture CSS3 such as BEM, OOCSS, and SMACSS, and the modern frameworks such as Bootstrap, Semantic UI, and Foundation, designers and developers spend less time to design scalable and maintainable user interfaces.

So these frameworks address the need of rapid prototyping by providing customizable, well-tested, and ready-to-use components.

However, even these front-end frameworks provide a specific solution for speed up the development, the end-user interface will be the same for different brands!

This is one of the cons of these frameworks, because everyone uses the same components and layouts to design the page. Imagine Facebook, Amazon, and Apple use the same UI framework to build their user interface, you'll find the same UI with different colors!

Furthermore, creating customizable components using these frameworks means following their conventions, code structure and styleguide. So the developers need to understand the architecture and the API of these frameworks which means invest more time for learning.

Design Systems, The future of UI development

Do you know Material Design? If yes, this is what I'm talking about.

Alla Kholmatova said there's not a standard definition of “design system” within the web community and people use the term in different ways, but she defined it as :

A set of interconnected patterns and shared practices coherently organized to serve the purpose of a digital product. Patterns are the repeating elements that we combine to create an interface: things like user flows, interactions, buttons, text fields, icons, colors, typography, microcopy. Practices are how we choose to create, capture, share, and use those patterns, particularly when working in a team.

So instead of consuming built-in UI patterns from Bootstrap, you'll design and develop your own patterns by creating your own standards and style guide. If you're deciding to create a social media app, for instance, you'll need to create your own like, comment, and share components that distinguish your application from your competitors. Also, if you'll create Data Visualization platform,
charts, progress bars are the most potent component you need to build your user interfaces. The idea is instead of creating templates each time, you'll create your own UI System that empowers you to build several products by influencing brand factors. These design patterns will create a mental model for users and customers.

But what are the benefits of design systems?

Before we use any technology or approach we need to know its benefits. Let’s take a look at the many ways a design system can be a much-needed painkiller for your growing pains.

Consistency:

Standardized components used consistently and repetitively create a more predictable and easy to understand the application. Standardized components also allow designers to spend less time focused on style and more time developing a better user experience.

faster:

When your product grows, you need to delight your customers by delivering new features. In the past, this means producing new code and start the development from scratch. But with a design system in place, you need only to iterate and integrate your UI patterns together to develop the feature.

Quick iterations:

The design system reduces effort from hundreds of lines of code to as little as a few characters. This makes iterations quick and painless, and experimentation much faster.

In conclusion, design systems are not a fad or even an untested hypothesis. For the design to find the scale necessary to match the rapid growth of technology, component-based design and development is a proven and dependable solution.

I've tried to show you the power of design systems and their impact on user interfaces. If you want to learn in-depth about the design systems, I'd recommend these books:

→ Invision Design System Handbook

→ Atomic Design

Edit →

How to limit your choices when you design?

Menai Ala Eddine — Fri, 25 Sep 2020 13:24:00 +0000

→ Which option will delight the users?

This is the frequent question I ask myself in my work basis. Hope I'm not the only one!

Designers and engineers waste more time on details and minor decisions in the early stage of designing and implementing new UI but they should realize that designing UI is an iterative process. In fact, it's better for you to not stick on minor details in the early stage of any task. You don't want to hear from me how many hours or maybe days I spent changing the font size by adding or reducing 1px.

→ Do you think that users will notice these changes?

→ Do you think that adding 1px will add more revenue to the company?

Please, don't waste your time on these changes in the early-stage.

From Speed Dating Decision Making – Why Less Is More:

Yet new research does point out a different dating problem: being confronted with a large number of choices can make it harder to make a good decision. In fact, it can even prevent you from making a decision in the first place.

When you're designing without constraints, your process will be very slow, and you will never end up with a choice. Let me clarify with this example:

As you see in the above image, the first scenario is for a buyer who wants to choose a flower for his wife but he's seeing flowers with different colors and they are almost similar which makes the decision so hard for him. The second scenario is for a designer who gets confused between these buttons where it's almost to see the difference between their background colors.

The fact is when there were too many choices people became confused and didn’t make a choice when there were too many options. People that had few options chose more often and were happier with their selection. So, you need to stick this rule in your head: Limit your choices.

So how can we limit our choices for our user interfaces?

Systematize colors:

When I was a student, I remember when we were working on the design of the website with my teammate, and because we had not a system for the colors, we were picking a color randomly each time from the color picker and we see how the color looks in the UI. But after I discovered and read Material Design, I figure out how companies choose their colors.

So, instead of hand-picking values randomly, create your palette from the beginning, there are dozens of online generators that can help you to make your decision. You can choose from 6-8 shades and expand when you need more colors.

Choose one or two font families:

It's hard to achieve consistency in UI and most of the time over designing is the reason behind losing it.

Having more than two font families will make your brand less-memorable like the logo and the content becomes more inconsistent for the reader. Obviously, choosing the font family is very hard in the early stage and my recommendation is to choose the one that fits the personality of the product.

Systematize font size

Similarly, don't do what I was doing by adding or reducing 1px until it looks perfect. You may waste 2 hours without taking a decision. Instead, create a stylesheet for your typescale in advance.

Systematize icon sizes:

Defining a system for the sizes of the icons in advance will save you time later.

For example, you can constraint yourself by 4-based or 6-based scale. Your options will be :

12px, 16px, 20px, 24px, 36px, 48px, 64px.

Sytematize opacity values:

Opacity values confuse me a lot because it's so hard to see the difference between them.

Personally, I choose a 5-based opacity-scale and I limit myself by 4 values:

12.5%, 25%, 50%, 75%.

In CSS3, this is equivalent to:


   opacity:0.125;
   opacity:0.25;
   opacity:0.5;
   opacity:0.75;

Having some choice is better than having no choice at all. But there is a limit. As it turns out, having more choices isn’t always a good thing.

Don't miss to star You Don't Know UI

Design few, Implement few is the right workflow for designers and front-end developers!

Menai Ala Eddine — Fri, 25 Sep 2020 12:57:42 +0000

I have this question for you:

→ Why do you need to design perfect UI with all details then implement it?

I have another question for you:

→ Did you feel frustrated in the stage of implementation of a new feature because the design does not take programming limits into consideration?

My last question is:

→ Why do you focus on details in the early stage of the design?

Ha! I know you're thinking in Agile but you're working with the Waterfall approach.

Indeed, people get confused when they switch from task to other per day even in the same domain, it happened to me usually, especially when it comes to designing different concepts of user interfaces per day.

Furthermore, people want to start a thing and finish it once time. They want to make it perfect from the beginning! Even with low resources and in limited time. It happens most of the time in early-stage startups.

So, let me tell you something: Details do not matter when you start from scratch.

The hard thing about the design is when someone asks you: Why you take this decision?

→ Why you chose this palette of colors?

→ Why you chose this typeface?

→ Why you chose this style of icons?

If you have not a Design System in place, creating consistent user interfaces is very hard, and focusing in-depth on details, will lose time, effort, and of course the consistency of your user interfaces.

So, what's the solution here?

As I mentioned in the title: Design few, Implement few, Repeat.

In the earliest stage of the new design or new feature, you don't need to stick on the high-level decisions about the foundation of your design ( Spacing, Color, Typography, Iconography). I know they matter but not in the beginning, right?

Let's say, when you were having a shower you came up with an idea for a new killer feature, and you want to make it more tangible for your teammates and the stakeholders to get buy-in. Adding new features means a new investment of money and time and what's matter later for any company is: Revenue.

The first thing, you need to do is ignore all details ( nice-to-have ) and just focus on the requirements ( must-to-have ).

So, I recommend this workflow to get quick both of internal and external feedback:

Create a hand-drawn version:

As you see here, there are zero details about your user interface
in production, but why this step matters?

This hand-drawn activity may take between 5min and 20mins if you want to make it a high-fidelity draw!

In fact, this step will help you to see other teammates and stakeholder's opinions and gather individual recommendations from each member of your team. People could not recommend changes when they see a well-done thing. But they can tell you how can you make it better when you deliver it clean but incomplete and ugly. It's human nature.

Ignore colors:

When I was a kid, I remember my Dad when he was buying a paint book for me. The content was grayscale images and my mission was to colorize these images using wood colors. Sometimes, I and my friend have the same image but when we colorize we end up with different looks! After that, we go to family members and ask them which one is better.

But how can we adopt this workflow in our design?

The idea is to hold the color even if you'll refine your design in higher fidelity. Let people tell you how are the shapes, sizes, spaces, and the position of your elements.

Implement the UI:

Modern frameworks and libraries such as Vue, React and Svelte were created for Rapid Prototyping which means you can implement one component and use it with different looks in different positions. So, you don't need to have a full prototype with all user interfaces to start the implementation.

It's a little bit challenging, but I can say that you don't need to regret the time you spent for designing perfect UI that you'll never see it on production.

The goal of this step is to test the back functionality ( How it works ) of the UI without sticking on how it looks for users.

Colorize:

If you don't have a color palette in place, you can try several colors and see the consistency between them based on color theory rules.

Repeat:

Our purpose here is to prevent the over investing and moving fast by doing parallel iterations on both design and code in a short time, so you can build real things as soon as possible. In the end, what matters is your UI in production.

Why you should think in a feature, not a layout when you create UI?

Menai Ala Eddine — Fri, 25 Sep 2020 11:41:45 +0000

I've wasted months not just days trying to create an MVP ( Minimal Viable Product ) for an idea. I spent nights and nights refactoring the user interfaces by changing just the places of the components and the layouts. Don't be stupid like me!

When you start designing a new user interface for a web or mobile application, most of the time you think about the structure or the position of your components, so you start designing the Header or the Top Navigation as your first component in your UI. Me too I was doing this mistake!

Do you know why it's a mistake? Because you're limiting yourself from the beginning. Because you're seeing the App Design from Top-To-Down or Down-To-Top while the App Design is a collection of features. You're not building a house here using LEGO bricks! But you're building a car and you can start designing the engine or the wheels, right?

Most of the folks try to copy & paste from popular websites and apps, without knowing the Standards or the Design Decisions for each product. This is the easiest way to find themselves frustrated, limited and they figure out that they overthink only on Generic Things.

They focus on the shape of their app but not the core features, and they start asking frequently these questions :

→ Where should I put the Logo?

→ How many items should I have in the navigation bar?

→ Should I have one or two sidebars?

→ Should I have a Grid Layout or a Table of items?

But, what you don't know ( maybe ) is UI Components are made to solve certain problems that are related to user interaction, data displaying, or new device screen invention, and you may be noticed that the Hamburger element is started to be well-known in mobile devices.

Obviously, we are not designing user interfaces but we are designing and implementing features, and Top Navigation is just a common feature that helps users to do quick navigation for certain and most important pages.

So, don't care about common features or what I call them Generic features or layouts.

Instead of starting by a layout, start with a feature or specific functionality, and not any feature but the core feature in your product.

Let's say you'll build the next-gen social media app for sharing videos. You could start with this core feature: Share a short-form video.

The UI will need :

→ Field for upload a video

→ Field for the caption

→ Field for the description

→ Button for posting or sharing

→ Button for saving in draft

These are the requirements to design your UI.

Star the project on Github: You Don't Know UI