Menu

Design Portfolio

Leading Change

,

This course provided knowledge about change processes and strategies, insights into the role of change leaders, corporate cultural transformation, and the driving forces that influence and contribute to change. It introduced concepts, tools, and practical examples of change processes within organizations, developed in collaboration with fellow students from both private and governmental leadership positions.

Key Takeaways

The course equipped me with concrete strategies and methods for understanding organizational change in complex environments like IBM and for successfully implementing innovations, such as AI, into existing delivery teams.

  • Understanding the complexities of change.
  • Understanding change processes in organizations.
  • Understanding and transforming corporate cultures.
  • Recognizing different organizational types and their relation to change.
  • Developing change plans using E- and O-strategies.
  • Applying standard change methodologies to change projects.

 


his.se
Förändringsledning I G1N.

Work Order Intelligence

,

Introduction

The new generative AI capabilities Maximo Application Suite (MAS) 9.0 are the next steps in the Maximo AI roadmap.

The 2024 release of MAS 9.0 is putting the focus on optimizing work order efficiency using generative AI powered by IBM watsonx™. The AI design is delivering on an AI strategy to compel business users to start consuming AI in small steps that deliver business value and progressively leads to increased usage at scale.

  • We are focusing on the business user and the business value.
  • We are providing value out-of-the-box
  • We are providing AI infused into adopted workflows and data
  • We are providing lifecycle support for models with watsonx

Work Order data quality and process automation AI helps automate the work management workflows and better support for decision making in Manage.

Objective

We will deliver improved efficiency, at the scale of thousands of hours, in everyday work order management by providing more accurate failure code recommendations as compared to current achieved by the organization.

User Research

Research objectives

Multiple qualitative user research projects were conducted as part of the asset management AI strategy and product usage studies, involving sponsor user groups and stakeholder interviews to identify business needs and validate proposed designs.

We sought to understand which personas would benefit most from AI-infused data and how generative AI could enhance their efficiency. Additionally, we explored how users perceive and trust AI recommendations, and we defined how trust in AI systems impacts adoption and usage.

Research targeted both internal and external stakeholders, including Maintenance Managers, Asset Managers, Operation Managers, Reliability Engineers, Technicians, and Business Partners.

Conclusions

“Even small gains in accuracy can have an enormous impact to an organization when it can be applied at scale.”

Organizations today are early in their adoption of Gen AI. Their organization lacks the AI governance and structures needed. Operations are focused on achieving short-term benefits and lack of high quality data is a challenge.

Organizations expect significant value outcomes from generative AI:

  • 10% increase in productivity: Access to recommended problem codes and related job plans will enhance fix rates, leading to cost savings and improved work productivity.
  • 10% increase in compliance: AI recommendations should utilize internal guidelines, regulations, rulings, and data.
  • 20% decrease in asset failures: As reliability engineers leave the workforce, generative AI models are needed to bridge skill gaps by leveraging learnings from historical data.

IBM AI Design

The Work Order Intelligence design is based on ‘Carbon for AI’ in the IBM Carbon design system.

Carbon for AI is an extension of the IBM Carbon design system, designed to give AI instances in IBM products a visually and behaviorally distinct identity. Generative AI introduces a range of new responsibilities when designing experiences, particularly regarding trust, transparency and explainability. Carbon for AI is the common design framework for identifying AI-generated content and delivering explainability in IBM products.

Carbon for AI is mandatory when introducing AI capabilities in IBM products. As IBM Software design leaders we are meeting weekly to share scenarios, review UI and unify usage of Carbon for AI.

AI label and styling

The AI label is a component used as an indicator of AI in the user experience. It is intended to be used in any scenario to identify context generated by AI. It enforces transparency, explainability and feedback. It also becomes the focal point for actions on AI-generated data..

Work Order Intelligence
The AI label components.

Explainability

The AI label contains the AI Explainability Popover, which provides a layer of explainability to the user. It provides a consistent summary of relevant model information and offers the option to dig into more details if needed. This may include an explanation of how the AI capability works, the model confidence, the model used, and its version.

Work Order Intelligence
The AI Explainability Popover.

Scenario

The end-to-end Work Order Intelligence scenario crosses over multiple maintenance roles and workflows. The main personas are Maintenance Managers, Maintenance Supervisors, Reliability Engineers, Domain Engineers, and Technicians.

First, new work orders are created by technicians from inspections and maintenance tasks. The technician describes the impacted asset, its location, a short and optionally long description of the problem. If known by the technician, the class of failure is provided, and a specific problem code is recorded. 

After the work order has been saved, Gen AI makes an inference and predicts the problem codes that best match the work order description. Additional information is also used in the prediction. The predicted problem codes with the highest confidence are captured. 

