dtps 1

Download as pdf or txt
Download as pdf or txt
You are on page 1of 57

Module 1: Design Thinking Introduction, Team Formation, Documentation and Canvas

What is Design Thinking?

• Design Thinking believes that the people who face problems are the ones who hold the key to their
problem’s answer.

• Design thinking is both an ideology and a process, concerned with solving complex problems in a highly
user-centric way.

• Design thinking is an approach used for practical and creative problem-solving.

• It is based heavily on the methods and processes that designers use but it has evolved from a range of
different fields — including architecture, engineering and business.

• Design thinking can also be applied to any field; it doesn’t necessarily have to be design-specific.

Page 2
What is Design Thinking?

• Design thinking is extremely user-centric.

• It focuses on humans first and foremost, looking for to understand people’s needs and come up with
effective solutions to meet those needs.

• It is what we call a solution-based approach to problem-solving.

• Design Thinking is Human-centered problem-solving tool which emphasize on Empathy,


Collaboration, Co-creation and Stakeholder feedback to unlock Creativity and Innovation, which
devises possible and viable Big Idea/solutions.

Page 3
KEY PRINCIPLES AND MINDSET
Design Thinking human-centered problem-solving approach is based on a few easy-to-understand principles:

Page 4
Mindsets, Skills and Thinking

Page 5
Design Thinking Process elements
Stanford University’s Institute of Design has split the design thinking process into the following elements:

Page 6
Phases of Design Thinking

• # 01. Empathize: Understand Your Audience

• # 02. Define: Establish a Point of View

• # 03. Ideate: Focus on Possible Solutions

• # 04. Prototype: Try Out Multiple Solutions

• # 05. Test: Find the Best Solution for Your Audience

Page 7
Phases of
Design
Thinking

Page 8
Phases of Design
Thinking
• Popularized by Tim Brown
and David Kelley of IDEO
and Stanford’s d School

• Structured creative
problem-solving process,
enables innovation and
positive impact

Page 9
1. Empathise

• The first stage of the Design Thinking process is to gain an empathic understanding of the problem you
are trying to solve.

• This involves consulting experts to find out more about the area of concern through observing, engaging
and empathizing with people to understand their experiences and motivations.

• Depending on time constraints, a substantial amount of information is gathered at this stage to use
during the next stage and to develop the best possible understanding of the users, their needs, and the
problems that underlie the development of that particular product.

Page 10
2. Define (Problem statement)
• During the Define stage, you put together the information you have created and gathered during the
Empathise stage.

• This is where you will analyse your observations and synthesize them in order to define the core problems
that you and your team have identified up to this point.

• Define a problem statement as in a human centered manner.

• The Define stage will help the designers in your team gather great ideas to establish features, functions,
and any other elements that will allow them to solve the problems or allow users to resolve issues
themselves with the minimum of difficulty.

• In the Define stage you will start to progress to the third stage, Ideate, by asking questions which can help
you look for ideas for solutions.

Page 11
2. Define (Problem statement)
• During the Define stage, you put together the information you have created and gathered during the
Empathize stage.

• This is where you will analyze your observations and synthesize them in order to define the core problems
that you and your team have identified up to this point.

• Define a problem statement as in a human centered manner.

• The Define stage will help the designers in your team gather great ideas to establish features, functions,
and any other elements that will allow them to solve the problems or allow users to resolve issues
themselves with the minimum of difficulty.

• In the Define stage you will start to progress to the third stage, Ideate, by asking questions which can help
you look for ideas for solutions.

Page 12
3. Ideate

• During the third stage of the Design Thinking process, designers are ready to start generating ideas.

• You’ve grown to understand your users and their needs in the Empathize stage, and you’ve analyzed and
combined your observations in the Define stage and ended up with a human-centered problem
statement.

• With this solid background, you and your team members can start to "think outside the box" to identify
new solutions to the problem statement you’ve created.

Page 13
4. Prototype

• The design team will now produce a number of inexpensive, scaled down versions of the product.

• Prototypes may be shared and tested within the team itself, in other departments, or on a small
group of people outside the design team.

• This is an experimental phase, and the aim is to identify the best possible solution for each of the
problems identified during the first three stages.

