Why we need Automation for UI/UX

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.