Maintenance Managers and Maintenance Supervisors use the operational dashboard and work queues to drive the work order review workflows at scale. With Work Order Intelligence, the work orders requiring attention may be identified using the ‘WOs with problem code recommendations’ work queue. The number of WOs in the queue is directly visible on the operational dashboard. 

When the Maintenance Manager or Maintenance Supervisor reviews the work order, the problem codes recommended by Gen AI are presented in the work order editor using the AI label. The Maintenance Manager views and chooses the best recommendation. Also, before closing a work order, the Maintenance Manager ensures the problem code is updated and matches any additional information or conditions discovered during the maintenance tasks. This ensures that the quality of historical asset data is continuously improved.

A Reliability Engineer may later review problem code recommendations and provide feedback to the model by identifying and tagging good examples of work orders. Retraining the model with such selected work orders improves its accuracy..

Design

Operational dashboard

The operational dashboard is the one-stop destination for the most critical KPIs and access points to maintenance workflows. Work Order Intelligence design identified the need to create a workflow using a work queue that selects all work orders requiring attention. A work queue, ‘WOs with problem code recommendations,’ should be added to the dashboard for that purpose.
Work Order Intelligence
Operational dashboard with Work Order Intelligence work queue.
Work Order Intelligence
Work Queue selecting all Work Order with problem code recommendation.

Work Order application

The work order application in Maximo Manage is the user experience for most work order related workflows. The application consists of two experiences; a list view page and a details page. The list page displays all, or a filtered set of, work orders. Work Order Intelligence design suggests a predefined view that filters all work orders with recommendations. The work order editor, or details page, is extends the standard editor by infusing AI generated data. New problem code recommendations are highlighted.
Work Order Intelligence
Work Order Intelligence
WO application and  and editor w/ problem code recommendation.

Problem codes and AI recommendations

Problem code recommendations can be inspected with details on the AI model confidence score. The best-fitting code can be selected for the work order. A user can also override any recommendations as decided.
 
The Gen AI capability generates new recommendations if the work order information is refined or updated. The recommended code may remain unchanged, or new information may generate an updated code with higher confidence.
Work Order Intelligence
Problem code recommendations for a work order.

Model management

Work Order Intelligence uses two separate AI models in its implementation.
 
  • Problem code predictions are performed by a classification model trained on high-quality work orders spanning all problem codes. The model uses the work order descriptions to classify the problem codes.
  • To achieve a large training and testing dataset of work orders, a second large language model uses a selected set of work orders to synthetically generate a larger dataset of work order variants. Improved model accuracy is achieved using the generated synthetic dataset.
Selecting work orders for model training is performed in the Work Order application, typically by a Reliability Engineer. The model configuration, models, and model training actions are managed by the system administrator in the AI configuration application.
Work Order Intelligence
Add work order to model training set to improve classification model accuracy.

Business Outcome

On June 25, 2024, IBM announced the availability of the 9.0 release of the Maximo Application Suite. Maximo Manage 9.0 introduces AI intelligence to the Maximo work management process with the new problem code classification capability. Maximo Manage 9.0 builds on a long history of AI capabilities in Maximo Monitor and Maximo Visual Inspection.

Work Order Intelligence AI in Maximo was presented at Maximo World 2024.

 


IBM.com
Maximo Work Order Intelligence: Where AI meets maintenance excellence.

 


carbondesignsystem.com
Learn more about Carbon for AI.

Visioning design practice

,

Visioning is a time-boxed design activity answering questions on strategy, approach, and experience and coming to a shared understanding of strategic objectives.

Introduction

Visioning projects are identified in a roadmap backlog and define the WHY and WHAT to build, but not HOW to build it. Visioning should define the strategy, ask and answer questions, and explore possibilities. Visioning ensures a shared understanding across stakeholders and sponsors.

Visioning precedes concepting and implementation, with the objective to produce hills and epics for the product roadmap backlog.

Visioning projects are led by a senior designer or strategist, working in a core team across leaders of design, product, development, and research.  A wider team of stakeholders, sponsors, and SMEs are providing guidance, and feedback, continuously or at playbacks. 

Visioning uses market and user research, competitive analysis, ideation, and alignment workshops. Visioning also makes the strategy tangible through conceptual prototypes. Information and data architectures are ways to structure workflow experiences. 

The vision projects preferably use agility, by working in sprints or workflow models, addressing objectives and questions in order. The team engages sponsors continuously, or through sprint playbacks.

Smaller vision projects may run for 3 sprints, larger projects may run for a quarter or two. The project ends with a Playback Zero stating the unity of the core team and sponsors on the resulting Hills and Epics in the roadmap.

Vision backlog

Visioning is a part of the product and portfolio roadmapping process.

