From UX to UI: implementation insights that matter

Enterprise UX case study (bonus).

Product designer tests implemented design solution. Photo by Ryan Yoo on Unsplash

Hello 👋, Aliaksei is here) In the previous series, we reviewed the whole UX process: ideation, validation, and application of experience design methods. All this was for the redesign of the EPAM’s time-off management system — Vacation portal.

The first part — ‘Value of the design artefacts and how to make Personas work’, the second — ‘Problem statement, Value Proposition Canvas and Hypotheses’, the third—Customer Journey Map, Flows and IA.

Based on the solid research foundations, the designer could make prototypes, iterating from lo-fi to hi-fi, deliver working design solution and ready to implement it with developers.

The risks of making the wrong design is significantly lower, a user is happier, business is making/saving more.

But design implementation is not just a cherry on the top.

Without it, all design effort is a mere wonderful concept.

What lessons could be useful for the reader?

We’ll answer with real practice examples.

#1. Do they see value in UX activities?

Product designer is nurturing the product from the idea to the interface.

We know the value of the UX, understand it’s a necessity.

This type of involvement could be treacherous—some designers are too touchy with UX artefacts or mockups, even when the product requires abandoning unworking design solutions.

But for the stakeholders, value of the UX activities is not obvious. They often are more sceptical, asking ‘So what?’.

If the designer starts the new product with a new team, he needs to build trust and earn credibility for our decisions. Sometimes it is very hard to do.

Non-designers have a different mindset, we couldn’t ‘remake’ them.

Insight: The designer could persuade stakeholders by showing a rigorous working ethic. I mean relentless iteration to find a feasible solution. Any bindings to UX artefacts are dangerous to the product.

If you want to demonstrate the value of UX, take only validated solutions. Prioritize the results to present sound decisions.

• The ‘brilliant’ hypothesis fails validation? Continue to the next one.
• The wireframe/mockup couldn’t pass the user testing? Next.

In the Vacation service redesign, we developed 9 Personas for the product. At the end (implementation), we had only three. That doesn’t mean that the other 6 weren’t good. We took only the essential ones—prioritization in all it’s beauty.

Another example:

We had an initial hypothesis that our redesigned portal should be more emotional to build rapport with our users. That leads to an increase in the service’s acceptance and will result in fewer support costs.

So, if we are about emotions, we decided to use illustrations, animations, develop an individual visual style, etc.

But interview sessions, work with a support crew, usability testing devastated this hypothesis.

People demonstrated clearly: for them, service was only about quickly and effectively taking the time-off. Web analytics nailed this. They don’t want any emotions, but effectiveness and clarity.

A concept for the Dashboard for Vacation service

But we got illustrations, visual hooks, and so on… Forget it, we need to move towards simplicity.

Implemented design of the Dashboard

So we changed the initial concept and aligned our product’s vision with researched data, not the reverse.

#2. Can people fly?

Designers want to make the best solution possible. But usually, we are limited by the product conditions. And not always we are ‘changing the world’ by our design.

But try to think about limitations from a positive standpoint.

Have you ever seen the interface of the original Macintosh (1984)?

If you ever worked on an actual Mac, the interface is very similar to the original.

It’s hard to believe: 1984’s Mac had a weak CPU, only 128 KB memory, a complicated cooling system, a small screen… And (almost) modern graphic user interface. This is a masterpiece of design and an example of a masterwork with limitations.

Yes, people can fly. But the aim is not mere fly. Usually, people want to get to the point.

Insight: We fly not for the sake of flying. The pilot (designer) could achieve good results only if he knows the limitations.

With modern technology, the team could do (almost) everything.

But who said that your product has the luxury of the cutting-edge tech?

Maybe, there isn’t any user/business value for the latest framework or switching to a new version of the language (like a transition from Python 2 to 3).

So, design limitations are inevitable. What are they?

