IBM Design

November 24, 2022

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.

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.

February 24, 2020

Carbon Design System – A Practical Example

mats Design-Articles, IBM Design

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.

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.

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.

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.

Portfolio page design using the Carbon library, theme tokens and LESS styles.

Projects page design using the Carbon library, theme tokens and LESS styles.

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.

Example design of a resource page using Data Table, Pagination, Buttons, Breadcrumb, Date Picker, Search, and the UI Shell components from Carbon 10.

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

October 20, 2017

IBM Design Thinking Workshop – October 26th, 2017 at Goto10

mats Conferences, Design Portfolio, Design-Workshops, IBM Design Conferences, IbmDesign

Exploring Big Ideas

We generated a Big Idea idea about the design of what to do when public transportation is canceled and people are stuck in the center of Stockholm.

Stakeholder Maps

We generated a Stakeholder Map from the Big Idea.

Officials and Data providers

City officials, public departments, police, public transport companies, maintenance managers, and engineers working on broken infrastructure. They all have information to share about the situation, recommendations on what to do, and the plans when it will be fixed.

Alternative transporters

Drivers, Taxis, Pooling, Bike rentals, and kind people can help citizens to get from Stockholm city to their homes or other destinations.

Citizens

Going from a commonplace A to their destinations
Going from A to a common destination B

Businesses and Developers

Businesses that want to use this event to generate business and deliver services

We voted for building empathy for Bob running a Bike Rental and John a Police officer at the scene in Stockholm.

Empathy Maps

The workshop explored the empathy map for Bob. An empathy map structures what Bob ‘Say’, ‘Feels’, ‘Thinks’ and ‘Does’.Bob, owning a bike rental business, THINKS this is a great opportunity. “How much can I earn?.” He thinks about the situation and his capacity to deliver his service.

Empathy Map for Bob at the Bike Rental

“Do I have enough bikes, locks, helmets?”. “How should my customer pay?”.

But at the moment he FEELS happy and a bit stressed. He needs help to pull this off. And he feels good about helping people.

He SAYS – “I love SL and the business it brings me” and asks “Where should I keep my bikes to be ready?”.

He bumps up the price of rentals and calls in help from his friends using SMSs.

Empathy Map for John the Police

John THINKS, and fears, that crimes were committed and hopes that no one is hurt. He assesses where dangerous situations may occur. He needs to work overtime.

He FEELS stressed and disappointed. Oh, no, not again. He needs to stay focused and realize he just missed his ‘fika’-break 🙁

He SAYS – “How can I help” and “Keep CALM”. He instructs on routes to exit out of Stockholm city.

He gives directions and advice. He sizes the situation, reports on needs, and calls in for assistance. He provides assistance to people with special needs.

Needs Statements

We ended the workshop by calling out the needs of Bob and John.

Needs statements for Bob the Bike Rental.

Needs statements for John the Police.

Based on the needs statement, we find the following design opportunities

Transportation

Need directions on where to go – hotel, restaurant, or another meet-up place
Need options on transportation – car, bus, bike?
Need clarity on schedules – when leaving from where?
Need pricing information – do I have the money?

Finding contacts

Need to find a friend
Need to find a guide
Need to find a local

“Very useful and inspiring”

IBM Design Thinking: Deliver Breakthrough User-Centric Solutions
Learn more about the IBM Design Thinking workshop.

Download the workshop presentation

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

September 21, 2017

IBM Design Thinking: Deliver Breakthrough User-Centric Solutions

mats Design Portfolio, Design-Workshops, IBM Design, Workshops IbmDesign, Workshops

IBM Design Thinking Workshop

Are you building a business with user-centric solutions? How well do you know your users today? Are you really solving your users’ actual problems and creating the best possible value for them? With IBM Design Thinking you will view a business idea and solution from the users’ perspective. Only then can one ensure that the actual user pain points are targeted.

This practical workshop invites you who want to learn a powerful methodology that can be used to develop your business idea into a user-centric one.

goto10