Product initiatives are created by product management and form the bridge between our strategy and work as a ranked backlog. Some initiatives may require strategic research or visioning, and are tracked as a visioning activity in the backlog. These initiatives may lack clarity or alignment of intent and strategy in the evolution of the product or portfolio.

During monthly reviews, the vision backlog is reviewed, prioritized, and vision projects are initiated based on size, scope, and available resources.

Link
Visioning design practice
Figure. Vision backlog process.

Types of vision project

There are different kinds of Visioning projects. Here are a few example types:

  • Exploratory vision projects take a more strategic research perspective with activities on competitive research, user research, concept testing and hill writing. The outcomes may be a strategic North Star vision, and demonstrations of key experiences.
  • Strategy and alignment vision projects take a more collaborative perspective with alignment workshops that unify the team around the roadmap direction. The outcomes may be more informative with hills, storyboards, and delighter and satisfier experiences.
  • Experience definition vision projects take a more concepting perspective that drives end-to-end flows and MVP experiences. The outcome is the product-level personas, hills, to-be storyboards, and resulting information architectures.

Defining a vision project

A good practice is to ‘Start with the end in mind’.

Start by understanding the objectives to meet and the questions to answer. The product management function is responsible for the roadmap strategy and defines the vision project. Make sure the vision definition is well-formed and has a clear ‘done criteria’. If the vision definition is not well-formed, use a Sprint 0 and an alignment workshop to get input from multiple sources for the definition. Use voting or prioritization methods to resolve conflicts.

Use a vision project template to ensure well-formed definitions.

Team

  • Exploration Lead: [Name of sponsor/main owner]

  • PM: [Name]

  • Design: [Name]

  • Development: [Name]

Timeline 

  • Visioning and research: [Target date]

  • Estimated date for concepting: [Target date, likely at the quarter level]

  • Estimated date for delivery: [Target date, likely at the quarter or half level]

Problem Framing 

  • [Short 1-2 paragraph ‘setting the scene’ statement that provides context for the problem this project will solve.]

Problem description 

  • [List the problems that our customers and their users are facing that this vision project would seek to better understand and set a direction for solving.]

Visioning Goal 

  • A visioning cycle would help us understand: 

  • [List]

Desired Deliverables 

  • [Eg: Competitive design analysis, Finalize persona research for X, As-is flow including screenshots, User research with X type of users to understand pain points and needs when Y, Design led workshop with X users, Prioritization of goals that X users are trying to solve, To-be story-boarding of UX journey, etc]

Questions to Answer 

  • [Eg: What tools are X users using today to make decisions? and how closely are these tied together? and where are there gaps?]

Target Users 

  • [Eg: Administrators, Operators, Technicians]

Example Customers/BPs 

  • [List customers and partners that the team can use as examples, and/or perform validation & research on for this project].

Risks 

  • [Outline risks faced if this visioning does not happen or is not successful]

Suggested/Expected Activities 

  • [Eg: Visioning kickoff with stakeholders to align Opportunity challenge & Visioning mission, Research with X users from target customers identified by PM, etc]

Resources 

  • [List any helpful resources or reading that may support or inform the vision project.]

Competitors 

  • [List]

Reference Materials 

  • [List any helpful resources or reference materials that may support or inform the vision project.]

Leading a vision project

Vision project are advised to use agile principles. By working in sprints the core team addresses objectives and questions in order and stay focused on a smaller set of questions while continuously making process and receive feedback to validate outcomes. Plan the sprint with clear objectives. End the sprint with a playback to sponsors. Declare the objectives for next sprint. And end the vision project with a Playback Zero stating the unity of the core team and sponsors. Set an expectation on project end date and playback zero.

Agree at start of the meeting cadence of core team meeting and playbacks. Work continuously in the core team, by meeting every or every second day. No less than weekly. Be sensitive to core team workload and other responsibilities. As a vision lead, manage the team calendar and invitations. Keep a backlog list of meeting topics from the sprint objectives. Plan 3-5 meetings ahead, minimally for next meeting.

Forming the vision team

Establish a core team from product PM, design, development, and key Subject mater experts (SMEs), to minimize knowledge transfer and enable rapid decisions. Work close in a 3-in-a-box.

Form a sponsor team with related Product Managers, Design leads, Development leads, and Architects, Technical and User Research, SMEs, and Executive sponsors.

Start the project with a 30 min Vision Project Kick-off with the core and extended team focusing on the project objectives and expected outcome. On indications that the objective is not well-formed or agreed, add a Sprint 0 to reach unity on the definition. Use a vision project kick-off template to guide at the first visioning team meeting, including Objectives, Preliminary hill, Questions, Project plan dates, Vision team and Stakeholders.

Perform competitive analysis

At the start, create an understanding of the bigger business context by analyzing the market and competitors. In cases where the market is less understood, start with a Strategic Research project.

