Exploring Big Ideas
We generated Big Ideas in three areas
This emerged to a design around the big idea of a tourist arriving in Stockholm.
- A chatbot for tourists in Stockholm that helps with finding and sharing information
- Growing a personal network by meeting new people
- A structured network to connect people
We generated a Stakeholder Map from this Big Idea.
- Tourists – Arriving to Stockholm city as first-time visitors with an interest in experiencing the best activities and Swedish culture.
- Locals – Loves meeting new people and show them around the city. Want to learn and improve their language skills.
- Officials – Want invest and be efficient to provide the best information and experience for visitors
- Guides and Agents – Travel agents and street artists that want to know where crowds are
- Businesses and Developers – Build client solutions and businesses
We voted for building empathy for Texas a Tourist and Lisa a Local.
Empathy Map for Texas the Tourist
We generated an empathy map for Texas the tourist. The An Empathy map structures what Texas ‘Say’, ‘Feels’, ‘Thinks’ and ‘Does’. We found that…
Texas, the tourist, THINKS he needs to get to a hotel and connect to wifi, so he can get information on what to do this evening. He is quite a good tango dancer and wants to see suggestions based on this interest.
But as the moment he FEELS lost, lonely, hungry, stressed. But also energized to learn more about Stockholm.
He SAYS – “Where are the locals?” and asks “Can you show me…?” and “How do I get to…?”.
He has been walking for hours and finally gets to his hotel. He spends hours on Google trying to find information.
The workshop practiced on Playbacks.
A playbacks is a safe environment to share ideas. Playbacks ensure the progression of the delivery of the outcome.
Empathy Map for Lisa the Local
We generated an empathy map for Lisa the local. We found that…
Lisa thinks that she has so much to show. She is a willing to set a day aside for such activities. She thinks that she may get tips like 10 SEK for every tourist that she is helping out. But she is a bit nervous and wonders how to call for help in case of dangerous situations.
She feels she might be lacking sufficient language skills. She might be annoyed by tourists are not behaving.
She tries to connect with some tourists to join her for a football match or dinner at a new restaurant she just heard about.
She works as a shop assistant and put her name up on a contact list at work.
We ended the workshop by calling out the needs for Texas and Lisa.
Based on the needs statement, we find the following design opportunities
Location and routing
- How to best get into the Stockholm city area
- Where to meet up guides, and pick up tourists
- Identification, who is a guide and who is a tourist
Allocation and Scheduling
- Who to go with who
- Optimize groupings from pick up, route, and drop off
Trust, safety and pay
- Only pick up people with good references
- Emergency calling
- Pre-agreed price. Simple pre-pay methods
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.
During this three hours 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 fulfills their users’ actual needs. It is a human-centric methodology that focuses on creating innovative solutions with high user experiences.IBM%40Goto10-IBM%20Design%20Thinking%20hand-out
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 optimising the process to achieve a deliverable, and only required tasks should be included. Both these methods let the mechanisms of delivery takes 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 the 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 most every IBMer and every project in the labs and in the field. And its inspiring other innovative practices, like the IBM Cloud Garage method.
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.
- Multi-disciplined teams
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 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. Its a clear statement of intent on the outcome, the WHAT. And, its 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 help us stay aligned. A 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 outcome
- Playback Zero – Align teams on Concepts, UX, and plan.
- Delivery playback – On milestones
- User / Client – Playbacks for stakeholders
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.
The workshops include practical session where we explore stakeholder maps, empathy maps, and needs statements. We also practice on playbacks.
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.
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.
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.
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.
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.
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 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 hardens the UX design and delivers 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 executing in as plan 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 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 offering requirements on the new capability
- Design Thinking user research artefacts, 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 defining 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 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 GutHub 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 handing off to front-end and back-end development. The sprint teams are formed with UX and Visual designer(s), Frond-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 as 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.
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.
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.
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 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.
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.
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.
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.
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 our organization beyond product thinking.
I was a part of the IBM Rational Green Threads team from 2005 to 2012 and its merger into the IBM Rational Design Factory team.
Green Thread Goals
- Cross-product solution team moving our organisation beyond point product thinking
- Deliver solutions that really work to solve real-world customer problems
- Build virtual teams across subject matter experts, product teams and solution architects to define solution scenario
- Identify and prioritise key issues and roadblocks to product development
- Work with point product teams on ownership and prioritization
- Provide guidance and recommendations for field to use now
- Identifying progress measurements and indicators
- Workflow across a set of products to solve a complex customer problem
- End-to-end workflow a customer might follow to accomplish a particular goal or handle a specific situation/event
- Reflects real-world usage and scenarios
- Demonstrates an optimal workflow
- Document the “As Is” flow – Define a “To Be” flow
- Try to match green threads to Rational market strategy (solutions & segments)
- Multiple green threads, each with a different focus, for example Business-Driven Development, System in Trouble, Deployment, Software Development Governance, Solution Delivery and Management, Global Development and Delivery, Systems Development, SOA Deployment, Collaborative Application Lifecycle Management, Agility at Scale.
- Span relevant products from Rational, Tivoli, WebSphere, Lotus, DB2
- Continuously updated for new product releases
- Each GT reflects a specific usage scenario, not all possible scenarios
- Current threads started after products delivered. Over time, they will catch up and get ahead of product schedules (e.g., feed Drake concept)
Way of Working
The Green thread method follows a set of steps to define the as-is solution scenarios, the longer term vision and the improvements steps to get to that solution vision.
The individual steps are:
- Identify and Prioritise Scenarios – Goals and Scope
- Detail and Document Tasks – As-Is flow
- Walkthru / Execute Scenario
- Identify Issues and Product Requirements
- Provide tactical recommendations
- Guidance and artefacts for field engagements
- Long-term Vision – To-Be flow
- Incremental Product Improvements
- RFEs and defects to product teams
- Milestone Assessments
The Green thread method uses a standard overview of the solution scenario. The overview outlines the personas, the actions performed, the flow of events and the offerings or tools in the solution used for the actions. The solution improvements in the to-be vision is tracked by tool and by solution release. Examples of green thread outcomes below.
Example of GreenThread scenario summary.
Example of GreenThread As-Is assessment
Example of tracking incremental product improvements