During this three-hour workshop, you will learn about the IBM Design Thinking framework and get practical experience on how to use it. IBM Design Thinking includes a number of tools and practices that help companies deliver breakthrough solutions that fulfill their users’ actual needs. It is a human-centric methodology that focuses on creating innovative solutions with high user experiences.

Design in the intent behind an outcome

Before we begin, let’s make sure everyone understands what we mean when we say “design”. Design is the purpose, planning, and intent behind an action, fact, or material object. In other words: Design is the intent behind an outcome. Nothing more, nothing less.

The focus on a desirable outcome is not in conflict with agile practices. Agile practices sets focus on achieving a predictable and repeatable heartbeat of delivering the solution. The content of each delivery will be scoped to what can be contained with quality in each sprint. Lean takes a focus on optimizing the process to achieve a deliverable, and only required tasks should be included. Both these methods let the mechanisms of delivery take precedence over the content delivered. With design thinking, we complement the agile methods with the focus on the desirable outcome. Design Thinking hence adds the purpose and intent and ensures that the user is at the center of the outcome.

Good design is good business

Good design is good business. This statement by Thomas Watson is well known and often quoted. It captures the importance and uniqueness of design at IBM in the 50s. Today, good design and Design thinking is mainstream. Good design much table stake and mainstream. Design thinking is widespread. So, what is different in IBM’s version of Design Thinking?

Mission: Create a sustainable culture of Design at IBM

The IBM Design program started small in 2013 with a mission to hire 100 formally trained designers and kickstart 7 hallmark projects across IBM. Across different BUs, different products, and different project objectives.

We emphasize the parts that drive

differentiated delightful outcomes
business value and leading business strategy
the elements that delivered @scale and speed for distributes and complex teams

Today, we are now 4 years into the program with over 400 projects, 1,000’s of designers, and IBM’ers trained on Design Thinking across Development, Offering Management, Sales, and Services. Design is touching almost every IBMer and every project in the labs and in the field. And it inspires other innovative practices, like the IBM Cloud Garage Method.

IBM Studios

The Design Studios are the centers of the design culture. They are a key enabler for the way of working with multi-discipline teams and reaching out to our global organization. Studios are built out across the IBM labs. Design studios are open and movable. Workspaces change the shape as the purpose over time.

Solving complex problems requires us to work together across differences

The question remains “What is different with IBM Design Thinking”. With the size of 350k employees at IBM, with geographically distributed teams, offering management, design, development, sales, and services across the globe we need a design model that scales. Four key aspects of IBM Design Thinking enable that scaling.

Users
Hills
Playbacks
Multi-disciplined teams

Users

The users are our clients. Their success is our success. They are the judge of the value we bring. And it’s their experience we have is given the privilege to host. Our designs must be based on their needs or pain points. Our design must be driven from an empty with the users. They must be our North Star.

We ensure that we put users first by recruiting Sponsor Users of the design. We ground the intent to their needs.

Hills

Hills gets us aligned. Hills are captured by a WHO, a WHAT, and a WOW. A hill is a clear statement of the intended user, the WHO. It is a clear statement of intent on the outcome, the WHAT. And, it is a clear statement of the differentiator compared to competitors, the WOW.

The hill provides clarity and frames the problem – in simple words; aligns the understanding across team members. And reaches out and aligns stakeholders (executives, marketing, sales), clients, and ecosystems. But it does not prescribe an implementation.

Playbacks

Playbacks help us stay aligned. Playback is a safe environment to share work. They ensure the progression of the delivery to a successful outcome.

Playbacks can be run anytime and may take different shapes and purposes. For example,

Hills playback – Confirm that stakeholders agree with the outcome
Playback Zero – Align teams on Concepts, UX, and plan.
Delivery playback – On milestones
User / Client – Playbacks for stakeholders

The workshops include practical sessions where we explore stakeholder maps, empathy maps, and needs statements. We also practice on playbacks.

Multi-Disciplinary Teams

IBM Design is not an agency – taking and delivering an awesome design. And we are not alone in solving a problem. In a multi-disciplined team, design work shoulder-to-shoulder with offering management and development, throughout sprints, milestones, and releases. Empowered teams can rapidly, generate ideas, reject or commit to them, and collaborate.