In the competitive analysis

  • Research competitive solutions.
  • Compare solution capabilities.
  • Identify, list, and rank gaps.
  • Align insights with strategy.
  • Identify requirements and epics.

Running the vision project

Be artifact driven

Collect and share visioning artifacts

  • Quickly pull together information from multiple sources to feed innovation
  • Use collaboration tools for quick information collection, discussions, and documentation
  • Accelerate team sharing and learning
  • Accelerate decisions to a shared direction

Be design experience driven

Collect, classify and organize product screens by comparative capabilities

  • Analyze common patterns
  • List and rank experiences
  • Identify opportunities for reuse
  • Add to requirements, strategy and epics

Use scrapbooking

Use Mural for rapid design and scrapbooking

 

  • Quickly pull together page designs from existing and new concepts and patterns in bits and pieces
  • Playback purpose, scenario, concept, ideas, and experience
  • Capture quick feedback for the next iteration

Use information modeling

Model artifacts and relationships

  • Explore data and workflows in scenarios
  • Create information models with artifacts and relationships
  • Extend models across products and portfolios
  • Identify system or record
  • Prototype experiences and points of integration
  • Add to strategy and epics

Be test driven

Test early and often. In vision projects, one decision leads to next decisions in a dependency chain. Early testing at playbacks allows for early validation and changing of direction before spending too much time in a chain of decision dependencies.

  • Seek continuous feedback
  • Use rapid prototyping, like scrapbooking, for rapid daily validation
  • Use scenario flow prototypes for sprint playback

Manage the vision content

Be document driven. Document the strategy through hills, concepts, prototypes, and epics in the backlog. Express vision in the staged release plan.

Be formal in the management of content. The material assembled and produced will be your legacy to any following concepting and implementation workstreams. Do not leave all insights only in the head of the core team. Document the details of the vision outcome for new teams concepting and implementing the vision.

Use  corporate collaboration tools.

  • Create a Slack channel for team collaboration. Start with the core team and grow to the extended team after sprint 0.
  • Create a Mural room for visioning activities. Consider a private Mural room or sub-folders to control open and confidential material.
  • Create a Box project folder for all project files.

 

Suggested box folder structure:

 

/vision-name
   /PLAN
   /MEETINGS
   /PLAYBACKS
   /DESIGN
   /MURAL
   /PROTOTYPES
   /RESEARCH
   /REQUIREMENTS
   /CONCEPTS
   /RELATED

Conclusions on best practices for visioning 

Best of luck with your vision projects!

Remember to

  • Manage a backlog of visioning projects
  • Start with well-formed visioning questions to answer
  • Establish a core team from product PM, design, development
  • Use agility and work in sprints with playbacks
  • Prototype and show, don’t tell
  • Look for reusable patterns
  • Validate early and often with stakeholders and sponsors
  • Conclude with a Playback 0 unifying the team on hills and epics, and concepts.

 

Lig

Link
Lig
Lig
Lig

IoTEdge-GwType_1

Image 1 of 6


IoT Platform Developer Experience
Design research on the developer experience in the Watson IoT Platform.

Robot Monitor Scenario Design

,

The Robot Scenario Context

The Robot scenario is a rapid design demonstration scenario on the use of Anomaly Monitoring and Monitor Dashboards in Maximo Asset Monitor.

The scenario outlines a fictitious manufacturing company ACME with 4 production sites in the US. The sites are located in Alphaville, Betacamp, Charlyton and Deltalake. The production assembly lines at the sites have robots instrumented with sensors connected to the IoT Platform cloud service running as part of the ACME Maximo Asset Monitor tenant. The robots report data metrics from the robot arm on torque, load, speed, and acceleration at 5- minute intervals.

Over the last few days, one of the robots in Alphaville has been anomalous data values on robot arm torque. Also, the speed and acceleration of the robot arm seem to be impacted. The alerts from the robot are notified to the operator at the ACME remote operations team. Bryan the operator will start a root-cause investigation and troubleshoot the abnormal values. Once he has validated the alert he will create a service request for the maintenance engineering team in Alphaville to resolve the issue before the robot breaks and causes a halt to the production line.

Simulating the ACME Robots

The robots in this scenario are simulated on the IBM cloud using a NodeRed flow. The simulator sends robot data events every 5 minutes as MQTT messages to the Watson IoT Platform service included and preconfigured in Maximo Asset Monitor. The event contains robot data for load, torque, speed, and acceleration using the following MQTT event message schema in JSON format.

    {
       “load”: 375.65,
       “torque”: 10.855,
       “speed”: 2.503,
       “acc”: -0.164
    }

