COURSE DESCRIPTION

Agile methods emphasize flexibility and adaptability, and the Agile

framework lends itself well to projects where requirements and
solutions evolve with time. Scrum, with its inherent simplicity and
lightweight processes, is the most popular way of introducing Agility to
a project. 
 COURSE OUTCOME
COURSE OUTCOMES
 On completion of this course, the students shall be able to

CO1 Explain how IBM Design Thinking works and using

loop Model to understand present and envision
future 
COURSE OBJECTIVE
Describe the importance of Design Thinking and Use of IBM Design
Thinking Framework.

Understand concept of History of Design Thinking

 DESIGN THINKING HISTORY
 
Design thinking is created not only because Tim Brown coined
the word that became a buzzword. There’s a logical reason to
it.
Design thinking is created because big corporation lack the
ability to be creative and on extreme cases, aren’t able to
create new products and services that meet unmet needs of
their customers. Because of 20th century education system
that fostered dominant logic and disregard creativity, people
grew up with an overpowered mindset and skill-set of
managing value. 
Defin
e
• synthesise your observations about your users from the Empathize stage
• definition of a meaningful and actionable problem statement, which the design thinker will
focus on solving
• A great definition of your problem statement => kick start the ideation process (third stage)
in the right direction.
• unpack your empathy findings into needs and insights and scope a meaningful challenge
• Define your Point of View – meaningful and actionable problem statement
• Preserves emotion and the individual you’re designing for.
• Includes strong language.
• Uses sensical wording.
• Includes a strong insight.
• Generates lots of possibilities
Define tools
• Point of view
• How Might We
• Why-How Ladder
• Powers of Ten
Define - Point of View
• You articulate a POV by combining these three elements – user, need,
and insight.
• insert your information about your user, the needs and your insights
in the following sentence:
• [User . . . (descriptive)] needs [need . . . (verb)] because [insight. . .
(compelling)]
Define - How might we?
• Short questions that launch brainstorms
• Seeds for ideation
• Come out form the point of view statement
• Example:
• Challenge: Redesign the ground experience at the local international airport
• POV: Harried mother of three, rushing through the airport only to wait hours
at the gate, needs to entertain her playful children because “annoying little
brats” only irritate already frustrated fellow passengers.
• (https://dschool-
old.stanford.edu/sandbox/groups/dstudio/wiki/2fced/attachments/f6
3e8/How-Might-We-Questions-Method.pdf)
Define - How might we
• Amp up the good: HMW use the kids’ energy to entertain fellow passenger?
• Remove the bad: HMW separate the kids from fellow passengers?
• Explore the opposite: HMW make the wait the most exciting part of the trip?
• Question an assumption: HMW entirely remove the wait time at the airport?
• Go after adjectives: HMW we make the rush refreshing instead of harrying?
• ID unexpected resources: HMW leverage free time of fellow passengers to share
the load?
• Create an analogy from need or context: HMW make the airport like a spa? Like
a playground?
• Play against the challenge: HMW make the airport a place that kids want to go?
• Change a status quo: HMW make playful, loud kids less annoying?
• Break POV into pieces: HMW entertain kids? HMW slow a mom down? HMW
mollify delayed passengers?
Define - Why How
Ladder
• Used to find user needs and ways to possibly solve them
• Step 1: Identify a few meaningful user needs and write them at the bottom of a
piece of paper.
• Step 2 Ladder up from that need, asking “why?”
• For example, why would a user “need to see a link between a product and the
process that creates it?” because the user, “needs confidence that it won’t
harm their health by understanding its origin.”
• Step 3 Ask why again, and continue to ladder from that same need.
• At a certain point, you’ll reach a very common, abstract need such as, “the need
to be healthy.” This is the top of the ladder.
• Step 4 Climb back down the ladder asking “how?”
• This will give you ideas for how to address the needs
Ideat
e
• generate radical design alternatives
• The goal of ideation is to explore a wide solution space
• both a large quantity and broad diversity of ideas.
• From this pool of ideas you can build prototypes to test with users
How to ideate
• Ideate=transition from identifying problems to exploring solutions
• Ideation is leveraged to:
• Harness the collective perspectives and strengths of your team.
• Step beyond obvious solutions and drive innovation.
• Uncover unexpected areas of exploration.
• Create fluency (volume) and flexibility (variety) in your innovation options.
• Fluctuate between focus and flare
Tools to ideate
• Brainstorm • Analogies
• Braindump • Provocation
• Brainwrite • Movement
• Brainwalk • Bodystorm
• Challenge Assumptions • Gamestorming
• SCAMPER • Cheatstorm
• Mindmap • Crowdstorm
• Sketch or Sketchstorm • Co-Creation Workshops
• Storyboard • Power of Ten
• Prototype
• Creative Pause
Ideate -
Brainwrite
• the participants write down their ideas on paper
• they pass on their own piece of paper to another participant
• The other participant elaborates on the first person’s ideas and so
forth.
• Another few minutes later, the individual participants will again pass
their papers on to someone else and so the process continues.
• The process takes 15 minutes
• Ideas are discussed afterwords
Ideate – Challenge Assumptions
• Identify the assumptions you have about the product you’re building
• (especially if you’re stuck)
• Challenge these assumptions
• Are they fixed because they are crucial aspects or because we have been
accustomed to them?
• Very important step if the empathy stage wasn’t well done and there
were
many things assumed about the users and their context
Ideate -
Mindmap
• Process through which the participants build a web of relationships
• Participants write a problem statement
• They write solutins
• Link statements and solutions between them
Ideate – Creative pause
• (I’d really hope to manage to sync this slide with the course break)
Define/Ideate – Power of Ten
• Consider challenges through frames of various magnitudes
• Consider increasing and decreasing magnitudes of context to reveal
connections and insights.
• Powers of ten for insight development – imagine what happens for
example when shopping for bubble gum vs. shopping for a TV vs.
shopping for a house
• How does this changes the user behaviour?
• Powers of ten for ideation
• Add constraints that alter the magnitude of the solution space (cost of 1 mil $
vs. 1 cent)
Prototype
• A prototype can be anything that takes a physical form—a wall of
post-its, a role-playing activity, an object.
• In early stages, keep prototypes inexpensive and low resolution to
learn quickly and explore possibilities.
• Prototypes are most successful when people (the design team, users,
and others) can experience and interact with them.
• great way to start a conversation.
• interactions with prototypes drives deeper empathy and shapes
successful solution
Low fidelity
prototyping
• use basic models or examples
• Just some features
• Methods
• Storyboarding.
• Sketching
• Card sorting.
• 'Wizard of Oz'.
Low fidelity prototyping
• Pros • Cons
• Quick and inexpensive. • lack of realism. basic and sometimes
sketchy nature =>the applicability of
• Possible to make instant changes and results may lack validity.
• test new iterations. • Depending on your product, the
• Disposable/throw-away. production of low-fi prototypes may
not be appropriate for your intended
• Enables the designer to gain an users.
overall view of the product using
minimal time and effort, • Such prototypes often remove control
from the user, as they generally have
• No advanced technical skills to interact in basic ways or simply
required inform an evaluator, demonstrate or
• Encourages and fosters design write a blow-by-blow account of how
thinking. they would use the finished product.
High fidelity
prototyping
• look and operate closer to the finished product
• For example, a 3D plastic model with movable parts (allowing users to
manipulate and interact with a device in the same manner as the final
design) is high-fi in comparison to, say, a wooden block.
• Likewise, an early version of a software system developed using a
design program such as Sketch or Adobe Illustrator is high-fi in
comparison to a paper prototype.
High fidelity prototyping
• Pros
• Cons • Engaging: the stakeholders can instantly
• They generally take much longer see their vision realised and will be
to produce than low-fi able to judge how well it meets their
prototypes. expectations, wants and needs.
• When testing prototypes, test users are • User testing involving high-fi prototypes
more inclined to focus and comment will allow the evaluators to gather
on superficial characteristics, as information with a high level of validity
opposed to the content and applicability. The closer the
• After devoting hours and hours of prototype is to the finished product, the
time producing an accurate model of more confidence the design team will
how a product will appear and have in how people will respond to,
behave, designers are often loathed interact with and perceive the design.
to make changes.
• Software prototypes may give test users
a false impression of how good the
finished article may be.
• Making changes to prototypes can take
a long time
T est
• chance to gather feedback, refine solutions, and continue to learn
about your users.
• The test mode is an iterative mode in which you place low-resolution
prototypes in the appropriate context of your user’s life.
• Prototype as if you know you’re right, but test as if you know you’re
wrong
Prototype/Test – Wizard of Oz Prototyping
• A wizard of Oz prototype fakes functionality that you want to test
with users, saving you the time and money of actually creating it.
• prototypes of digital systems, in which the user thinks the response is
computer-driven, when in fact it’s human-controlled.
• Determine what you want to test.
• Then figure out how to fake that functionality and still give users an
authentic experience
Prototype/Test – Card sorting
• how concepts for a project should be organized
• help the user experience professional know how to best organize a
website or software application so that the structure of information
will be logical for the largest number of users.
• Open card sorting = asking the users to come up with category names
for each card
• Closed card sorting = predefined names for each category
• a participant is given a number of cards or sticky notes, each
containing a different word. The test participant is then asked to
organize these as he sees best
Testing with users
• Allows you to learn about the solution you created but also about the users
(builds empathy)
• Let your user experience the prototype.
• Show don’t tell. Put your prototype in the user’s hands (or your user in the
prototype) and give only the basic context they need to understand what to
do.
• Have them talk through their experience.
• Use prompts. “Tell me what you’re thinking as you do this.”
• Actively observe.
• Don’t immediately “correct” your user.
• Watch how they use (and misuse) your prototype.
• Follow up with questions.
• This is often the most valuable part.
Test – Feedback capture matrix
• real-time capture of feedback on presentations and prototypes
• arranges thoughts and ideas into four categories for easy assessment
• Fill in the matrix as you give or receive feedback.
• 1st quadrant: Constructive criticism
• 2nd quadrant: Place things one likes or finds notable
• 3rd quadrant: Questions raised
• 4th quadrant: new ideas spurred
IBM Design Thinking Framework

We think the systems of the world should work in service of people. At

the heart of our human-centered mission is Enterprise Design Thinking: a
framework to solve our users’ problems at the speed and scale of the
modern enterprise.
 References
[1]Turk, Daniel, and Robert France. "Assumptions Underlying Agile Software Development Processes." Journal of  Software and Systems Modeling 17 (2003): 19-25. Print.
 
[2]Heeager, Lise Tordrup . "INTRODUCING AGILE PRACTICES IN A DOCUMENTATION-DRIVEN SOFTWARE DEVELOPMENT PRACTICE: A CASE STUDY." Journal of Information Technology Case and Application
Research 14.1 (2012): 3-24. Print.

[3]Abdelshafi, Ibrahim. "Primavera Gets Agile: A Successful Transition to Agile Develo." IEEE Software 22.3 (2005): 36-42. Print.
https://youtu.be/WjwEh15M5Rw