Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Intersection18: From a "Simple" App Challenge for Astronauts to an Enterprise Re-design Challenge - Panayotis Tzinis

38 views

Published on

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.

Published in: Design
  • Be the first to comment

  • Be the first to like this

Intersection18: From a "Simple" App Challenge for Astronauts to an Enterprise Re-design Challenge - Panayotis Tzinis

  1. 1. From a simple app to Enterprise Design Panayotis Tzinis GDE – X-Lab 1 Intersection 18 | Prague Sep,07 | 018
  2. 2. Theoretical Convergence
  3. 3. Theoretical Convergence Eventual Target
  4. 4. Theoretical Convergence Eventual Target Actual Progress
  5. 5. The Crew Timeline 6
  6. 6. Cautions & Warnings 7
  7. 7. Communication Status 8
  8. 8. The Steps we took for building the App 01
  9. 9. 10 01 Research & Development 02 The Users 03 Validated Prior finding 05 Research Insights 06 Technology Review 07 Design Processes
  10. 10. The steps we took for proposing redesign enterprise strategies 02
  11. 11. 12 01 Research & Development 02 The Users  Departments 03 Validated Prior finding 05 Research Insights 06 Processes Review 07 Design Processes 08 Visions UX Thinking processes
  12. 12. Research & Development01
  13. 13. 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
  14. 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 15 Scrum Theory 01 Commitment 02 Courage 03 Focus 04 Openness 05 Respect
  15. 15. Internal Design Sprints
  16. 16. Internal Design Sprints Sharing outcomes with partners
  17. 17. Internal Design Sprints Sharing outcomes with partners
  18. 18. Internal Design Sprints Sharing outcomes with partners S.R.E
  19. 19. Internal Design Sprints Sharing outcomes with partners S.R.E Site Reliability Engineering
  20. 20. Internal Design Sprints Sharing outcomes with partners S.R.E Site Reliability Engineering How Google runs Productions Systems
  21. 21. 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.
  22. 22. Awesome … … …
  23. 23. Awesome … … … … … but how it works?
  24. 24. 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
  25. 25. S.R.E. https://landing.google.com/sre/resources.html
  26. 26. What are wicked problems?
  27. 27. 29 29
  28. 28. 30 30 By the pricking of my thumbs, something wicked this way comes. - MacBeth, William Shakespeare
  29. 29. 31 31 So many unknown and unforeseen factors and complications...
  30. 30. “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)
  31. 31. Sometimes it is easier to define what something is not.
  32. 32. How can we recognize a wicked problem when we see it?
  33. 33. 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)
  34. 34. 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)
  35. 35. 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)
  36. 36. 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
  37. 37. 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)
  38. 38. Lab #1
  39. 39. 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.
  40. 40. 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.
  41. 41. 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.
  42. 42. 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.
  43. 43. 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.
  44. 44. 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?
  45. 45. 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.
  46. 46. 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.
  47. 47. Design Processes
  48. 48. Research Process Experiential Learning 4 50 Contextual Inquires 6 Interviews 21
  49. 49. Uncovering Insights
  50. 50. 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
  51. 51. 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
  52. 52. 54 Thank you! planet@mustafar.xyz

×