The simulated data is mainly random values within a set range for each metric. To simulate anomalies, random data spike values are added to the torque data to show reoccurring abnormal data indicating a possible root cause of a future robot failure.

Link
Robot Monitor Scenario Design
Anomalous ACME Robot torque values at Alphaville site.

Configuring Anomaly Detection

All ACME Robots in this scenario is of the same type and send the same torque, load, speed, and acceleration sensor data. The robots are monitored as an ACME_Robot entity type with torque, load, speed, and acc metrics. Maximo Asset Monitor provides an out-of-the-box catalog of anomaly model functions that can be configured with data metrics as inputs. The model computes an anomaly model score. The score is a likelihood of anomalous data within a time window of data samples. The anomaly function scans the time-series torque data and produces a time graph of anomaly scores. Maximo Asset Monitor provides a predefined set of anomaly models. In the robot scenario demonstrator, we are using a saliency-based generalized anomaly scoring model. The model employs Saliency and GAM on windowed time series data to compute an anomaly score from the covariance matrix. An alert function in Maximo Asset Monitor can be configured with the anomaly model score as a parameter to compare with a set threshold. If the score is above the threshold an anomaly is detected and an alert is created. In this scenario, the torque anomaly alerts are set to trigger alerts at a threshold of 100. 

Link
Robot Monitor Scenario Design
Maximo Asset Monitor analytics function catalog with out-of-the-box anomaly models.
Link
Robot Monitor Scenario Design
ACME Robot torque score values generated by the anomaly model. Score values above 100 are set to generate anomaly alerts.

Configuring Robot Dashboards

Maximo Asset Monitor provides two types of operational monitor dashboards; Summary Dashboards and Entity Dashboards.

A Summary Dashboard is a dashboard-type that presents aggregated KPIs and provides drill-in to aggregated metrics using hierarchical filters. Let’s decompose that statement a bit. For the operators at ACME, the Robot Summary Dashboard presents an overview of KPIs across all ACME sites. And it allows a drill-in to a selected site, a selected line, and a selected robot. Robot data, resulting from the selected filter, is aggregated and presented as statistical units. For example, maximum, minimum, and mean values across all robots passing the filter. Data is also aggregated across a time grain. For example by the hour, by day, by week, by month. This allows the KPIs to be tracked and compared over various levels of the organization and at shorter or longer time ranges. A screenshot of the Robot Summary Dashboard is given below. The screen shows filtering the KPIs of the robots to an hourly report of the Alphaville manufacturing site. 

Link
Robot Monitor Scenario Design
ACME Robot summary dashboard.

An Entity Dashboard is a dashboard that presents the operational metrics of a single entity. In this scenario a single robot. Metrics from a single entity can be presented without any aggregation and in near real-time. Robot metric values and anomaly alerts are presented on values cards, tables, and graphs on the dashboard. The Robot Entity Dashboard for one of the robots at Alphaville is shown below.

Link
Robot Monitor Scenario Design
ACME Robot A1 entity dashboard.

Monitoring Alerts

Operators approach the task of monitoring by identifying and prioritizing alerts on the Alerts page, or by identifying ‘assets in trouble’ using Summary Dashboards.

Maximo Asset Monitor provides an Alerts page that summarizes all alerts across all types and entities in the system. An ACME operator may filter the Alerts to identify the most critical alerts on the most critical assets and start the root cause analysis by following the link on the alert to the entity raising the alert. An example of the Robot Alert Page for the ACME robots is presented below.

As shown on the screens above, alert tables may also be included on summary dashboards and entity dashboards.

Link
Robot Monitor Scenario Design
Alerts page in Maximo Asset Monitor providing a tabular view of all alerts from monitored asses in a system.

Creating Service Requests

Operators validate alerts and troubleshoot the root cause of the anomalous data by inspecting the short and long-term asset behavior using historical metric data using the time range picker on the dashboards. Once the anomaly is validated and the root cause is identified, operators will create a service request for maintenance supervisors to plan the work order for maintenance engineers to resolve the issue.

As shown on the screens above, a service request may be created including reference information of the asset id, job code, and links to the alert in Maximo Asset Monitor.

Link
Robot Monitor Scenario Design
Creating a new service request from an alert in Maximo Asset Monitor.

Get Hands-On with Maximo Asset Monitor Dashboards

Explore the steps to configure the dashboards for ACME robots in the Hands-on Lab Mastering Dashboards in Maximo Asset Monitor. In the lab, you will start by exploring more in detail the sources of robot data that you will monitor. You will then learn the steps of configuring an operational dashboard for monitoring the metrics, trends, and anomaly alerts from the ACME robots. You will use the monitor dashboard presentation techniques of value cards, graph cards, table cards, and image cards with hot spots. You will also explore summary dashboards that provide data aggregation and filtering to monitor your performance KPIs.

 