• The solutions are implemented within the prototypes, and, one by one, they are investigated and
either accepted, improved and re-examined, or rejected on the basis of the users’ experiences.

Page 14
5. Test

• Designers or evaluators carefully test the complete product using the best solutions identified during the
prototyping phase.

• This is the final stage of the 5 stage-model, but in an iterative process, the results generated during the
testing phase are often used to redefine one or more problems and inform the understanding of the users,
the conditions of use, how people think, behave, and feel, and to empathise.

• Even during this phase, alterations and modifications are made in order to rule out problem solutions and
derive as deep an understanding of the product and its users as possible.

Page 15
What’s the difference between Solution-Based and Problem-Based
Thinking?
As the name suggests, solution-based thinking focuses on finding solutions; coming up with something
constructive to effectively tackle a certain problem. This is the opposite of problem-based thinking, which tends
to fixate on obstacles and limitations.

Every person approaches a problem in a different way. Some focus on the problem or the reason why a problem
emerged (problem focused thinking). Others prefer to think about possible solutions that help them to solve a
problem (solution focused thinking). Problem Oriented Thinking: Approaching a difficult situation
problem-oriented might be helpful if we attempt to avoid similar problems or mistakes in the future, but when it
comes to solving the problem we simply waste large amounts of our precious time! Problem-focused thinking does
not help us at all to solve difficult situations, which is especially necessary in times where one must find quick
solutions to an upcoming problem. Furthermore, the problem focused approach can have negative effects on one’s
motivation.

A good example of these two approaches in action is an empirical study carried out by Bryan Lawson, a Professor
of Architecture at the University of Sheffield. Lawson wanted to investigate how a group of designers and a group
of scientists would approach a particular problem. He set each group the task of creating one-layer structures
from a set of colored blocks. The perimeter of the structure had to use either as many red bricks or as many blue
bricks as possible (we can think of this is as the solution, the desired outcome), but there were unspecified rules
regarding the placement and relationship of some of the blocks (the problem or limitation). Page 16
Traditional Problem Solving

• Traditional thinking refers to the thinking that has traditionally permeated the mindsets, models,
decisions, and analyses of Western management. Its basis is in analysis and analytical
thinking. “Traditional” problem-solving often takes a methodical, almost scientific form. Pinpoint a
problem, define the steps to take and tools to use to reach a solution, then stick to the plan and hope for
the desired result. The traditional approach is also focused on solutions and aims to get the perfect
outcome on the very first try.
• Traditional problem solving is a linear and structured way of solving a problem. It relies on a set of data at
the beginning of a process, converges onto one solution using viability and feasibility, and creates a plan
of action to fulfil the solution.
• Traditional problem solving is a more linear and structured approach to describing and resolving an issue.
• It takes a set of data and works on that same data to come up with a solution.
• It’s straightforward, but not always flexible, innovative or effective.

Page 17
Traditional Problem-Solving approach

Page 18
Design Thinking

• Good design is really about solving problems.

• Design Thinking is a problem-solving framework.

• Design thinking is a human-centered approach to innovation that draws from the designer’s

toolkit to integrate the needs of people, the possibilities of technology, and the requirements

for business success.

Page 19
Traditional Problem-Solving V/s Design Thinking

• Instead of starting with a problem, design thinking starts with observation.


• Traditional thinking assumes we understand the user while design thinking goes out there
and interacts or lives the life of the user.

Traditional Thinking Design Thinking


Designer centered Client/user centered
Talk about problems Test solutions
Existing ideas/best practices Innovate ideas

Avoid failure Fail fast


Give the right answer Ask the right questions
telling Showing
Subject expert Process expert
Passive experience Active experience

Page 20
Traditional
Problem-Solving
V/s
Design Thinking

Page 21
User Centered
Design
• It’s important to note that
design thinking is different
from user-centered design.
• User-centered design is an
approach to design that puts
users’ needs front and center
and follows an iterative design
process that focuses on the
user’s needs every step of the
way.
• This means the design process
is being influenced and guided
by the user’s behaviors,
values, and expectations from
beginning to end.
Page 22
Differences between user-centered design and design thinking?

