UX/UI has no business rules

I am involved in a project that designs a browser based application. The customer has very specific ideas about the way the UI/UX aspects. As Forrester states: “Ultimately any service must meet the customer’s needs, be easy to use and enjoyable – the three facets of customer experience.”

UI (User Interface) and UX (User Experience) are related concepts. In practice the difference is fuzzy, to say the least. In theory, UI is about the buttons, drop-down lists, colors, and other elements on a user interface, while UX is about the whole user experience (like how easy can one switch between tasks, or how responsive a user interface is to user actions). UX is mostly about the joy of using a user interface.

I found that it can be hard to define the demarcation point between the UI/UX part and the rest of the application. In older applications, there was no real border between both. But splitting the UI/UX layer from the rest of the application components is very beneficial.  

The main rule is that the UI/UX layer should not have any business logic; all business logic must be implemented in the underlying application. This allows using multiple user interfaces with the same application. For instance, a modern browser, but also older browser versions, mobile apps on tablets of phones, an interface for disabled people, or whatever comes next.

The user interface should only help users to get a better experience. In theory, a text-based interface (green screen) should suffice to operate the application via its API services. The UI/UX layer is just helpful for humans, but does not improve or extend the business functions of the application.

For instance, the user interface could have a drop-down list to select a value. In theory, such a value could also be entered manually with the same functionality (but it could lead to errors when a value is mistyped). Therefore, drop-down lists are part of the UI/UX layer. When the user interface is ported to a mobile app, this app could use another interface to select a value. In all cases, the application and its API service is unchanged. This means that UI/UX is all about non-functional requirements, not about application or business functionalities.

In general, the release cycle of user interfaces like mobile apps is much faster than that of functional management, or software development. Where software development to create new functions typically takes months to get into production, and changes on the functional management layer could take weeks, changes on the UI/UX layer could be done in days. This allows for frequent updates of the user interface and a constant increase of the user experience.

But to allow a new version of a user interface to work seamlessly with the underlying application, it is essential for the app to have no business logic. Instead it should use the API services of the underlying application(s) on the server. This allows for instance for changing one user interface to benefit from the latest browser enhancements, while still providing an unaltered user interface to users of older browsers, without changing anything on the appliation or its API services.

The question is how to handle functionalities like spell checkers or auto-fill fields like Google uses. Strictly speaking, these functionalities are only helping the user to get a better experience. For instance, most applications would still work when words are mistyped in a text editor. The spell checker is only helping the user and enhancing the user experience. Therefore, a spell checker is part of the UI/UX. But to have a functional spell checker, system calls are needed (it makes little sense to load a full dictionary in the user interface of a web browser; the typed words are typically checked against a dictionary on a server using a API service). Therefore, a API service is needed, which is a service-side application component. As this type of UI/UX functionality is typically used in a number of applications, in most cases one generic service is used by the UI/UX layers of multiple applications. But architecturally, it is still a UI/UX component, as it has no business function.


This entry was posted on Friday 18 July 2014

Earlier articles

Infrastructure as code

My Book

DevOps for infrastructure

Infrastructure as a Service (IaaS)

(Hyper) Converged Infrastructure

Object storage

Software Defined Networking (SDN) and Network Function Virtualization (NFV)

Software Defined Storage (SDS)

What's the point of using Docker containers?

Identity and Access Management

Using user profiles to determine infrastructure load

Public wireless networks

Supercomputer architecture

Desktop virtualization

Stakeholder management

x86 platform architecture

Midrange systems architecture

Mainframe Architecture

Software Defined Data Center - SDDC

The Virtualization Model

What are concurrent users?

Performance and availability monitoring in levels

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Infrastructure Architecture - Course materials

Introduction to Bring Your Own Device (BYOD)

IT Infrastructure Architecture model

Fire prevention in the datacenter

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

The first computers

Open group ITAC /Open CA Certification

Sjaak Laan


Recommended links

Ruth Malan
Gaudi site
Byelex
XR Magazine
Esther Barthel's site on virtualization


Feeds

 
XML: RSS Feed 
XML: Atom Feed 


Disclaimer

The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.

 

Copyright Sjaak Laan