Mastering Dashboards in Maximo Asset Monitor

Hands on Lab for a practical introduction to the use of dashboards in IBM Maximo Asset Monitor.


Mastering Dashboards in Maximo Asset Monitor

Hands on Lab for a practical introduction to the use of dashboards in IBM Maximo Asset Monitor.

Carbon Design System – A Practical Example

,

Introduction

Want to get a modem, consistent and great looking sparking user experience and visual design? Why not take a look at the latest version 10 of the Carbon Design System with guidelines and resources from the IBM Design Language.

“Carbon is IBM’s open-source design system for products and experiences. With the IBM Design Language as its foundation, the system consists of working code, design tools and resources, human interface guidelines, and a vibrant community of contributors”

This article presents a practical example of some of the highlights in the Carbon Design System and brings a pragmatical approach to a modernization task. In this example, I use my rather simple portfolio website to apply Carbon-styling to an existing interface. I also demonstrate some of the basic elements of Carbon to help you get started.

First, we will overview some of the Carbon Design System basics like colors, icons, typography, and layouts. We will then look at some practical examples of applying the Carbon 10 resources to an existing visual design. The article also shares a new few links to references and reusable LESS/CSS and Sketch resources.

Great, let’s look at how Carbon can provide a foundation for a sparking carbonized design.

Carbon Design System and the IBM Design Language

As mentioned above, Carbon is an open-source design system built from the following guiding principles

  • Open for anyone to use and contribute
  • Inclusive of all, regardless of ability and situation
  • Modular and flexible in use
  • Putting the user first
  • Builds consistency by ensuring a consistent experience

The Carbon design system includes guidelines on the principles of the design, like color, themes, icons, typography, and layout. This article will discuss the application of these principles. Carbon also provides set rich set of key component building blocks designed and coded for a specific UI problem or purpose. The 30+ components and the principles are designed to seamlessly interact with the bigger consistency of the experience. The components are provided in the Carbon Design Kit, including Sketch libraries and React and Angular UI components. Additionally, Carbon also provides patterns as best practice experiences as combinations of components that address common user objectives with sequences and flows, like dialogs, notifications, filtering, and search. 

In this article, my focus will mainly be on the experience and visual aspects of applying Carbon.
To explore more on the Carbon Design Kit resources, visit www.carbondesignsystem.com.

Colors

The selection of colors creates uniqueness. Carbon provides balanced and harmonic color anatomy. Colors are provided as base color palettes, themes, and as tokens for a consistent user experience.

Let’s start with the color palettes. Carbon defines a natural gray and 7 color families; Green, Teal, Cyan, Blue, Purple, and Magenta. Each color family is given as 10 values, ranging from light to dark colors, for example, Blue-10, Blue-20, .. Blue-100. Additional single action colors values are provided in Red, Orange, Yellow, and Green. The Blue and Grey color palettes and the corresponding HEX color codes in LESS syntax for Blue are shown below.

Carbon Design System – A Practical Example 
@blue-100: #051243;
@blue-90: #051b75;
@blue-80: #0530ad;
@blue-70: #054ada;
@blue-60: #0062ff;
@blue-50: #418cff;
@blue-40: #6ea6ff;
@blue-30: #97c1ff;
@blue-20: #c9deff;
@blue-10: #edf4ff;

The visual design discussed in this article mainly uses gray and blue color values. The grey colors in the design come with the White theme that we will discuss later. The blue colors come from selected accent colors in the design.

Carbon Design System – A Practical Example
Portfolio home page with Carbon blue colors.

Themes and Tokens

Carbon uses tokens and themes to manage color to achieve a consistent experience and visual design. There are two light themes and two dark themes; White, Gray 10, Gray 90, and Gray 100. The design in this article is using the White theme.

To achieve a consistent experience, Carbon defines tokens as code identifiers for a unique role or set of roles in the design. Tokens are universal and identified by a name consistently used across the themes. For example, a page background is defined by the `@ui-background` value. In my White theme, this takes the value `#fffff`. In the dark Gray 100 theme, it would take the value `#171717`.

There are multiple other roles defined for the experience. For example primary, secondary, and tertiary buttons. Backgrounds for primary, low, and high contrast containers. Primary, secondary and tertiary texts, and texts for error messages and links and hovers. And the list goes on … Check the details on www.carbondesignsystem.com/guidelines/color/usage.

In applying the Carbon White theme I used a LESS stylesheet that defines the colors and tokens and sets the values for the White theme used in the design. A code snippet of the LESS definitions is exemplified below. The portfolio design example discussed in this article, mainly uses the ‘ui-background’, ‘text-01’, ‘link-01’, ‘ui-01’, ‘ui-03’ and ‘interactive-01’ tokens. 

