Simplifying Complicated Form
Are all of our end-users lazy? No ❌ (maybe some), they just want things to go easy for them to use. They like simplified things. Lesser time spent on doing things = more time to do other things. We live in the IT era where working smart is the new work hard. So, as the product designers, we need to make our product outsmart the intended user's expectations 🧠📈.
Today I will share my process of simplifying a complicated-looking form into a simpler one. The original structure is the exact requirements and was designed by the client themself. Ideally, a module should be relevant to all other clients, instead of just fitting a single client. So, to satisfy all stakeholders we need to audit the client's requirements, audit them out, question the reasons why❓, and point out any peculiarity before coming out with an improved UX and UI for their request.
Disclaimer:
YES. I KNOW. UX-wise, it is a sin 🚫 to use a modal dialog to host hi-stake and complex processes [context]. I lost this battle ☹️ to convince the product owners previously in early 2021, but at least I managed to persuade them to slowly convert the complicated work request, and financial form creation into the fullscreen page, modules by module this year (2022). If you can't obtain your goal in a short term, try to reach a win-win situation to cater for both parties.
1. Audit, Question & Point Out
//Hissing aggressively at the client's requirements. |
2. 'Marie Kondo' it
I bet you know Marie Kondo and her KonMari approach to neatness, decluttering, and organization of stuff. For me, there's a deserved place for anything. The KonMari approach is about choices. Similar to how we UX Designers make choices for customers, Marie Kondo guides her clients to make decisions about those items that they need to keep, organize, and or give/ throw them away. So, let us do the brain 🧠 work and organize for our client.
Here, I sorted the dialog content using the required data hierarchical importance. We should know what to prioritize and it’s very important to understand what to put first, and what to put last.
Here, I sorted the dialog content using the required data hierarchical importance. We should know what to prioritize and it’s very important to understand what to put first, and what to put last.
I communicate with the Business Analysts (BAs) to learn more about the client's requirements. I also asked if my decision to change the UI from A to B would affect other stakeholders. These are just the product delivery prep based on experience-based assumptions —At the end of the sprint, these designs are going to be usability-tested with the actual end-users.
3. Improve the UX and Organize the UI
If you read about the Jon Yablonski Laws of UX, you'll probably know the drill already. The ultimate goal is to deliver screen/design components that obey all the UX laws — aesthetically.
I used to think that by working in a product-based company, I'll be blessed with the luxury of time ⏱️. ちがう!! ❌❌❌ Nevertheless, I'll do my best to commit to my deliverables with 💎 diamond-level quality with the cheapskate time given.
4. Use Proper Copywriting That Guide The User
The goal of UX copywriting is to use language to help people make use of their brain 🧠 decisions when interacting with a product or environment. Users are guided through the crucial interactions of a product by UX copywriting.
A lot of cincai-mentality companies simply let the developers do the copywriting themselves, making the copies sound technical and alien 👽 to the end users.
The original UI given by our client is having too many boxes. |
Copies sound too technical 🛠️ is one thing. Other aspects to be taken care of are, making the design less text-ty and at the same understandable by the end users. Maybe we have been working too long in this industry and got used to the technical terms. But how about our end users? Empathy is the key 🔑 . So, use layman's terms, please.
Rule of UX – Hick's Law stated that the time it takes to make a decision increases with the number and complexity of choices.
So, I reduced the 'choices' offered to avoid the 'Paradox of Choices'. How to know which one is important, which one is less important, and which can afford to be simplified? I use data-driven 📊 decisions. I ask my colleagues from the implementation team (the team that does the data fillings of our clients to our product database). The higher the number of end users that will pick the option 📈, the higher the priority that I will give to the option 📈.
Not every user will configure these options, so I simplified their view. |
I personally think Product Designers are somewhat of a public prosecutors representing the UX aspect of product delivery. My counter would be my bosses and they have the product manager and the BAs as their lawyers. I can't win every time. That's the reality. Sometimes, they will have business requirements do's and don'ts that I had to compromise with.
Sometimes actually most of the time there will be some specific place where the end-users will still be confused with the business requirement's complicated instruction. What can I offer to the end users despite this shortcoming? I'll usually provide them with the 'info' ℹ️ icon they can click on.
5. The Important Contexts MUST Appear Above The Fold
Remember the 'Fold' manifesto?
What appears at the top of the page vs. what’s hidden will always influence the user experience — regardless of screen size. The average difference in how users treat info above vs. below the fold is 84%.
In this context, it is what appears on the modal without needing to be scrolled. This is why we need to stop 🚫 putting the complicated process on a modal/dialog.
However, I still managed to simplify this modal and enabled the user to see all the important items at the first glance without needing the end-users to scroll down. But still, having the tab component on this already-compacted modal... 😓😓😓. It's okay. I've done my best with the given 2+ hours of prototyping and redesigning these last 2 months.
END RESULT →
Okay, lah. But I know I can do it better if given the chance to. |