How a “simple” app implementation for a client in the Space Industry, helped our team to identify, isolate and rethink the whole procedures and communications our client had. Sometimes we focus on the tree, in this case a space rocket, and we miss the forest... in our case the galaxy. We will go through the tools used for building the app and how they unveiled pain-points and challenges within the organization itself. Sometimes we need to build a tool to explain what major changes should be faced within an enterprise.
14. Agile Manifesto
01 Individuals and Interactions Over Processes and Tools
02 Working Procedures Over Comprehensive Documentation
03 Collaboration Over Negotiation
04 Responding to Change Over Following a Plan
14
Scrum Theory
01 Commitment
02 Courage
03 Focus
04 Openness
05 Respect
15. Agile Manifesto
01 Individuals and Interactions Over Processes and Tools
02 Working Procedures Over Comprehensive Documentation
03 Collaboration Over Negotiation
04 Responding to Change Over Following a Plan
15
Scrum Theory
01 Commitment
02 Courage
03 Focus
04 Openness
05 Respect
22. Internal Design Sprints
Sharing outcomes with partners
S.R.E
Site Reliability Engineering
How Google runs Productions Systems
23. SRE is what you get when you treat operations as
if it’s a software problem.
Its mission is to protect, provide for, and progress the software and systems
behind all of Google’s public services — Google Search, Ads, Gmail, Android,
YouTube, and App Engine, to name just a few — with an ever-watchful eye on
their availability, latency, performance, and capacity.
26. 1. The Systems Engineering Side of Site Reliability Engineering
There are two main disciplines mingling together
A. Software Engineers
B. Systems Engineers
2. (Un)Reliability Budgets: Finding Balance between Innovation and Reliability
A metrics-based approach which provides an objective metric to guide
decisions involving tradeoffs between innovation and reliability
3. DiRT (Disaster Recovery Testing)
An annual test simulating catastrophes, like a loss in the Data Center, a
downtime on the servers, etc. This simulation aims at ensure “day-to-day
Google’s routine in services or departments. DiRT was developed to find
vulnerabilities in critical systems and business processes by intentionally causing
failures in them, and to fix them before such failures happen in an uncontrolled
manner.
4. Managing Incidents
Key = velocity in restoring normal business operations
32. “Wicked problems are real world problems that
acknowledge the complex interdependence of diverse
factors and stakeholders, rather than simplistic, linear,
cause and effect abstractions that isolate the product of
design from its context.”
Daniel Christian Wahl (Facing Complexity: Wicked Design Problems)
34. How can we recognize
a wicked problem
when we see it?
35. Wicked problems are unstructured.
It is difficult to sort out causes and effects, there are
numerous variables, and there is little consensus
when defining problems and identifying solutions.
1Weber & Khademiam (2008)
36. Wicked problems are cross-cutting.
They have many overlapping stakeholders with
different perspectives on the problem, and they have
many conflicting facets.
Different use cases have different needs and
outcomes that may be in conflict.
2Weber & Khademiam (2008)
37. Wicked problems are relentless.
They cannot be solved “once and for all.” There is no
single, optimal, final solution. They evolve and persist.
3Weber & Khademiam (2008)
38. We must solve them to clearly define them.
A wicked problem can be clearly defined only by
solving it (or part of it.)
This paradox implies that we must solve the problem
once to clearly define it, and then solve it again to
create a solution that works.
Peters & Tripp (1976) 4
39. Characteristics of wicked problems
1. Every wicked problem is novel and unique with multiple explanations.
2. One wicked problem is the sign, symptom, or cause of another.
3. Previously identified solutions to similar problems may be irrelevant.
4. We do not understand the problem until after we have solved it.
5. There is no small, finite set of possible solutions. There are many.
6. Solutions are incremental. There is no single, final, best solution.
7. Solutions are not right or wrong. They are on a scale from good to bad.
8. We are responsible for the outcomes of the solutions we create.
Adapted from Horst Rittel & Melvin M. Webber (1973) and Jeffrey Conklin (2006)
41. Controllocationreporting
1. Reporting device location may be turned off.
2. People with privacy concerns often do so.
Sketch a mobile interface
to control device reporting location.
42. Locate a device
3. People misplace or lose phones.
4. “Wait! Where’s my phone?!?”
5. Online tools can help people find their phone.
Sketch a a web interface
to locate a lost or misplaced device.
43. Re-activatedevicelocation
6. Unless they have turned off device location.
7. “I need to remotely control device location reporting.”
Sketch a web interface
to remotely control device location reporting.
44. Device location
7. “I need to remotely re-activate device location reporting.”
8. No.
9. “Why?!?”
10.If we could, it would introduce a concern about trust and privacy.
11.“BUT I NEED MY PHONE!”
12.We don’t know where it is. Sorry.
45. Device location
7. “I need to remotely re-activate device location reporting.”
8. No.
9. “Why?!?”
10.If we could, it would introduce a concern about trust and privacy.
11.“BUT I NEED MY PHONE!”
12.We don’t know where it is. Sorry.
Discuss the potential trust & privacy concerns
with remote re-activation of device location.
46. Solutionfacets
TECHNOLOGY BUSINESS
DESIGN
& EXPERIENCE
CULTURE
& ETHICS
What are we
capable of doing?
What do we need
to become capable
of doing?
What keeps us
viable?
What leads to
satisfaction,
loyalty, trust, and
revenue?
What must we do?
What are the user
needs, goals, and
expectations?
What is the
product?
What is the user
experience?
What should we
do?
What is the right
thing to do?
47. Solutionstrategies
Kelly Levin, Benjamin Cashore, Graeme Auld & Steven Bernstein (2007, 2012)
AUTHORITATIVE COMPETITIVE COLLABORATIVE
Tame wicked problems by
vesting the responsibility
for solving the problems in
the hands of a few people.
Solve wicked problems by
pitting opposing points of
view against each other
and requiring parties
holding these views to
come up with their
preferred solutions.
Engage all stakeholders in
order to find the best
possible solution for all
stakeholders.
48. Strategies for addressing wicked problems
Kelly Levin, Benjamin Cashore, Graeme Auld & Steven Bernstein (2007, 2012)
AUTHORITATIVE COMPETITIVE COLLABORATIVE
Tame wicked problems by
vesting the responsibility
for solving the problems
in the hands of a few
people.
Solve wicked problems by
pitting opposing points of
view against each other
and requiring parties
holding these views to
come up with their
preferred solutions.
Engage all stakeholders
in order to find the best
possible solution for all
stakeholders.
52. Research Insights
Coordination
between planning
and execution can be
improved by worker
suggestions.
Adjusting
instructions for a
user can improve
understanding.
1 3 4
Spatial references
help guide workers
through a procedure.
2
Workers track status
within a procedure.
52
53. Rational Discursive Critical Speculative
What are
we doing?
What should
we be doing?
What could
we be doing?
What might
we do or not do for a better future?
Design continuum
During regular missions aboard the International Space Station (ISS), NASA astronauts are tasked with conducting scientific experiments and performing a variety of maintenance operations. However, carrying out these operational tasks involves memory recall challenges due to the length of time that elapses between when astronauts receive training and when they execute tasks aboard the ISS. As NASA undertakes the next leap in a new era of human space exploration that extends beyond low-Earth orbit, an intelligent system that provides instructions can empower astronauts to autonomously execute procedures. This project started with understanding the context in which astronauts work. We used this research to design a working prototype of an augmented reality device that allows astronauts to get hands-free instructions for procedures. After several design iterations, we developed an an intelligent, connected device that leverages various technologies to empower astronauts performing unfamiliar procedures while maximizing their mobility. We considered how to present information that allows users to stay focused on the task at hand and navigate the user interface (UI) while keeping both hands free. We also implemented features to aid the user with navigation and tool location. The integration of all of these features provides astronauts with increased autonomy by reducing the dependencies that they have using current methods for procedure execution.
Looking like an excel spreadsheet, the Crew Timeline screenshot is difficult to understand without a prior knowledge of what the acronyms and abbreviations stand for. One major insight we were able to draw from this was an understanding of how tightly regulated the astronaut’s day is. From the moment they wake up, their day is a hard set list of actions and tasks. The black and white bar along the top also illustrates orbits around the earth and indicates when it will be light or dark (day or night). This could be quite disorientating to the astronauts and may affect the task they are currently working on.
It’s very difficult to interpret a screenshot like this without explanation and training. Pages like this highlight the complexity of the information an astronaut has to deal with on a day to day basis. This was also the first time we had to start to understand what to include and what to leave out.
The communication board gives a real-time status of the connection with Earth. The interface the astronauts work with is minimal but very practical.
We performed contextual inquiries at the Arc Jet complex at the Ames Research Center and the Thermal Protection System Facility at Kennedy Space Center. Observing these processes allowed us to observe two NASA procedures while they were being executed. Additionally, we performed research around nine domains whose conditions map closely to that of astronauts because access to current astronauts is extremely limited. Research in these analogous domains included two additional contextual inquiries, twenty-one interviews, and three experiential learning sessions in which we were able to perform the activities within the domain ourselves to give us hands-on knowledge of the experience.
We modeled all our research data in sequence models, flow models, and ultimately a 1000+ note affinity diagram. Analyzing these data, we found out that many of the findings in behavior were related to procedure execution that could lead to feasible solutions in the context of NASA.