AIoT Usage Viewpoint

From www.aiotplaybook.org
Jump to navigation Jump to search
Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Usage 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 is 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.

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

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 in which assets are deployed. Additionally, usage patterns 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 the usage of the product in a realistic environment. Alternatively, in the case of our Vacuum Robot, different scenarios for testing the robot must be made available, including different room types and different floor surfaces (wood panels, carpets, etc.).

Personas

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

AIoT Personas

The UX Viewpoint should define a comprehensive set of personas that help model the product features in a 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 such as 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 focuses 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 important not only 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 usability. Another important factor is the question of 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 upselling and digital add-on services.

UX/HMI for Vacuum Robot

The HMI strategy for ACME:Vac seems relatively straightforward at first sight: HMI features on the robovac are reduced to a minimum, including only some status LEDs and a reset button. Instead, almost all of the user interaction is done via the smartphone app. In addition, some basic commands such as 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 evolvability (a physical HMI cannot 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 the case of bad connectivity or unavailability of a required cloud backend, the entire physical product might become entirely unusable.

Mockups / Wireframes / Prototypes

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 smartphones or tablets. They should initially be kept on the conceptual level. Tools such as Balsamiq offer a comic-style way of creating mockups, ensuring 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 save 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 and replacement of the garbage bag.

Authors and Contributors

Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

AUTHOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.


Michael Hohmann.jpg
MICHAEL HOHMANN, BSH HAUSGERÄTE GMBH
CONTRIBUTOR
Dr. Michael Hohmann works as a Systems Engineer in the field of autonomous cleaning robots at BSH. After studies in Mechanical Engineering and Measurement Science at TU Ilmenau he joined the Bosch Roxxter development team at BSH robotics department.