• User-centered design and design thinking both helps in finding solutions to people’s problems, you may
be wondering what the big differences between these two design methods. While the steps and general
mindset of each are quite similar, the most notable difference is their primary focus.

• User-centered design focuses on fostering deep empathy, with the population you are designing for. The
goal is to create solutions with users’ needs and feedback at the forefront of all design decisions.

• User-centered design is a great approach when you want to design a highly desirable product for a
specific audience. In the UCD process, the user is the focus from first ideation to development and
release.

Page 23
Differences between user-centered design and design thinking?

• While design thinking also requires great knowledge of the user, it also takes technological feasibility and
business goals into consideration. This is a method that can be applied to more than just product
development.

• Design thinking utilizes abductive reasoning to identify and solve complex problems that may affect
product design or organizational policies, processes, and function.

Page 24
Differences between user-centered design and design thinking?

Page 25
What do user-centered design and design thinking have in common?
While the primary focus of these two approaches are indeed different, user-centered design and design
thinking share many similar principles and concepts.

Empathy

The ability to feel for your users and understand their behaviors as well as the challenges they face is a
crucial part of any design process. So, whether you are using UCD to create a stellar mobile app or design
thinking to revamp employee training, you’ll need to have great awareness of the population you are
designing for and what their needs are.

Problem-solving

Both UCD and DT view problems as opportunities for improvement. Each method takes an optimistic
approach to problem-solving and uses structure, action, and design to take the issue at hand and turn it into
a positive experience for both the company and their users.
Page 26
What do user-centered design and design thinking have in common?

Iteration

The process for both UCD and DT is a cyclical one that relies on learning from mistakes and incorporating
user feedback into future designs.

At the end of each cycle, designers assess what went well, what needs work, and how to use past failure to
generate new and improved solutions.

Collaboration

Each design method works best when a team of people across organizational work together. Both
approaches are optimized when designers, high level executives, developers, accountants, customer-facing
employees etc., all work together towards a common goal.

Page 27
Best tools for each Design Thinking stage

• Empathize: Typeform, Zoom,

• Define: Smaply, Userforge, MakeMyPersona.

• Ideate: SessionLab,, IdeaFlip.

• Prototype: Boords, POP.

• Test: UserTesting, HotJar, PingPong.

• For the complete process: InVision, Mural, Miro.

Page 28
Relevance of design thinking in engineering

• Design Thinking is extremely useful in tackling problems that are ill-defined or unknown, by re-framing
the problem in human-centric ways, creating many ideas in brainstorming sessions, and adopting a
hands-on approach in prototyping and testing.
• Engineers use design thinking in a solutions-focused, human-centered way to creatively problem solve
and innovate throughout the engineering design process. Design thinking is a way of looking at and
tackling real world problems that we experience in our everyday lives, and greatly need solutions
for— especially the world’s “wicked problems” that are not well defined or have clear answers , such
as climate change.
• Design thinking is a fluid way of reasoning to purposefully devise solutions for difficult problems rather
than a series of trial-and-error steps. Design thinking is also a valuable life skill—like reading and
numeracy—that can be learned and perfected with practice and applies to a wide range of careers.

Page 29
Relevance of design thinking in engineering

• If you work in tech long enough, one day you’ll find yourself having a chat with clients and they’ll share a few
war stories about working on products that, despite brilliant engineering, were commercial disasters.
• They’ll tell you these elephant-in-the-room products were unpredictable. They’ll explain that their job is
building stuff, shifting boxes is someone else’s department. But is it? When products fail it might be nothing
to do with the physical engineering of the product, but it’s a mistake to assume it must therefore be a
marketing failure. Product fails often reflect shortcomings in the design philosophy of the engineers that
built them.
• Where engineering aims for perfection, design values imperfection.
• The classic engineering mindset is expressed by the Japanese word ‘kaizen’, meaning (roughly translated)
“continuous improvement’. This was the design philosophy that reconstructed post-war Japanese
engineering giants like Toyota, Honda and Nissan. The premise is sound: Continually monitor and improve
every process from the shop floor to the CEO’s desk. In product design, kaizen drove the trend towards
making things smaller, more efficient and more reliable. But kaizen is an after-the-fact process. It produces
better products for the next customer, not the one you just lost because the product wasn’t up to scratch. In
a world where consumers churn through brands in a highly competitive digital marketplace, kaizen doesn’t
Page 30
When engineers adopt design thinking, the impact is huge.
Consider engineering pioneers like Henry Ford and Steve Jobs, both of whom brought a collaborative design
philosophy to the engineering party. It’s important to note that neither of them were fans of focus groups, but
that’s not what collaborative design is, that’s what Hollywood movie producers do when they wreck a director’s
original cut of a film by showing it to a test audience and change the edit based on the response. Collaborative
design is human centric, not designed by the customer. It’s a subtle difference, but a crucial one.