“Today I had a very amazing opportunity to be a part of a workshop called “IBM Design Thinking: Deliver Breakthrough User-centric Solutions”: I learned so much in such a short time and met a lot of amazing people. But before that, I was hesitating to go because I didn’t know anyone there and the thought of being embarrassed cared me. If I had let my fears decide for me then I wouldn’t have had one of the best experiences in my UX career.”

“Well thought out and structured presentation and Workshop”

“Thank to all of you from IBM for a great workshop”

“Workshop experience and following discussion were very interesting. A lot of inspiration, thanks to the organizers”

“Very useful and inspiring”

March 27, 2017

Adopting IBM Design Thinking for Solution Development

mats Design Portfolio, IBM Design IbmDesign

IBM Design Methods

Adopting IBM Design Thinking for Solution Development

This blog share some of our latest experiences from the Product Line Engineering (PLE) delivery team in adopting these processes and the way we started applying IBM design thinking to our solution development supporting businesses that include embedded software development.

Last year, AmyS blogged on the progress defining our internal Continuous Delivery process. To follow up on those concepts, I would like to share some of our latest experiences from the Product Line Engineering (PLE) delivery team in adopting these processes and the way we started applying IBM design thinking to our solution development supporting businesses that include embedded software development.

Design is good business!

IBM recognizes that good design is good business. And there is a long tradition to back up that statement. Lately, IBM Design Thinking has gathered design practices to identify and ideate on the aspects that makes a solution desirable to its users; the Who, the What and the Wow! These aspects become the mission for release(s) and the business requirements for the solution. Amy identifies these as the business planning artifacts at the top of the planning taxonomy. We call these Release Hills.

Figure 1. Cross-Solution Planning Taxonomy.

The use of Hills to capture the WOW’s

For delivery of improved capabilities for product line engineering, the team has focused on three Hills to drive innovation, to drive our work, and to organize and track our activities. Our first Hill ‘Work in configurations with artifacts and links’ focuses on core capabilities introduced in our solution on configuration management, with streams and baselines of engineering artifacts. The second Hill ‘Create and use product definitions’ extends the value of the first Hill with more targeted support for advanced product line engineering practices and use-cases. Our third Hill ‘Track and report on configurations of engineering artifacts’ is orthogonal to the first two and adds complementary capabilities to the solution with dashboards, queries and reports. To refine our mission to a focused and executable level we have also defined sub-hills that narrow-in scope and prioritize sets of features.

Organizing our solution artifacts by Hills

At the next level in the planning taxonomy we use the Hills as our primary organizational item for solution artifacts. At this level we use Rational Team Concert work items to capture our Epics and Features. And we use Categories to represent the Hills. This makes the process of classifying new capabilities simple by just using the Filed Against field when assigning Epics and Features to a Hill. We refine Hills into Epics to represent our sub hills. Features then become children under their parent Epics to further refine the capabilities into work that we can execute on within a single release cycle.

Our solution features are to be delivered by the impacted products, e.g. Rational Team Concert, Rational Quality Manager, Rational Doors Next Generation and Rhapsody Design Manager product development teams. Any enhancements to products are planned using Plan Items and Stories in each impacted product backlog respectively. To manage relations between solution features and application plan items we use cross-project Tracks links. This linking provides transparency to commitment and plan of delivery. It also provides transparency to progress on work and in-context collaboration.

Figure 2. Artifacts used for solution and product planning.

Using scenarios and playbacks to explore and validating our design

