Why we need Automation for UI/UX

Getting good UI (the visual presentation) and UX (workflows) into production is hard. In many cases it is an order of magnitude harder than getting traditional software deployed. Hence, in the zero-sum game of engineering resources, many UI/UX efforts never get the necessary time or resources, and a lot of  usability efforts never see the light of day. Organizations simply give up on developing good UI/UX to drive their products and customer experiences, relying on their underlying technology (e.g., great data science, great hardware, or access to great data) to make a sale.

From what I have seen running a B2B software design studio, a fundamental blocker preventing the creation of UI/UX at scale is the absence of automation that can translate vision into code. Some low-code/no-code solutions (either programming meta-languages that procedurally generate UI, or drag and drop UI builders) have emerged that have attempted to solve the process of building UI, but these tools still require the user to translate objectives into structure. The yawning chasm is the lack of intent-based automation that does that heavy lifting for the development team.

This blog post discusses why the industry needs to solve Automation for UI/UX, and the unique challenges that stifle efforts to get front-end creation (both design and engineering) operationalized and launched into production. It goes on to describe the vacuum in the current low-code/no-code ecosystem.

Website creation

Thinking back to 20 (or even 10) years ago, companies would go through a multi-million dollar process to develop their website. Websites were mostly custom written projects, with designers, copy-editors, and engineers working long hours to get even the most basic web-presence. Geocities websites just wouldn’t cut it if you were a B2B corporation, As a result, businesses would either form large in-house teams, or contract out to specialized firms to design, build, update and maintain their website. 

Then in the mid 2000’s along came website Content Management Systems (CMS). CMSs ranged from highly customizable (Wordpress and Drupal) to end-to-end platforms (Squarespace, Wix, and Shopify). Regardless of their approach, CMSs managed a common thread of pain points. Most websites had a common set of use-cases, and through templates, the company’s marketing team (or even a single marketing person) could design, update, and maintain their own website.

The advantage of the template-based approach is that while most developers, marketing teams, and executives do not know how to create good UI/UX, the template ensured an acceptable minimum quality of consistent UI (and to a lesser degree, a reasonable UX) for both the website creation process and its use by customers once deployed. This was another reason why templates were so safe and effective (for product managers and development leads)..

This fundamentally changed the scope of the engineering work. Previously, engineers were responsible for creating everything down to the smallest button as well as developing unique content. Now, companies were able to focus their limited resources on creating custom content, running web-campaigns, and responding quickly to their customer’s needs and challenges.

employees are 125% more productive when inspired by high value work

Time, Talent, Energy By Michael Mankins and Eric Garton

Some key benefits of CMS 

  • Marketing/Product-Management owned the website. They were empowered and ultimately responsible for what website is in production. This sense of ownership generally increased quality, as well as timely website updates. Decisions of when and how to create “custom” elements could be planned, discussed, and iterated on — thus improving quality and predictability.
  • Teams were able to iterate rapidly. No more chafing under the imposed slowness of months-long waterfall cycles. Most changes could be handled in minutes or hours, instead of days or weeks. Larger efforts could be telegraphed weeks or months in advance; customer feedback could be solicited and integrated; even A/B testing became possible for most companies.

Today, the CMS website based approach is the default for many (if not most) B2B companies.

Complexity of Web Applications

While templates and drag-and-drop editors (also known as WYSIWYG or what you see is what you get) work quite well for websites, they fail to deliver for web-based applications. Even though they are also displayed in a browser, web-based applications are a different beast.

Webpages are primarily for information and marketing, allowing a potential/existing customer to understand what the company offers. The available options for interactivity are generally low, often including  search functionality, pricing/payment or form completion.

Web applications, however, are full-fledged applications in their own right. They allow an end-user to perform tasks that are a critical part of their job. Users (especially business users) depend on complex workflows that contain stateful information across multiple screens. They must investigate, configure, troubleshoot, monitor, and visualize data to make critical decisions for a business, hospital, or infrastructure. Unlike websites, application usage must:

  • Allow users to discover and access data at multiple levels of granularity
  • Cross-link data to follow trails of information
  • Provide support/help systems for when users get stuck
  • Configure complex systems
  • Maintain state to reduce their cognitive load

Further complicating matters, the variation between products and the uniqueness of the information being presented to users means that web application templates are not up for the job. It is not that they haven’t been tried. There are tons of websites that sell web-app templates. Yet their adoption remains low, and the reason for that is plain to see. Unlike websites, where simply providing a variety of colors, pictures, and text is typically good enough, each web application is unique: their data, workflows, and use-cases cannot be addressed by a one-size-fits-all solution.

The complex relationships between constantly changing data and the evolving workflows to be executed means that static templates could never hope to keep up with all the possible paths and interactions a user may need to have. 

