Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Usage Viewpoint


UX Viewpoint

The goal of the UX (User Experience) viewpoint is to provide a holistic view of how the product or solution will be utilized by the user and other stakeholders. Good UX practice usually includes extensive product validation, including usability testing, user feedback, pilot user tests, and so on. A good starting point are usually customer surveys or interviews. In the case of an AIoT-enabled product or solution it can also make sense to include site surveys to better understand the environment of the physical products or assets.

In order to ensure realistic and consistent use cases across the design, a set of personas should be defined, representing the typical users of the product or solution. Revisiting the User Journey from the initial business design helps clarify many details. Finally, HMI (Human-Machine Interaction) design, early prototypes and wire frames are also essential elements of the UX viewpoint.

Site Surveys and Stakeholder Interviews

In order to capture and validate requirements, it is common practice for IT projects to perform stakeholder interviews. This should also be done in case of an AIoT product/project.

However, an AIoT project is different in that it also involves physical assets and potentially also very specific sites, e.g. a factory. Requirements can heavily depend on the type of environment the assets are deployed in. Also, usage pattern might vastly differ, depending on the environment. Consequently, it is highly recommended for the team responsible for the product design to spend time on-site and investigate different usage scenarios in different environments.

While many AIoT solutions might be deployed at a dedicated site, this might not be true for AIoT-enabled products. Take, for example, a smart kitchen appliance, which will be sold to private households. In this particular case it can make sense to actually build a real kitchen as a test lab, to test usage of the product in a realistic environment. Or, in the case of our Vacuum Robot, different scenarios for testing the robot must be made available, including different room types, different floor surfaces (wood panel, carpet, etc), and so on.

Personas

Personas are archetypical users of the product or solution. Often, personas represent fictitious people which are based on your knowledge of real users.

AIoT Personas

The UX Viewpoint should define a comprehensive set of personas which help with modeling the product features in way that takes the perspective of different product users into consideration. By personifying personas, the product team will ideally even develop an emotional bond to key personas, since they will accompany them through an intense development process. A persona does not necessarily need a sophisticated fictitious background story, but at least it should have a real-world first name and individual icon, as shown in the example below.

User Journeys

The initial User Journeys from the Business Model design phase can be used as a starting point. Often it can be a good idea in this phase of the product design to create individual journey maps for different scenarios, adding more detail to the original, high-level journey.

The example user journey for ACME:Vac shown here is not that different from most user journey designs found for normal software projects. The main difference is that the user journey here is created along the life cycle of the product from the customer`s point of view. This includes important phases like Asset Activation, Asset Usage and Service Incidents.

Customer Journey for Vacuum Robot

From the point of view of a Digital Equipment Operator, the user journey most likely focus less on an end-customer, but more on the different enterprise stakeholders and how they are experiencing the introduction and operations of the solution. Important phases in the journey here would be the solution retrofit, standard operations, and what actually happens in case of an incident monitored or triggered by the solution. For example, for a predictive maintenance solution it is not only important to understand the deep algorithmic side of it, but also how it integrates with an existing organization and its established processes.

UX / HMI Strategy

The UX/HMI strategy will have a huge impact on useability. Another important factor is the question, how much the supplier will be able to learn about how the user is interacting with the product. This is important, for example, for product improvements, but also potentially for up-selling and digital add-on services.

UX/HMI for Vacuum Robot

The HMI strategy for ACME:Vac seems relatively straight forward at first sight: HMI features on the robovac are reduced to a minimum, only including some status LEDs and a reset button. Instead, almost all of the user interaction is done via the smart phone app. In addition, some basic commands like starting an ad-hoc cleaning run are supported via smart home integration.

It is important that the decision for the HMI strategy will have a huge impact not only on usability and customer experience, but also on many other aspects such as product evolveability (a physical HMI can not be easily updated, while an app-based HMI can), customer intimacy (easier to learn how a customer is using the product via digital platforms), as well as the entire design and development process, including manufacturing (none needed for app-based HMI).

However, the risk of completely removing the HMI from the physical product should also not be underestimated. For example, in case of bad connectivity or unavailability of a required cloud backend, the entire physical product might become entirely unusable.

Mockups / Wireframes / Prototypes

In order to ensure a good user experience, it is vital to try out and validate different design proposals as early as possible. For purely software-based HMI, UI mockups or wireframes are a powerful way of communicating the interactive parts of the product design, e.g. web interfaces and apps for smart phones or tablets. They should initially be kept on the conceptual level. Tools like Balsamiq offer a comic-style way of creating mockups, making sure that they are not mistaken for detailed UI implementation designs. The figure shown here provides a mockup for the ACME:Vac floor map management feature on the ACME:Vac app based on this style.

Example Wireframe for Vacuum Robot

It should be noted that the validation of the UX for physical HMI can require the actual creation of a physical prototype. Again, this should be done as early as possible in the design and development phase, because any UX issued identified in the early stages will help saving money and effort further downstream. For example, while the HMI on board the ACME:Vac robot is kept to a minimum, there are still interesting aspects to be tested, including docking with the charging station, replacement of the garbage bag, and so on.