Scenarios are a key concept in our design thinking. They ensure that we can deliver our features in a coherent, usable and desirable solution. Scenarios also support our activities on innovation, exploration and validation. Much like a movie script we let our personas act out in the scenes using scripted steps. Hence, each scenario Act is decomposed into Scenes where the scenario personas act through Steps interacting with the tools and collaborating in context of a configuration of engineering artifacts. As indicated in Figure 2 above, our scenarios are linked to the features used in each scene using an Implements relation. Using these links in figure 2 we can report on important delivery metrics. As a few examples, lately we have been using the Rational Engineering Lifecycle Manager (RELM) product and the Lifecycle Query Engine (LQE) to index our solution artifacts and provide traceability reports that outline the dependencies and coverage of Plan Items to Features, Epics, Scenes and Hills. This creates a great overview of the design artifacts. On our delivery dashboard we use the artifacts to present key design metrics like; ‘Scenarios with no features’, ‘Features with no scenarios’, ‘Features with no Tracks’.

For our PLE scenario we use a storyline on ‘Fixing a defect in a product variant’. This scenario is exploring in the first act how the scenario personas will initially ‘reproduce the defect’ using the engineering artifacts in the released baseline configuration. In the second act the team will ‘create a new delivery configuration’ with updated engineering artifacts resolving the defect. In the third act the team explores the opportunities for reusing the fix when ‘delivering and baselining a fix to the product line’. Our personas acting in the scenario are the Product Line Manager, the Project manager responsible for product line delivery, the Development lead responsible for platform component delivery, the Configuration lead, a Systems engineer, a Embedded SW Developer and a Tester. To show progress on the solution delivery we conduct frequent playbacks of the scenarios using initially low fidelity mockups and prototypes. Over time we converge to more stabile high fidelity wireframes and working code by milestone.

Exploring design options and usability

Lately we have been using playbacks to explore design options and usability aspects on how the scenario personas are interacting with the configuration management application when creating streams and baselines of configurations. Using a scenario and playback design approach helps us in clarifying implications to usability and consistency across the solution.

Download article

View article on IBM DeveloperWorks

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

January 25, 2017

Integrating Design Thinking and Agile Development

mats Design Portfolio, Design-Methods, IBM Design IbmDesign, Methods

Stages of Concept Design and Development

The Watson IoT Platform team is using an agile way of working to design, develop and deliver new capabilities for the IoT Platform service in Bluemix. Such new major capabilities are identified as market or customer need, specified as requirements using Rational Doors NG, and managed as a ranked backlog. The team is delivering the backlog using an agile 3-week sprint heartbeat.

The sprint objectives and the outcome is varying depending on the phase in the design – develop – deliver lifecycle for a new capability. The initial phase defines the concepts and scope of the design. Later phases harden the UX design and deliver front-end and back-end implementations of the design.

A key success factor is the teaming across the disciplines across offering management, design, and development. And the right-sizing and right-staffing of the sprint teams. The concern and issues addressed by this practice is to ensure that the teams are engaged, right-staffed, and committed to the delivery. It avoided a situation where design is executed in a planning vacuum with major trash and rework as the development teams get engaged.

Let’s start and explore the expectations, inputs, and outcomes of each sprint type and the team personas participating. The phases, roles, dependencies, and outcomes in figure 1 below are discussed.

Stages of Concept Design and Development.

Concept and Plan

The first stage is a Concept and Plan sprint focusing on the product definition. A sprint team is formed by the design lead(s), Architect(s,) and Offering Manager(s).

The concept and plan sprint requires strong offering management and design lead participation. To ground the concept in the existing solution architecture there is a requirement of lead architect participation. A core team is formed that is responsible for defining and delivering the concept and the delivery sprint plan. The playback of the outcome is a driver and a forcing function by schedule to get early agreement on the concept scope and objective. The core team stays as a governance body for the later phases to manage and approve changes to the concept and plan.

For this concept and plan stage the inputs are:

High-level market and product requirements on the new capability
Design Thinking user research artifacts, e.g. stakeholders, and stakeholder needs
Existing Hills where the new capability may be a new sub-hill

The outcome of this concept and plan stage is:

An approved set of requirements capturing the Minimal Viable Product, MVP.
Hills defines the user value through statements of Who, What, and WOW.
The Epics that will deliver the hills. The hill is complete when the epics are delivered.
The Stories that deliver the Epics. A story is delivered in one sprint.
An end-to-end high-level scenario that can be played back as a statement of the hills