• Non-technical: people, time, and product conditions.
• Technical: tech stack, hardware constraints, etc.

When a good designer is going to make the change, he asks questions like:

What if the frontend framework doesn’t support the designer’s intent?

What if backend has no endpoints to my dashboard tabs?

What if the capacity of developers is rigidly limited by vast business requests/roadmap/technical debt, etc.?

Knowledge of the tech stack, basics of the developer's work and SDLC will help to make design solutions feasible.

Example from Vacation product:

At first, we planned to have more features in the first release, but the main factor was the limited resources of the team.

So, e.g. we couldn’t implement a document preview section. Yes, it’s simple, it’s appreciated by users, but sorry.

Document preview feature variant for Vacation

Also, some features for the filtration of the dashboard were modified because of backend reasons. In every case, we needed to tune the design to technical conditions.

#3. Who is king in teamwork?

What if the designer doesn’t collaborate with developers (both frontend and backend), QA, support crew, other stakeholders, users, etc.?

Insight: It’s almost 100 percent, that this designer is making wrong design decisions.

So, proper communication is king in collaborative work. Especially in remote conditions.

For every ‘work-from-homer’ investing in this topic is highly recommended. It doesn’t mean chit-chat or aimless meetings, but a more subtle thing.

Building working relationships with a team is vital.

No, the designer doesn’t need to befriend everyone in the crew. In tight deadlines conditions, every communication is a double edge sword — it takes the time of all involved.

The main point: when you write them a message (say, about a blocker) they want to respond and collaborate with you.

Example:

I received a PO request for simple commentaries feature. I quickly validated the idea, made a solution for the comments, designing a simple tree of comments, tested with users. PO approved the design, so I made a handoff to developers. From the frontend everything was ok, too.

And it happened, that the backend team wouldn’t implement it, they had other important task. Why did nobody raise the hand earlier?

Nobody from the backend dev side felt that we really need this feature.

Sure, the designer is not responsible for the developers’ capacity management. But trying to disrupt their ‘task-done-next’ routine could help deliver better results.

After that I was far more concerned about devs opinion for features and kept them informed why we need this stuff. On every demo/grooming/planning, etc., I’ve tried to make them feel not a passive task-workers but main force of the product’s evolution.

Commentaries feature variant in the Vacation service

Happens, that team deploys a release without some cool features, I’ve designed. For me, it means that I need to proactively work to make proven ideas finally true. Often there is a chance to improve the solution, make the UX author’s supervision.

But without good work relationships with a team, it’s hard to expect game-changing implementation.

#4. Alone in the dark

That being said, sometimes the product designer is a team-of-one.

She could work without business analysis support. This means increased difficulty level, and chances of gaps with requirements, plenty of communication with a team of developers, etc.

I don’t think that the designer needs to be a jack-of-all-trades. Better have a multidisciplinary team, with separate business analyst role.

What if it did happen?

I had no BA support, working on the Vacation product. It was hard, but I managed to make the redesign and with developers and QA, we implemented it.

Example:

When your product is in demand, it must be supported 24/7. Customers wouldn’t wait for the redesign. They need to have solutions based on the current version. In my case, BA were overloaded with communications.

Happens, the BA is absent, not assigned, etc. A lot of requirements are waiting to be discovered.

Insight: Like in an old school RPG game, the solo designer hero plays the hardest way here:

• Light the fire! Construct the basic design process, get the vision with a team.
• Comrade aid. In our company, the designers could ask for support in various chats, consult with stream design leads, etc. There are communities in LinkedIn, Reddit, forums, etc. I found useful UX Stackexchange.
• Users summoning. If hero hesitates, he tests. Limited resources for research? No problem, test with a colleague, friend, relative, etc. Better have some user testing, than nothing.
• Dungeon journal and map. Our hero wants to share the knowledge with other wanderers, he describes it in a product knowledge base. Also, he maps the artefacts to quickly find them.
• Fireball. After important meetings, the hero always writes MFU (meeting follow-up) letter. It isn’t only to cover his bottom but for the navigation and recalling the milestones.