It is also important not to laud these engineers as collaborative design evangelists, because they weren’t.
However, they both recognized that product success depends on customer experience as well as engineering. In
Ford’s case, the success of the Model-T wasn’t simply down to his simplification of component tech or his
innovative production line assembly process, the Ford Motor Company also promoted the lifestyle concept of
‘automobiling’. They created local motoring clubs to encourage car owners to explore the countryside and
participate in organized driving activities, which established the product as more than just a transport solution.
They designed both the product and the user experience of owning it.

Page 31
When engineers adopt design thinking, the impact is huge.

Notably, Ford didn’t initially offer customers a choice of colors and specifications, they built a product
around the customer journey, not the customer’s taste. Like Steve Jobs who decided, when he
returned to Apple, that they would scrap the complex model line and make only four computers, a
laptop and desktop for home and a similar pairing for work. That’s another example of designing for
the customer’s needs, not technical specifications.

Like Ford, Jobs also shifted the product engineering process towards collaborative design by
considering the role Apple’s engineering played in people’s lifestyles. After his return to Apple, this
human centric approach cast Apple products in a mould more akin to furniture and household
appliances than the beige box Apple product range at the time. The new Apple Macs weren’t simply
defined by the function of computing, but by the need to be intuitive and aesthetically pleasing.

Page 32
When engineers adopt design thinking, the impact is huge.

• Similarly, Apple designers studied customer behavior to improve their user manuals and
discovered they were mostly thrown away with the product packaging or left shrink-wrapped and
unused. So the company made a supreme effort to make their software easier to use and obviate
the need for manuals in the first place. Again, this was observing customer experience and
engineering products accordingly, not assuming because every other product in the category had a
manual, manuals were fixed points on the customer journey.

Page 33
Into the future: Will design-led engineering become the norm?

Striving for perfection is a noble aspiration, but celebrating human imperfection is proving to be a
smarter business model.
Of course, it would be rash to ignore the complexities of the globalized economy and make
sweeping generalizations about it, but it would also be rash to ignore the impact of different
regional design and engineering cultures upon shaping that complexity. And in terms of the digital
economy, it has certainly been shaped by the difference between the engineering-led approach of
assuming “build it and they will come” and the collaborative design-led approach that says “find
out where they go, and build something there.”

Page 34
Team Formation
• Forming project teams – the right mix is key to success
• It is well known, that teamwork is essential for projects. Many research papers, books and standards
highlight this fact.
• Bruce Tuckman´s stages of team development – forming, storming, norming, performing and adjourning –
are well known in the community and explained in nearly all project management trainings. However, little
attention has been paid so far to the team composition. Though observing teams in real life we often
recognise that they are basically formed with people from the functional department being available at the
moment of the request. It would be simply coincidence that those people fit together. The project
manager may form them throughout the project lifecycle to a performing team. Nevertheless, it is more
likely that they underperform or stall.

Page 35
Team Formation

• Another problem is, that project managers often do not know which people they need for their project. A
team is a social system, which builds on a “good” match of motivation, skills and interactions of its
constituents parts, like an orchestra. If one person does not fit, the whole team will most likely
underperform. Thus, the project manager needs to analyse the project tasks and derive key requirements
for all team members.
• It does not necessarily need to be a “perfect” team, all three, the motivation, skills and interactions could
be developed along the project lifecycle. This is the main leadership task of a project manager, but also
the team itself can help individual members and the interactions between them to grow. It is the
self-organisation of the team that helps to overcome some deficiencies of the original team composition.
However, if the basic requirements of the team members are not fulfilled, the “healing forces” of
self-organisation and leadership might not be enough for a successful completion of the project.