This degree of interaction and data complexity also limits the utility of drag-and-drop/WYSIWYG tools. Information hierarchies, workflows, layouts, and data visualizations (to name a few) must be carefully designed and considered. So even someone can drag and drop whatever they want, they still must decide WHAT to drag and WHERE to drag it to. Using these tools, a creating user can produce a “compilable” UI but through lack of expertise, time, and/or planning their design can violate basic UX and workflow principles.  As a result they are likely to be left with a poorly designed outcome. Thus, the adoption of this class of solutions has also been relegated to (at best) simple applications.

For teams to deliver high-quality products, the UI/UX must be deliberately designed and the UI must be carefully implemented by hand, using highly-skilled, highly-paid designers who have expertise in the architecture, creation and implementation of a quality user experience. This does not scale well.

The Promise of WYSIWYG

All the limitations above being considered, WYSIWYG tools are reasonably effective for one particular UI/UX use-case: the creation of limited or focused UI. In data science or natural language processing (NLP), these techniques work better when the data set’s scope / vocabulary is limited. For example, it is far easier to build a system that can understand only legal text or doctor’s notes (each of which has its own constrained structure/style), than a general purpose system that can understand any kind of unstructured text. By limiting the types of words, and the way those words can be used, these types of algorithms can be trained and optimized for more rigid and structured real-world usages. As a concrete example, medical dictation software (something that sounds like it should be a more recent solution) was used even in the 1990s simply because of the limited and constrained nature of doctor’s notes.

The same is true for WYSIWYG product UI creation. Consider data entry builders. These are helpful tools that allow people to create solutions for data entry; forms, basic summary statistics, and raw-record browsers (think spreadsheets). Likewise, tools that do basic data lookup and presentation (e.g., recipe finders) can also be designed and implemented with WYSIWYG. The behavior, layout and tasks of these applications are so limited in scope that these tools can constrain creating user behavior sufficiently, and, hence, can ensure a successful outcome. This is especially true when the UI layer is almost a mirror of the data layer: for example, form apps, that read and write to a basic relational database, so that their visual presentation is nearly identical to the underlying database schema.  In short, WYSIWYG can empower many users to build applications – but the scope and complexity of those apps (to ensure high quality UI and UX without having expertise) is limited.

The Consumerization of the Enterprise Experience

A new era is emerging in the B2B product space: the Consumerization of the Enterprise Experience. This is a combination of:

  • the proliferation of high-quality consumer software solutions;
  • the migration of tools from consumer into enterprise; and
  • some companies putting a premium on designing great UI/UX

These trends have resulted in a massive shift. Time and again, we see companies with fewer features and less (or no) history come in and dominate existing players. Disruptors like Box, Meraki, iPhone, PagerDuty, Gsuite, and Slack have supplanted and disrupted the existing markets simply because their look-and-feel, usability, and overall end-user experience felt like a well-designed consumer product (not like enterprise software). Employees expect and demand that their required business apps should be as useful and flexible as those they use at home on their computers, smart TVs, or phones.

To achieve this level of usability, these new applications have required a fairly significant upfront investment to set up, although once properly established, good UI/UX empowered these companies to leapfrog the competition.

Unfortunately, this is an extremely difficult strategy to execute on. Companies have limited resources: time, people, and budget. Even worse, there are increased talent shortages (lack of skill, high cost, and unrealized outsourcing help), broken internal processes (handoff delays, long development cycles, slippage no user feedback), and siloed solutions (existing tools are segregating teams) exacerbating the problem.

Access to developers is a bigger threat to business than access to capital
Stripe

[Projects] experienced cost overruns of 150 to 200% [and] experienced time overruns of 200 to 300%
The Standish Group

Even the most ardent supporters of good UI/UX simply may not be able to find the budget and people to successfully execute on time.

 

The Future is Automation

Templates don’t work. WYSIWYG won’t work. And manual efforts do not scale. Yet companies need to avoid being outmaneuvered by their competition. 

But take heart, help is on the way! We are Kleeen Software and we are leading the way to a revolution of how B2B companies design and build UI. 

As the tenets of our revolution, we have taken 3 key pillars:

  • Build More, Faster – even if you don’t have the UI/UX/Eng expertise
  • Make Stunning Designs – with usable, high-quality code
  • Free Up Your Resources – take your time, money and talent and put it towards developing your differentiating product features and showcasing your unique value proposition

Doing more with less, freeing up resources, and having reliably good output is the hallmark of the automation movement. 

And this is why the future for UI/UX is so bright. Numerous technologies under the very broad umbrella of “AI” have characteristics that could help turn the art of UI/UX into a repeatable science. Imagine a solution that could help teams plan, design, validate, code and deploy a product’s UI (with a compelling UX and workflows) – without creating a non-functional mockup or writing a line of code? How could multiple automation technologies come together to accelerate that process? 

Please watch this space for upcoming announcements as we (in stealth for now) work closely with a few design partners, helping them get their UI/UX visions into production at scale. 

If your team is working through similar challenges and are interested in joining our hands-on pilot, we’d love to chat.

Cover Image by Edho Pratama on Unsplash