UI/UX - Is It Just a Fancy Term for Good Solution Design?
Andrew Ronchetto
Visionary and Co-Founder @ Be On | Pioneering Digital Holistic Wellness Platforms, Innovation, & Transformative Growth
Has it ever occurred to you that a poorly designed solution is like a punch in the gut? It's painful, creates a degree of resentment, and forever changes your relationship with the other party. As I collected my thoughts on this topic, I couldn't help but focus on the human aspect of what we do as solution architects. My responsibility in its simplest terms is to take the business requirements and mold them into systematic and technical requirements. Nowhere in that statement, though, do I talk about how the end user will use the solution or how their work will be positively influenced. That is the rub that I want to talk about. There shouldn't be this separation and below I want to discuss a few of my focus points when I design and build solutions.
One Click
I will be the first to admit that not everything can be done with a single click, but that doesn't mean we shouldn't try to limit the amount of effort the end user has to exert in order to complete an action. Thinking not only of function, but also interaction will promote a mindset of simplicity. If you look at mobile devices and applications that have successful user productivity features and capabilities, they tend to illustrate a very refined user experience where every action is natural. For example, how you share information with others or open content in another application isn't convoluted. When we build a new solution, we should ask ourselves how can I make every activity faster and easier to complete?
One System
Have you ever gone into a solution leveraging a specific platform and realized that it has been customized to the extent that it no longer looks right, operates different from other solutions on the platform, and promotes an inconsistent experience within the solution. If you aren't raising your hand then you have done very well to implement standards, force all project teams to abide by those standards, and have seen those teams implement the standards very willingly. It's that or you got lucky!
If you are customizing the platform to the extent that it is no longer recognizable, is it really the right platform to be building the solution on? All too often I have seen that early on in the solution definition phase, the end user will step in and outline what platform will be used before the requirements are even written down and vetted. The one I love the most is when someone says I want to use this platform, but I don't want it to look at all like that platform. In simple terms, "Houston, we have a problem!" If the solution you are building is going to be leveraging a particular platform then it needs to operate based on the fundamentals of the platform and not have a degree of customization that alters the core functionality.
One Palette
I want to expand on this particular point beyond the color palette and include formatting. With the advances in platforms to offer user the ability to change fonts, sizes, colors, etc. we run the real possibility that even though we follow my previous two points we still create a solution that is less than appealing. My first recommendation here is to implement a color palette in the solution, when possible, that is consistent with the corporate branding. It is generally easy to do and if this is done upfront you will reduce any rework to align the solution with the corporate branding later. My second recommendation comes from my days of creating promotional material in college where I learned to apply what I call the "Rule of 2". No given page should have more than two types of fonts, sizes, or colors when it comes to the text on the screen. This ensures that the page is simple and easy for the user to absorb. This is important if you are going to create something that is natural for a user to use.
Final Comments
I am sure there are other areas to focus on and I look forward to readers of this post providing their comments both on my few points as well as others they find important. When we look at what it takes to build a solution, often times these items can get lost. I want to highlight them in an effort to make sure they stay in the back of our minds. I also want to remind all of us, including myself, to remember when a requirement or a comment goes counter to any of these, we should stop, explore the need further, and look to encourage a different path whenever viable to avoid potential pitfalls in the future.