From UX to UI: implementation insights that matter
Enterprise UX case study (bonus).
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.
But we got illustrations, visual hooks, and so on⌠Forget it, we need to move towards simplicity.
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.
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.
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.
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:
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.
And thatâs not all. The second part, on the same screen.
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).
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.
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!