In recent years I’ve noticed the ever-growing gap (or a drain) of in-house designers in Interaction Design (IxD) or UX designers with capabilities in IxD. Recently for a high-profile project in a multinational software company, I was astounded that IxD wasn’t included in the process nor were any IxD designers on the payroll. There were indeed Visual/UI designers busily creating components for its Design System and creating beautiful GUI, but when it came to the overall flow of the app experience it had major issues chronically.
I’ve also noticed that frequently UI designers conflicted with developers or tech leads on how screens are designed, leading to fundamental usability issues —which should’ve been avoided initially. It made me ponder how and why an organisation can end up in this predicament. Let’s consider some root causes & drivers.
But first: The back-story
It was in 2014 when I had been introduced to a Design System at an enterprise level– it was with GE’s DS facilitated by Frog Design in its creation. Since then I had been both a beneficiary and contributor to various DS and have seen them evolve as they became mainstream. Having served in Visual design / UI for the first 12 years of my design career before transitioning into UX full-time, I will add that corporate style guides (the predecessor to DS in the early days decades ago) were valuable tools from the start and still is.
I am critiquing the current trend in DS with the hope of seeing it meet its full potential and helping other designers to navigate the trend’s shortcomings, and push for a better standard.
The shortcomings of Design Systems
Most companies’ DS (Design Systems) are comprised of UI kits, with different degrees of UI elements’ classes, groupings, and components which are building blocks in creating user interfaces. They are accompanied by corresponding code snippets for developers for the production of the UI. Even more importantly, the documentation on how and when they are to be used serves as rules and guidelines to follow. Unfortunately, for the majority of cases, Interaction patterns are scarce or left out in DS unless you’re Google’s Material DS or IBM’s Carbon DS. In short, there are too many DS which are heavy in Visual design, and too light on interaction guidelines.
Style-guides & Pattern libraries
DS itself based on rules & UI patterns alone cannot replace IxD in the complex software domain.
UI kits are essentially a kind of style guide. There lies the key issue. An org’s DS can host thousands of pieces of UI elements in a rules-based framework but it still doesn’t yield any great designs with consistent interaction experiences across an org’s apps, platforms, and production teams. Why is this? Without the IxD patterns produced from experiments of what works/what doesn’t with real users within a relevant goal-directed design process, why’d we expect a “toolbox of UI elements” to generate an answer to interaction design challenges we face? Style guides help a great deal when it comes to visual consistency & aesthetics, it does not however resolve any issues with flow or interaction.
DS itself based on rules & UI patterns alone cannot replace IxD in the complex software domain (while it may be feasible for standard websites using themes). Good UX does not get generated repeatable patterns like a factory or a machine. As IxD deals with time, context, cognitive loads and human empathy– all of which serve for good UX, it’s not smart to skip out on IxD in the process.
Having an interaction designer produce IxD patterns with the use of a DS, and contribute back to it with User goals, scenarios, and interaction patterns would be ideal. Of course, if the next project comes along with similar goals & needs, those patterns can be very useful. If the shared interaction patterns can shave some time off from the design team by setting up some foundations of consistency (and do not need to start from scratch), the DS had served the teams greatly.
Developers designing the interaction
Some developers may also confuse the existence of a DS as an invitation to start designing the software independent of IxD designers. Or in some cases, restrict their colleagues on parameters set from an old rule and reference them as dogma to work within the limitations set. The challenge is how to recognise the right context to apply the old rule limitations or to investigate a new solution.
It’s important to note that a design system is never “finished.” As your product evolves, the design team will add new UX and UI designs over time. When you have UI designers or developers, or any non-IxD designers designing the interaction side of the software, this is a clear red flag to reconsider the situation. I advocate for getting everyone “thinking UX” but differentiate that from having everyone designing the experience.
Designers jumbling of titles as “UI/UX”
It’s a modern myth that a single human resource is capable of handling both UI & UX with sufficient expertise & quality. In 99% of cases, the person is either UI-inclined or UX-inclined and never both. Wise UX managers/leaders hire based on the 80/20 rule for skills/competency. For the UI candidate to be 80% focused on UI as a core skill set while having 20% of UX proficiency. And vice versa for UX designers. This is particularly useful when a project arrives at a delta where IxD meets VxD (Visual experience / UI design). Having those designers understand each others’ discipline & crafts would enable them to communicate effectively and collaborate well.
The employ-ability factor may also be the root cause of why designers jumble it as “UX/UI” to cast the net wide especially when they are just starting in their careers. But prevalent use across the industry hurts us all in the end. It is mainly due to the spreading of false reality & expectations.
Cutting corners on skills & head-count in design
It’s commonplace for organisations to have designers reporting to Tech or Product. For them when hiring and reviewing resumes, the “UX/UI” title insinuates that the candidates can do both, and for the org to save costs on hiring 1 designer instead of 2. This leads to promoting a myth that it’s okay to lump 2 distinct disciplines of design work into a single person. It’s not only detrimental to the business due to poor outcomes but it’s simply unfair to the designer with these expectations. The exception to this is Small-Medium Enterprises with a smaller scope of work which can be manageable via Product Designers (who handles some of UX, interaction, and mainly visual design).
It appears to be for the extreme majority of cases, “UX/UI designers” are essentially UI or visual designers. For hiring managers, it’s a clear signal when filtering initial applicants. The rationale is that if you’re dedicated to IxD, you’d be sure to write “Interaction designer” or “UX” as your title and not “UX / UI”.
Many seem to think from product management or tech that the faster they arrive at generating Hi-Fi design screens, the better. And the more beautiful it is, the more accolades the team gets. Much of design time is invested upfront in visual design or detailed design upfront. This way of thinking leads to hiring only visual designers over IxD resources, hence the science of studying & delivering on User goals & their needs takes a backseat, if at all. In the long run, when the product or service gets progressed into production & gets released into the market, it will face harsh realities of poor usability & low user acceptance. Studies have shown that the extreme majority of new products fall into the trap and fail because of it. The root cause for failures has overwhelmingly pointed to one: poor User acceptance.
The misguided approach of “Big Design Upfront”
Many seem to think from product management or development that the faster they arrive in generating Hi-Fi design screens, the better. And the more beautiful it is, the more accolades the team gets. Much of design time is invested upfront in visual design or detailed design upfront. This way of thinking leads to hiring only visual designers over IxD resources, hence the science of studying & delivering on User goals & their needs take a backseat, if at all. In the long run when the product or service gets progressed into production & gets released into the market, it will face harsh realities of poor usability & low user acceptance. Studies have shown that the extreme majority of new products fall into the trap and fail because of it. The root cause for failures have overwhelmingly pointed to one: poor User acceptance.
So why is this happening like a pandemic?
Business stakeholders generally want to see a sparkling & glossy detailed design as soon as possible, it’s always been the case and it’s a pity. If a business executive had hired you, it’s natural we have designers being pressured to deliver this sooner than later. It’s the role of the UX / IxD designer to guide stakeholders throughout the process, communicating & managing expectations. But if the business stakeholder had a hand to play in hiring the designer though, it’s most likely had chosen the designer based on Visual / UI skills, and that’d mean most likely that the aforementioned required guidance of stakeholders on IxD wouldn’t take place. Rather the designer would be inclined to apply concentrated time in designing visual outputs as he/she was trained to do.
Impatience to rush to a visual design, and bypassing IxD has huge negative business consequences as the product/service is wrought with usability issues or misaligned with the needs of Users as that discovery through experimentation was skipped, leading Users away to find an alternative solution. In other words, the poor UX damaged severely the product’s livelihood as it went off in the wrong direction from the start.
Pressure to work to feed developers to code something
The other driver behind the issue is developers wanting detailed design as well as soon as possible– so that they can get started coding, which is consistent with the “ship fast, ship frequently culture”. Developers want as much specificity & a clear picture of what to build, leaving out any room for the abstract & ambiguity. This all leads to designers working hard to invest heavily in creating Hi-Fi designs as outputs for that demand (known commonly as the “Big Design Upfront” symptom. This practice unfortunately means not investing adequate time in working out the kinks in IxD. Ironically, ironing out the ambiguity by investigating what works (and what doesn’t) are inherent in interaction design at the early stages of the project. By omitting IxD in the design process it increases the chances of building something which adds little/no value to Users.
Are we really working “agile”?
The 3rd and final driver is a false belief that putting out a product as quickly as you can is “working agile”, when actually it is not. In other words, the supporter of this belief thinks that getting feedback from placing the product on the market LIVE to iterate is adhering to the agile mindset. That may be worth entertaining in doing but it has 1 massive drawback: most issues discovered after launch are large fixes required instead of minor adjustments. The extremely high costs or time required means it doesn’t get done mostly or they get heavily compromised due to tech/business constraints at the end of the process. A such misguided path could’ve been avoided with rapid learning tests in IxD and validated with actual Users with minimal costs in the sketching process.
How do we turn it around?
Embrace the “Fail early, fail often, fail cheap” mentality.
Recognise the roles & responsibilities and hire accordingly, and not look for unicorns to save costs in human resources. Not only is it unfair for the person you’ve hired with unrealistic expectations, but it’s also placing the whole product in jeopardy. Taking shortcuts in UX & interaction design means a higher probably of missing goals of Users and putting out just simply bad software that’s not desirable.
Tell-tale signs of an org with UX maturity is when its design department is comprised of several IxD designers as well as UI/Visual designers. They’d be assigned to projects in appropriate stages/milestones, working together in a design-driven process with the User’s goals being the main drivers. More on this topic is discussed in the article,
Work towards “Big Learning Upfront” instead of Big Design Upfront. Embrace the “Fail fast, fail early, fail often” mentality. Having UX / IxD designers assigned to a project would mean Users’ goals are mapped out with an evidence-based approach. It means someone in your org is actively listening to Users (rather than following them) and coming up with hypotheses on how to achieve them, and testing them regularly. They’d conduct experiments to validate and refine the abstract ideas into valid approaches cheaply & frequently, and most importantly ahead of production in detailed design & coding which has the highest costs.
We can liken the work in IxD to a writer creating an engaging screenplay for a movie before the production of filming with actors and the stage crew building the sets. Imagine having a half-baked script to shoot a film when each day is costing thousands of dollars. You’d end up with a movie which makes little sense to the audience while it may be visually dazzling and full of spectacles. The work for sure ultimately will be easily forgotten by the people it was intended for.
Work towards MDP – Minimal Desirable Product. Many orgs take the approach of MVP as getting a product out there in the market as one big learning experiment with eyes on iterating it for improvements over time. That can mean years and dozens of software upgrades before you get a decent product in front of customers, popularly known as the “attrition method’ in software. Many refer to this as “painting over a corpse” as you’re hoping to revive something which was dead in the water to start with. Unless the software org is a corporate giant with an endless amount of resources & budget, with strong brand support, can this approach ever be seen as smart.
Having a desirable enough product to Users and a clear goal to achieve for the first release to ship can completely change the landscape. Having frequent evidence of User research to validate good ideas from software rabbit holes, and filtering out wrong paths at the early stages in the process would lead to hitting the mark much closer from the get-go. Refinements which follow in updates are enhancing the durability & experience rather than fixing what’s broken (which in many cases are not possible, simply are band-aids to deep hemorrhaging).
UX research, IxD, VxD, and Dev – and it that order
One may say the first real issue is with the label of “Design System” setting false expectations that the answers to interaction problems can be sourced from there. Rather, the answers can be reached with trained operators & problem-solvers using the tool-kits in design, which is essentially what a DS is. In my humble opinion, we need 3 pillars of specialists in the team to efficiently leverage a DS: IxD, VxD, and Dev. Those 3 disciplines ought to use their expertise to interpret the problems first, then use the tools to find solutions, and continually upgrade & add more tools into the toolkit.
