IBM Design Portfolio – Design Methods

IBM Design Thinking

IBM Design Thinking is an approach to applying design thinking for modern enterprise design. The framework drives teaming and action. It helps to form intent and deliver outcomes that improve the experience of the users. I use the techniques and tools of IBM Design Thinking in my daily work. Learn more about IBM Design Thinking at ibm.com/design/thinking.

Green Threads

Green Threads was an early precursor to many of the outside-in design principles we see in IBM today. It captured user design scenarios across a set of products that solve a customer problem. It moved out organization beyond product thinking. Some of the material and tools mentioned below was also using with the Green Threads projects.

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 brings 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 on the PLE solution.

View the material from Designing User Experience Concepts in 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 white-board 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 do not work that well (tagged orange/red).

Stakeholder Maps

Stakeholder maps is 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 captures what a persona Says, Thinks, Feels and Does. Empathy map is a great tool to capture how clients interact with a solution and their expectations. A few examples of Empathy maps below.

Personas

Empathy maps becomes 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…”. Its an act of balance in capturing important differences in personas and keep a generalise level to make personas applicable across the solution and across industries.

Sometime we want to generate a bit of interest for personas. This is a cool set of trading cards we created for the Innovate conference using the Product Line Engineering (PLE) personas. These give-aways generate interest and conversations.

I document the personas in detail in our solution requirements tool.

View the material on Validation of PLE roles and personas and user experience maps at Innovate 2014.

Experience Maps

Experience maps is 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 Map for an Operator persona managing maintenance of assets in the Natural Resource industry.

Scenarios

A scenario is a key artefact in our design. It ties together the personas and their objectives with their workflows and pain-points. It forms the basis we derive solution requirements, like release hills. And the way we validate our design using playbacks.
End
The is a great variability in how I have used scenarios across Green Threads, CLM, PLE and IoT projects. A few examples below. All using a visual representation of the scenario flow as Acts and Scenes.

Scenarios always benefit from a context, or a story. It builds on the personas and provides an organisational context to the individuals. For example, in the scenario for Global Development and Delivery (GDD) we tell the story off a global organisation sourcing work to near-shore and off-shore teams.

On the Story below I describe the personas, their objectives and hint on their geographical distribution.

Then, on the Solution I discuss more about their responsibilities and activities. And I indicate the application artefacts and tools each of the personas are interacting with. The relation between the personas and the artefacts are key in the Application Lifecycle Management (ALM) scenarios. Note that colours also gives hints on their geographical distribution and artefact ownership.

I find it valuable to have a single page outlining the overview of the scenario. It becomes a great image to present the high level objective and flow of a scenario and its personas. Two examples below from initial GDD scenarios. And later scenarios for ALM.

I use scenarios to report on solution gaps and user pain-points as we declare state our as-is and to-be products. Two examples below from capturing tool gaps and user pain-points.

A final example from the design of First day productivity for the Systems and Software Engineering solution. The scenario outlines the discover-try-buy scenario, the personas, and their interactions in exploring and adopting the solution in a project.

Low-Res Sketches and High-Res Mockups

The scenarios is decomposed into individual steps that forms the user experience using the tools. This UX design is made using low res to high res mockups. In the examples below we see a low res initial mockup of the configuration management menu in the PLE solution and comparing to the final menu after assessing usability design options.

Playbacks

Playbacks is a key tool for validating all design artefacts in the context of a scenario. Early playbacks focus validating the personas, objective and outcome. Later playbacks transition from early design proposals or demos using running code. All using a consistent scenario. I find it valuable to overview the scenarios graphically at a high level with the scenario acts. Drill into each act individually and outline the scenes. And finally steps through each step using mockups, screen shots, or running code. Examples below on Scene outlines and a step mockup with design comments.

View playback material from PLE design validation and playback at Innovate 2014