#5. When do you need to reinvent the wheel?

By ‘wheel’ I mean the existing complex component which has established design patterns.

Insight: The designer could customize the established pattern. But it’s not about ‘inventing’. Even customizing a complex UI element could be tough. Usually, it’s way to a helluva of work.

What if you have a design system? Will it cover all edge cases? The main question here is the level of maturity of that system.

That being said, most “design systems” are close to UI kits than to complete systems. But there are some good ones, with comprehensive guides and flexible components.

In EPAM, we usually build internal products with our design system, Unified UI (UUI). This system is constantly evolving and all designers could contribute to it. With time, I hope our design system could be open-source.

EPAM’s UUI portal

As you know, the design system allows designers and engineers to create a user interface much faster, applying developed ‘lego blocks’.

Sure, as the design is built on the design system, so the designer is limited to the building blocks.

Is it leading to dull and predefined design?

I dare to say: no.

Minecraft is ‘lego on steroids’, intentionally primitive by look. But you can see people on Youtube are building absolutely insane things inside that sandbox.

So the designer is limited by design system, but the depth of these limitations is up to the designer.

Let’s look at the customization of the date/time picker in the Vacation service. Sure, you could not ‘invent’ something new (‘the wheel’) with such a widely used component.

Hint: simply take date/time picker from a frontend framework, use native elements, etc., and that’s it. Almost for all cases, it is the most reasonable solution.

But in my case, I couldn’t just add JS library to solve the problem. I was caught by the requirement to use our library and customize the existing component.

Example:

We have plenty of requirements for the time-selecting component: various work length for employee, start/end conditions, sometimes hours must be available, sometimes minutes too, the necessity of quick actions (presets), users habits, etc.

An old picker was divided into two sections — start and end date, which was a point to improve—user wanted to make all actions in a single place.

Original picker:

Original date/time picker examples

A new variant, based on UUI:

Customized date/time picker has plasticity the original solution lacked. It covered all necessary cases, has room to change (e.g., adding more working hours), presets, etc.

Users don’t want to study the behaviour of the new system. They just want to use the service with patterns of other popular solutions. So interaction design is better if it follows Jacob’s law. The interaction of the custom picker was similar to Google Flights (except the slider/hours selector).

And sure, I didn’t make the customization by myself. We did it in constant collaboration with a lead frontend developer. Thank you, Max!

#6. How to gain solid ground in a marsh?

A designer spends time gaining hard skills: applicable UI/UX methods to day-to-day work. But there is a ‘soft’ skill which all of us need.

Insight: A crucial point of the design process is presentation/argumentation of the solution. In these vague conditions, some designers can lose track.

Managers, software engineers, QA and other stakeholders usually have not a designer eye for interface work. But until the designer doesn’t get their trust, they’ll validate the design decision as they could. Happens, they are forever skeptical.

And this means: if the designer didn’t do the homework, smart guys with different titles could make him do his work again. And again.

Sometimes there isn’t any correlation between design quality and filling the requirements. Simply the designer couldn’t properly answer the questions about the solution.

Experience + stakeholders involvement + data (qualitative, quantitative) = solid design decision

A good designer is speaking by problem-solving and users/business goals.

Based on solid UX research foundations, a mature designer could answer the questions:

• Is this a problem? Do we need to solve it? Who cares? How will it affect the user/business?

After this, our designer has a bunch of insights for reasonable change.

So, product designer is ready to face the critical remarks, confidently answering, gaining authority for further actions.

Moreover, if the stakeholders see the same thorough approach from the designer, the trust is building.

Trust is the most valuable design asset.

Example:

In the original service, user did next steps to reach the Extension request form (shift of regular vacation deadline):

Open My requests tab > Select ‘Extension’ item > Click ‘Add request’ button on the opened page.

