Computational thinking and design process with Littlebits droids

Cybersecurity First Principles in this lesson


In this lesson, we will learn how components can be used to solve a problem by decomposing it into sub-problems. We will also learn about how the design process can be applied to imagine a problem, think about different solutions, and then iteratively make attempts to solve it - getting better solutions at each iteration. The Littlebits Scratch programming interface will be used as an organizing technology platform for these activities.


By the end of this tutorial, you will be able to:

Materials Required

Prerequisite lessons

Intro to components using Littlebits Droids

Table of Contents

The Design Process

Design is more than sitting down and starting to code. In the real world when faced with a complex problem, companies, and individuals need a systematic process to think about the problem, consider all of the stakeholders and come up with a solution. In this lesson, we examine a 5-step design thinking process created by the Hasso-Plattner Institute of Design at Stanford. Their process is iterative and non-linear.

design process

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Empathizing and Defining

I group these two stages together as they are very iterative.

design process

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Before trying to solve a problem, one must understand it. Complex real-world problems involve more than one stakeholder. If you are trying to design software, for instance, you need to cognizant of all of your users, not just some of them. Implicit bias (where problem solvers accidentally leave some users out) can be a real issue if problem solvers don’t empathize with their users. In this sense, empathizing is the part of the design process where we observe and study our user base, build user stories that describe who our users are and what they want to do with our product, and then make sure we have coverage across our user population. Empathy is also important for setting aside our assumptions so that our product can meet the needs our users and not ourselves.

design process

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

After we have gathered some data about our users and empathically considered their perspective, we can begin to define the problem. It should be noted that the define stage is not done once we initially define the problem. We will keep returning to the problem statement as we test our potential solutions. With definition, we want to make problem assumptions clear and define the requirements for any potential solution.

Some processes for empathizing and defining the problem

A good technique for empathizing and defining the problem is affinity diagramming. This technique helps development teams consider multiple perspectives and is a great process to use with groups of users from the target population.

For affinity diagramming, you need some sticky note cards, a few ink pens or markers, and a few questions. The questions get posed the group. Individuals in the group think up their answers and write them on the note cards, and then the facilitator goes note by note and the group decides how to categorize the notes. No note is bad.

This can produce some interesting categories that help define and contextualize the problem.

User stories are another useful technique for contextualizing a problem. User stories are used pretty extensively in software design and development - particularly in teams using a process called Agile.

A user story is generally written as:

As a type of user, I want to some action, so that I can rationale.

an example would be:

As a instagram user in highschool, I want to post pictures of myself and my friends, so that I can build my social status at school.

This may create very different requirements that a different kind of instagram user with different actions and rationales, e.g.

As a company on instagram, I want to post pictures of my products, so that I can build brand recognition.

Both statements help define requirements for any potential solution.



Once we can begin to stabilize the problem definition, we can start zoning in on solutions. The ideation phase is very important to help us find as many possible solutions to the problem as possible - so that we can pick the best one. Often times, computer scientists and developers don’t ideate enough before jumping into development. This can lead to some myopic focus on one particular design - that might be bad.

When ideating, there are several techniques you can use to come up with good ideas.

One is obviously brainstorming - where the team sits around a table and thinks up different ideas to address the problem. Brainstorming is great, but it is better applied as a second step.

First, a technique called worst possible idea is a good starting place. Worst possible idea runs counter to out notions of solving a problem, but its a helpful exercise. Here, participants come up with the absolute worst solutions to a problem that they can think of. Bad solutions are considered for why and how they are bad - to list out all the reasons.

Going through this process, the group begins to get a notion of the solutions to avoid. This is a great time to introduce brainstorming. The group can start to frame new ideas in terms of how they avoid the mistake and pitfalls of the bad ideas. This can help break town team-dynamics barriers that often emerge whenever a particular team member becomes attached to their particular idea.


design process

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Prototyping and Testing

design process

Prototyping is the stage where you start making. Prototypes should not be full-fledged at the beginning. Since we aren’t always sure if an idea coming out of the ideation stage is really going to work, we don’t want to spend too much time on it at first. Prototypes can help to identify whether or not an idea will pan out. Often prototypes lead to new ideas - because different members of a team begin to bounce ideas off one another to create better ones.

As you progress, prototypes need to be tested.

design process

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Testing a prototype helps us to learn whether or not it succeeds (i.e. does it meet the requirements of the problem) and can help to refine the definition of the problem - if we learn something about the problem that we hadn’t thought of before.

Scratch 101 in Littlebits App

Try coding your droid.

Exercise: Apply design thinking to solve a problem with Littlebits

The problem: Navigate a course, drop an object on the dropzone, and drive out.
The twist: You must drive and deliver the object using a scratch program written on your R2-D2.

Work in teams.


Make sure to use the design process, in this case since the problem is defined, focus on the ideating, prototyping, and testing phases Consider decomposing the problem into subproblems and solving each one of them You can use parts from more than one droid kit, just make sure everyone gets their parts back at the end.

Reflection and takeaways

The design process is useful for conceptualizing a problem and exploring different solutions that meet all of your user’s needs or meet the requirements of the problem. Often, breaking a problem down into subproblems can help you tackle complex issues. Components can be used in more than one way for more than one purpose. This leads to reuse and is a positive side effect of modularization and resource encapsulation.

Additional Resources

For more information, investigate the following:

Lead Author


This lesson was inspired and informed by a blog post written by Rikke Dam and Teo Siang. Materials in this lesson are used consistent with their CC-v3 license.


Nebraska GenCyber Creative Commons License
is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Overall content: Copyright (C) 2017-2018 Dr. Matthew L. Hale, Dr. Robin Gandhi, Dr. Briana B. Morrison, and Doug Rausch.

Lesson content: Copyright (C) Dr. Matthew L. Hale 2018.
Creative Commons License
This lesson is licensed by the author under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.