Page 36
Bruce Tuckman´s stages of Team Development

Page 37
Team Formation

Page 38
How to reach the right mix of a project team?

This is a joint effort of three parties

1. Project Manager
The project manager, analyzing the project with its requirements regarding people and developing the
team systematically along Tuckman´s five stages.

2. Project Sponsor
The project sponsor, ensuring the deployment of the “right” team members from the functional
departments in order to help the project to succeed.

3. Project Team member


The project team members themselves, performing assigned tasks in the best possible way through
motivation, skills and interaction.

Page 39
Project Documentation

• Project documentation is the implementation of a streamlined, efficient, and uniform process for
producing the key documents that are required to implement a new project successfully.
• For example, these documents might include, business cases, project status reports, and project
requirement sheets.
• In addition, the project documentation process outlines a clear approach for organizing these essential
project documents. This uniform, considered approach means that these key documents will be easy for
your whole team to use (and find!) – ensuring that the creation of your new project goes without a
hitch.

Page 40
Project Documentation

• By adhering to these guidelines, you will be able to establish complete traceability of the documents in
your workflow. Beyond this, the process of project documentation also involves the outlining of a clear
and accessible layout, format, and level of written content.
• Normally a standardized process of project documentation is put in place by the project manager (to
manage the documentation for their particular project effectively), or by a team leader (to cover any
documentation that is being created to complete a task).
• In general project documentation is a vital standardized organizational technique that your entire team
should be practising. It is also an essential tool for ensuring that your business consistently
produces successful projects.

Page 41
Project Documentation

• In addition, the project documentation process outlines a clear approach for organizing these essential
project documents. This uniform, considered approach means that these key documents will be easy for
your whole team to use (and find!) – ensuring that the creation of your new project goes without a
hitch.
• By observing to these guidelines, you will be able to establish complete traceability of the documents in
your workflow. Beyond this, the process of project documentation also involves the outlining of a clear
and accessible layout, format, and level of written content.
• Normally a standardized process of project documentation is put in place by the project manager (to
manage the documentation for their particular project effectively), or by a team leader (to cover any
documentation that is being created to complete a task).
• In general project documentation is a vital standardized organizational technique that your entire team
should be practicing. It is also an essential tool for ensuring that your business consistently
produces successful projects.

Page 44
What Are the Benefits Of Project Documentation?

Sets and defines your project goals

• Project documentation guides you towards setting and defining clear goals, while ensuring that everyone
involved (the project manager and the stakeholders) has the same expectations of the project. This
process requires you to question the validity of each document that is being created.

• In the project initiation step, you create the Project Business Case and the Project Charter document,
which enable you to define both your project’s goals and the resources that are required to make it
happen.

• Establishing these pieces of documentation from the get-go, means you’ll have clarity about the project’s
core aims and objectives. This in turn means that, with each step you take, your team is sure that they
are actively working towards achieving these project goals, without exceeding the project’s allocated
resources.

Page 45
What Are the Benefits Of Project Documentation?

Supports the project planning stage

• Each document has a clear function and a role to play within project documentation. Project
managers use them to create very detailed Work Breakdown Structures which, in turn,
enable them to draft realistic and attainable schedules.

• Each document that the project manager creates supports the planning process, which
speeds up and optimizes the execution of the project as a whole.

Page 46
What Are the Benefits Of Project Documentation?

Gives a clear overview of the project

• Because all of these documents are constantly kept up-to-date, all of the stakeholders involved in the
creation process are always aware of the project’s current status.

• This method is especially useful for project managers who are working with remote teams. An ability to
manage and organize a team is just one of the key skills that a marketing project manager needs to
have. Project documentation gives those managers an easy yet effective way to get a quick status
update on a project, which has multiple team members contributing to it.

Page 47
What Are the Benefits Of Project Documentation?

Manages risks and issues

• The project manager will create a RAID document, as part of the project documentation process..
This will prepare them for any possible risks or issues, and so they will be well-equipped to deal with
them, should they crop up.