// Core color tokens
@ui-background: @white; // Default page background.
@interactive-01: @blue-60; // Primary interactive color. Primary buttons
@interactive-02: @gray-80; // Secondary interactive color. Secondary button
@interactive-03: @blue-60; // Tertiary button.
@interactive-04: @blue-60; // Selected elements. Active elements. Accent icons.
@danger: @red-60; // Danger button background.
@ui-01: @gray-10; // Container background on @ui-background. Secondary page background.
@ui-02: @white; // Container background on @ui-01. ‘Light’ variant background.
@ui-03: @gray-20; // Subtle border. Tertiary background.
@ui-04: @gray-50; // Medium contrast border.
@ui-05: @gray-100; // High contrast border. Emphasis elements.

Layout and Spacing

Carbon defines a spacing scale as useful when laying out individual components. It includes a range of large to small increments to create the appropriate relationships for detail-level layout designs.

@spacing-01: 2px;
@spacing-02: 4px;
@spacing-03: 8px;
@spacing-04: 12px;
@spacing-05: 16px;
@spacing-06: 24px;
@spacing-07: 32px;
@spacing-08: 40px;
@spacing-09: 48px;
#portfolio-headline {
background: @ui-01;
color : @black;
margin-top: @spacing-05;
}

#portfolio-headline-name {
.expressive-heading-05();
margin-bottom : @spacing-05;
}

#portfolio-headline-quote {
.expressive-heading-03();
}

Here I find that using Sketch with the Carbon library to comes handy when creating and testing the carbonized design. The layout can be defined using spacing components that guide the implementation of margins and padding’s on the individual components on the page designs. The design below shows the layout in Sketch of the home portfolio page with inserted Carbon `@spacing-09`, `@spacing-07`, and `@spacing-05` spacings. The Sketch design guides the final coding of the styling using the LESS stylesheet declarations implementing the component spacings.

Typography

Carbon uses type tokens to define the typography. A type token is a pre-set style with typographic elements such as font size, weight, and line height. The typography is calibrated for use with the open-source IBM Plex typeface.

Download IBM Plex from the IBM Plex Github Repo. github.com/IBM/plex

IBM Plex is also available directly for use through Google fonts.

Carbon defines typographies for two situations. Productive typography for product and web designs. The Expressive typography for web, graphic, and print usage extends the Productive design with more dynamic typographic hierarchies and more variety with a fluid Heading scale. My carbonized design portfolio will use Productive design typography.

The Carbon design kit provides the type tokens in the Sketch library. The type tokens can be defined in LESS to simplify the style coring.

.body-long-01 { 
font-family: 'IBM Plex Sans', sans-serif;
font-size: 14px;
line-height: 20px;
font-weight: 400;
letter-spacing: 0.16px;
}

.body-long-02 { 
font-family: 'IBM Plex Sans', sans-serif;
font-size: 16px;
line-height: 24px;
font-weight: 400;
letter-spacing: 0px;
}

Responsive design

Carbon defines fluid types for headings using 5 breakpoints across screen widths. The LESS definition uses these breakpoints in the header type definitions to implement the fluid types.

@sm: ~"(min-width: 320px)";
@md: ~"(min-width: 672px)";
@lg: ~"(min-width: 1056px)";
@xlg: ~"(min-width: 1312px)";
@max: ~"(min-width: 1584px)";

.expressive-heading-03 {
font-family: 'IBM Plex Sans', sans-serif;
@media @sm {
font-size: 20px;
font-size: 18px;
line-height: 26px;
}
@media @md {
font-size: 20px;
line-height: 26px;
}
@media @lg {
font-size: 20px;
line-height: 26px;
}
@media @xlg {
font-size: 20px;
line-height: 26px;
} 
@media @max {
font-size: 20px;
line-height: 26px;
}
font-weight: 400;
letter-spacing: 0px;
}

Icons

Carbon provides a super-rich set of icons and pictograms for visual design consistency. Check out the icons at www.carbondesignsystem.com/guidelines/icons/library. Using icon library you can view and filter and then download the icons you need directly from the library.

Carbon Design System – A Practical Example

In the Carbon design example, I only use a few icons from the library for page browsing, downloads, and social media. The Up Right Arrow icon is used to indicate a navigation link to related articles. The Download icon for shared file-based material.

Putting it all together

We have now explored some of the fundamental visual elements of the Carbon Design System; Colors, Themes, Spacing, Typography, and Icons. Note that Carbon Design System provides many more advanced elements for web, product, and digital designs, like Components, Patterns, and Data Visualization. View it all on www.carbondesignsystem.com.

