3 Points About UX Design That UI/UX Designer Should Know
Bohdan Doshchak

User experience (abbreviated as UX) in the context of Web-based systems such as websites, web applications or desktop software, means how a person feels when interfacing with a system. Users looking at such things as ease of use, a perception of the value of the system, utility, efficiency in performing tasks and so forth. Talking about a product developed by UI/UX designer that makes your client and customers happy I would like to affect three points:

Flat Design

Flat design has been trending in UI design for the last few years and keeps hyping even harder during 2017. But where did this trend come from? Apple is a trendsetter. But how did the company pass from “icons that you want to click” to simple icons, and most applications no longer imitate the real things?

3 Points About UX Design a UI/UX Designer Should Know: Flat Design

The deal is that skeuomorphism, as every other stylisation, is just a visual noise that doesn’t help to interact with the app. It was needed as a transition from analog to digital tools.

This is how the notebook looked before:

analog diary

And it’s digital version looked similar:

UI digital diary

But who uses interfaces like that one now? Today’s digital UI UX design is orientated on gadgets and computer active users, so the modern version of planner called Google Calendar pretty much looks like that:

UI Google Calendar

There is no need to bring artifacts from analog to digital (with some excuses).

Project Specification vs UX Design

Nothing is sadder for UI/UX designer than working on a project with no possibility to design. In most cases, the client doesn’t come to a designer with a project. He has just a ‘naked’ idea, a budget, the deadline, and maybe some features on his mind. And together, you have to develop an idea of the project. Not a client on his own. Not a designer by himself. Cooperation is a success.

One of you is an IT master, another one is a specialist in a branch the project is related to. Together you are a dream team. There is a very tiny chance you could be/do both at the same time.

Most likely, without cooperation, the third part of ideas would be declined, another part will be removed from MVP to another phase. Then you’ll realize the budget and deadline failed.

The main goal of UI/UX designer is to figure out the key features of the project, its classification, maintaining, etc. A designer should not just blindly follow specification full of project requirements, but find and make a solution that brings the maximum benefit to the client.

Here is a checklist to achieve that:

1. Everything should be logical.

The user must do what you want to before he gets too bored and lazy to figure out how your system works. Laziness and boredness are quite a test, not the designer’s, developer’s or customer’s, but the user’s one. It perfectly described in ‘Don’t Make Me Think! A common sense approach to web usability’ by Steve Krug. You should read that book.

2. The project must be technically possible to be developed.

On that point, newbies in design fight with programmers, but skilled ones find a solution in the development process.

3. Communicate with your client.

Tell him how this or that decision was made. Possibly, the client is more skilled in a branch your project is related to, and he could help you with some solution or an idea. Also, if your client is involved in a process, there will not be a problem if the project has differences from project requirements.

So make no assumptions, just ask.

Also, I can recommend the FFF working system: fix terms, fix budget, flex scope. But before you use that, you have to discuss that with your client.

A bad case:

A large company gave a specification for an application already designed but with bad UI / UX solutions. The project needed a production. By long negotiations, we fixed obvious and annoying UI / UX bugs, but a lot of uncomfortable solutions for a user were released.

The design is like the American Justice with its applicable law cases: something applied is easier to use in a new case than a fresh solution. And it is bad to make decisions when you change the default behavior of the elements.

A good real-life case:

We received a project, the most part of its specification was hand-drawn charts and tables. They were very confusing, so we decided not to waste time and just made a call to a client. The manager spent time negotiating and getting the details. But even without personal communication, with charts and tables, we got the idea of the project and what we needed first. The call helped us with the right understanding of our perspectives.

We finished the first phase with drawn wireframes and the main project part designed. The client was satisfied with UX / UI we came up with, and the second part of the project we’ve done together ‘on the board’. Should we say the project wasn’t according to specification?

Development for a Peculiar Audience

Actually, UI/UX designer always develops projects for a peculiar audience. We are specialists in our narrow spheres and have to make assumptions about people related to another branch, gender, culture etc. But it’s a wrong way to find user’s needs, so as a good UI/UX designer, you must decrease the number of assumptions.

But how, you may wonder? Just ask. Communication is a key to everything. Your mission is to figure out what the project really needs, not what your customer formally said.

One more trick: follow users’ expectations and user experience. Give a user exactly what he expects to receive from your product.

Want to learn more?

Master of Code designs, builds, and launches exceptional mobile, web, and conversational experiences.

















    By continuing, you're agreeing to the Master of Code
    Terms of Use and
    Privacy Policy and Google’s
    Terms and
    Privacy Policy

    Also Read

    All articles