• For example, a strong project documentation process requires the creation of a feasibility report.
This outlines the benefits of the project and its probability of success; thus enabling the project
manager to mitigate any potential risks, for example, regarding the financial success of the project.

Page 48
What Are the Benefits Of Project Documentation?

Makes the project traceable


• As we mentioned earlier, the project documentation process gives you a thorough, complete
knowledge of the roles and deadlines governing the workload of each team member. This ability
forms a key part of the lessons learned register, by making the project fully traceable and
transparent. At the end of the project, the project manager can evaluate what worked well, and what
aspects need improvement.

Page 49
Key Project Documents with Project Documentation

• Project Initiation
• This phase occurs at an organizational level, where it meets a company-wide need. The project is
proposed, outlined, approved and receives the required funding.

Page 50
Log Book
• Logbooks are primarily used in the engineering profession as a way to document an individual’s progress
with a particular project.

• Project log books are used to record your daily activity from the very first thing you do in starting the
project (an introduction statement what your project is all about), to the completion of the effort (including
the final results, did your project meets the core objectives, etc.)

• Activities such as precursory analysis, initial sketches, task lists, programmatic issues, reflections of past
work, meeting agendas and meeting minutes are typical items recorded in a logbook.

• Logbooks are typically hardback, paper based products that are bound in such a way as to ensure that
pages cannot be removed; consequently, logbooks are sometimes used as legal records in professional
liability, intellectual property and project scope disputes.

• An engineering logbook is a personal/professional reference about project learning and results.

Page 51
Example: Log Sheet

Page 52
Types of Logbooks:
Generally, there are three types of logbooks:
• Equipment Logbooks - Kept near an asset and used for a particular equipment
∙ Site Logbooks - Kept in a control room or head office and applying for the overall site
∙ Personnel Logbooks - Kept with a staff member. these typically apply to multiples sites to which the staff
member has responsibilities

Page 53
Forms and Attributes of Logbooks

Forms of Logbooks:
• Structured – These contain prescribed fields usually to meet the statutory maintenance requirements.
• Unstructured – These are open ended sheets of paper where the contractor can record notes as they deem
appropriate.

Attributes of Logbooks
Logbooks have the following attributes:
• A logbook is a living document that contains dynamic data.
• They are essentially classed as historical documents.

Page 54
Documentation

What is documentation?
Documentation refers to a set of records that professionals or companies keep to provide evidence or
information that can be used to inform decisions. In the workplace, documentation is retained records of
employment and company actions and events as required by legal mandates and company policy.

The importance of documentation (i.e. why should you care about this?)

1. A single source of truth saves time and energy

2. Documentation is essential to quality and process control

3. Documentation cuts down duplicative work

4. It makes hiring and onboarding so much easier

5. A single source of truth makes everyone smarter

Page 55
Types of documentation in system:

1. System documentation
2. User documentation.
• SYSTEM DOCUMENTATION
• records detailed information about a system’s design specifications, its internal workings, and its functionality

divided into internal and external documentation.


• Internal documentation is written in a program as comments. Internal documentation refers to the records that
your organization keeps and uses to inform decisions within your company
• External documentation is written in a place where people who need to use the software can read about how to use
the software. External documentation includes the outcome of all of the structured diagramming techniques, such
as data-flow and entity-relationship diagrams.

• USER DOCUMENTATION
• is written or other visual information about how an application system works and how to use it. Although not part
of the code itself, external documentation can provide useful information to the primary users of system
documentation—maintenance programmers. Page 56
Design strategy

• Design strategy applies the tactical thinking of a business strategy to the needs of the user in order to
create the most effective product.
• This intersection between corporate strategy and design thinking achieves long-term goals through creative
applications targeted at the end-user.
• Unlike strategic planning, which collects data to make a decision about how to approach a goal, strategic
thinking involves an entire group that makes meaningful contributions at all levels in the business.
• A design strategy is created by understanding the business needs of the customer and aligning the design
and design process around those business needs. Each step of the design process should map to the goals
and outcomes of the business problem that needs to be solved.

Page 57

You might also like