Let’s close this article with a few conclusions, examples, and references on how to get this all together into a carbonized design. I find that Sketch and the Sketch library available with Carbon provides a great help in expressing, specifying, and testing the design. Down to a pixel-perfect implementation. The Carbon library provides a direct selection of the design elements like colors and components directly in the Sketch tool. Using a LESS stylesheet, in combination with any existing CSS / LESS stylesheet from an earlier design is a great way to incrementally lay the carbon design over en existing implementation. Then drive additional style changes or redesigns from there. All in all, the experience becomes guided, practical and productive. And providing a consistent experience.

Carbon Design System – A Practical Example
Portfolio project page design using the Carbon library with theme tokens. Carbon layout and spacings are included in the visual design.

A few simple examples of designs of portfolio, project, article, and session pages are provided below. These designs use Sketch and combine the definition of LESS/CSS and Carbon theme style classes for each design element. It also defines the layout using the Carbon spacing sizes in units of 48, 32, and 16 px.

Carbon Design System – A Practical Example
Portfolio page design using the Carbon library, theme tokens and LESS styles.
Carbon Design System – A Practical Example
Projects page design using the Carbon library, theme tokens and LESS styles.
Carbon Design System – A Practical Example
Article page design using the Carbon library, theme tokens and LESS styles.

Carbon Design System at and across enterprise scale

Carbon is IBM’s official design system and serves a wide range of designers and developers building digital products and experiences. View examples of applying the Carbon Design System to enterprise-scale product, digital, and event designs at IBM on carbondesignsystem.com.

Carbon is the foundation and design language for product design of AI applications and the Internet of Things at IBM. The two examples below exemplify the use of the principles discussed above and the use of components and patterns from the Carbon Design System in IBM Maximo Asset Monitor product designs.

Carbon Design System – A Practical Example
Example design of a resource page using Data Table, Pagination, Buttons, Breadcrumb, Date Picker, Search, and the UI Shell components from Carbon 10.
Carbon Design System – A Practical Example
Example of a dashboard page design using Carbon data visualizations.

 

Visit my portfolio at design.gothe.se for additional exemplifies in the use of Carbon in our product design of AI applications and Internet of Things at IBM. And look luck in creating web and product designs using Carbon.

Mats Göthe, PhD
STSM, Senior Design Lead
Maximo Asset Monitor
AI Applications, IBM



Download Carbon 10 LESS stylesheet

 



Download Sketch file

 

Device Simulator with CSV Data

, , , ,

Design Objective

In 2019 I delivered a design to integrate the IoT platform Device Simulator with IoT platform Connection and Analytics Services.

The objective of this design is to improve the customization of simulated device data and by automation of Data Management configurations enabling data to be stored in the DB2 data lake by the Connection Service.

“A LOB engineer running a POC can use out-of-the-box simulated device data and in a minute with no other actions required start exploring simulated entities and apply analytics functions to the simulated entity data”

Design Requirements

  • The requirements on this design
  • Device simulator shall by default be Activated
  • The Device Simulator editor shall provide a setting to “Save device events to the data lake”
  • The Device Simulator shall automatically generate and activate a physical and logical interface for a simulated device if the “Save device events” property is selected
  • The Device Simulator editor shall optionally allow a CSV file to be uploaded containing a simulated time series of data.
  • The Device Simulator shall construct an event payload schema from CSV file column names and data types.
  • The Device Simulator shall, by rows in the CSV file, send data events with column values as event payload.
  • The Device Simulator editor shall run (as-is) in the client browser. Closing the browser will terminate simulation and ingest of simulated data
  • The Device Simulator shall support the export/import of the simulator configuration.
  • Limitation: A user shall not be allowed to edit the simulated device type and the event payload schema after the physical and logical interface has been defined.

Production Design

The final Device Simulator production design.

ChrisDevon

Meet Chris is the Application Developer and Devon is the Edge Device Developer. 

Chris and Devon are the most frequently used personas in the developer experience design across the platform capabilities.


Simulated Devices Design

The Device Simulator design in Watson IoT Platform enables developers to build and test the IoT applications without deploying physical devices beforehand.

Get Hands-on Next Generation IoT Platform

, , , ,

Abstract

Learn how to get started with Watson IoT Platform quickly and take advantage of the leading platform for industrial IoT. This lab will provide an overview and hands-on experience of Watson IoT Platform, including: Connection Service—to connect devices and start event data ingest; and Analytics Service—to gain insights from data using an extensible catalog of analytical functions.

Lab Introduction

This recording introduces the ‘Getting Hands-On with Watson IoT Platform’ hands-on lab. It introduces the operator persona, the scenario, the instrumentation of the Munich HQ with the sensors used in this lab.

Lab Material

Think2019-Lab4322-NextGenIoTP-Presentation

 

Think2019-Lab4322-NextGenIoTP-LabHandbook

 



Download lab presentation


Download lab handbook

Load More