After redesign:

Click the CTA ‘Add request’ in the header > Select Extension request form in sidebar menu.

Sounds obvious, so sells itself, right? Nope.

I needed to defend the solution and show the value. The research results helped me a lot—UX audit, Personas, Problem statement, work with IA, Flows, CJMs, etc. The team was involved in the design process, their ideas were reflected in the design. In the demo, engineers themselves answered the skeptical questions about the decisions.

All this built trust and the solution was approved.

#7. Whom to believe in the wilderness?

We talked about earning trust for the design solutions. But whom would the designer trust?

User’s words? Stakeholder’s wishes? Trends?

Let’s find out, starting from the users.

People could develop a bad habit to deal with day-to-day tasks. Their mental model could be deformed by the non-humane logic of the initially poor software design.

Maybe, the designer is a nice guy and users don’t want to say unpleasant things about his design.

Insight: If I feel, that interface is messy, clumsy or somewhat — I try not to believe at once to the users and stakeholders who say ‘we just need to polish it’.

Good designer watches the users, what they do, asks the reasons for actions, validates their answers.

Example:

There was an issue with the Vacation’s Balances page.

On this page is placed the actual day count that the user has for time-off. Usually, the user gets a number of the days for different leave types on the first day of the year and spends it. Some time-offs are limitless.

Problem: the data on this page was hard to understand, messy, a user was overloaded with tables.

1st part of the original Balance page for Vacation service

And that’s not all. The second part, on the same screen.

2nd part of the original Balance page for Vacation service

You’ve seen the stats for the person, who wasn’t fond of time-offs. The more absences the user takes, the more mess is grounding up.

And you know what?

In the first usability testing session, the first user said: “Everything is okay”.

An experienced one, 3 years in the company. He’d told that he was completely satisfied with a page look, information and so on.

At first, I was a bit surprised but decided to find out how he would manage test tasks. Yes, the basic flow was ok, because he knew the rules.

But after I asked him to show me some details of the balance, he started to have difficulties:

• Could you explain the terms in the header of the table? What’s the logic under the ‘Reported’ and “Requested”?
• How the leave could be ‘Reported’ without ‘Requested’?
• Is the balance correct? How to check it?
• Why does the user see these zeroes? He hadn’t taken any time-offs like Exceptional leave, without pay time-off, and so on.

Another users’ tests showed the same—experienced users were confident until asked to show something specific. Newbies were paralyzed almost at once.

Also, I found an issue that users didn’t communicate the final issue directly.

The user was able to see only the final sum of his time-off balance, without details of his absences.

To understand, whether the sum was correct, the user needed to go to another page, remember the numbers in separate requests, return to the Balance page and make calculations manually (or write to support).

During tests, nobody told me that this flow is inconvenient. But they showed it clearly.

I made a prototype that fixed issues of the page, validated it with users, sold the idea to the team and we implemented it (the screen below).

Redesigned Balance page for Vacation service

The user gets everything needed about balances in one place. If he wants a quick summary, it’s here. Only request types you really took, actual numbers (no meanless zeroes). Additional details are provided, the user could find it underhand: we placed the requests inside the balances.

Requests are on the Balances page

Moreover, the user could see the request’s details in the sidebar:

Moreover, the user gets the information gradually, step by step, without pulling the torrent of the numbers on his head.

The result: the users got a simple and quick tool, the business felt the change by lowering the support tickets and wider service acceptance rate.

Sure, I could not cover all topics about product design implementation in a single article.

There are left questions like “Why do the design bugs usually go to the end of the backlog?”, “How to design in fire?”, “Will the robots(algorithms, etc.) replace digital designers?”. Sorry, for the first question I have no answer).

But I think, some points will be useful for your design journey.

And wish you build the best starships possible and enjoy the Path.

Thank you for your attention and feel free to connect with me on LinkedIn.

Cheers!