UX and APIs

The second stage is focusing on exploring the User Experience and the APIs for the new capability. The objective is to harden the MVP by validating the concept in the context of the IoT Platform.

For this stage, a sprint team is formed with UX Designer(s) and Architect(s). UX playbacks are demonstrating the capability experience. Any updates and additions required to the solution architecture are identified. The stories in the plan and broken down into actionable tasks.

The outcome of this state is:

Validation that requirements can be met
Elaboration of the Stories and breakdown into actionable RTC work items or GitHub issues.
UX designs (LoFi) for the scenarios

UX, Front-End, and Back-End development

The following stages are focused on delivering one or more stories in each sprint. UX design is leading and handed off to front-end and back-end development. The sprint teams are formed with UX and Visual designer(s), Front-End and Back-End developer(s).

The outcome of this sprint is:

Completed work items or issues
Completed UX designs (HiFi)
Playbacks of UX designs or running code

Summary and Conclusions

The Watson IoT Platform team is using an agile way of working to design, develop and deliver new capabilities for the IoT Platform service in Bluemix. The benefits are:

Embedding design thinking practices into the agile development process
Cross-discipline teaming
Right-timing, Right-sizing, and Right-staffing the agile sprint teams
Early delivery and hardening of design concepts

The workflow has been successfully established and used for the design of new Watson IoT Platform capabilities, like design and delivery of Risk and Security Management and Information Management.

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

January 25, 2017

Applying IBM Design Thinking

mats Design Portfolio, Design-Methods, IBM Design IbmDesign, Methods

Workshops

Working with a group of users is an effective way to make progress on conceptual and detailed design. Such workshops run from 2h to 6h using the Stakeholder Map, Empathy Map, Prioritisation, and Experience Map tools. Workshops quickly bring together teams and team members in a creative environment.

Design Studios

At IBM conferences like Innovate, Interconnect, and Insight we often get the opportunity to run design labs. These labs can support the design lifecycle we use both at early phases of Understanding, as well as later phases where we Prototype or Evaluate. The example below is from the three design studio labs in 2014 where we researched the PLE solution.

View the material from Designing User Experience Concepts in the Multi-Stream Configuration Management lab at Interconnect 2015.

1-1 Interviews

Sitting down with a client in a 1-1 interview will generate essential research information. Shadowing a user is another way to observe the as-is workflows and pain points.

I favor a style of dialog using a whiteboard to capture workflows and artifacts. This benefits my graphical way of thinking and engages the client. The sketches can easily be an overview where pain points can be identified. What works really well (tagged green), and what does not work that well (tagged orange/red).

Stakeholder Maps

Stakeholder maps are a great way to get started with a new group of clients, or a client team. It makes attendees start standing, ideating, talking, and telling. It generates a holistic view of the solution space and its stakeholders. It provides a mechanism to discuss and establish priorities and scope.

Empathy Maps

I use Empathy maps to capture the details of Stakeholders and transform them into Personas. An Empathy map is a great tool to capture how clients interact with a solution and their expectations as it captures what a persona Says, Thinks, Feels, and Does.

Personas

Empathy maps become the source for persona definitions. I often come across stakeholder that becomes variants of our more general personas. In such cases, I document this using “Also know as…”. It’s an act of balance in capturing important differences in personas and keeping a generalized level to make personas applicable across the solution and across industries.

Personas documented in the Requirement Management solution.

Sometimes we want to generate a bit of external nterest for personas. This is a cool set of trading cards we created for the Innovate conference using the Product Line Engineering (PLE) personas. These giveaways generate interest and conversations.

Experience Maps

Experience maps are a tool to outline a scenario. It captures the major and minor steps as the personas interact with the solution to achieve an objective. The example below is an experience map from PLE design on the steps to create a global configuration baseline. The experience map was created by the InnerCircle members across multiple industries at the IBM Innovate conference.

Example of Experience Maps for an Operator persona managing maintenance of assets in the Natural Resource industry.

Learn more about IBM Design and IBM Design Thinking on ibm.com/design