Design Essentials für Techniker

Transcript

1. Design Essentials für Techniker
2. Ing. Christoph Hochstrasser twitter.com/hochchristoph hochstrasser.io facebook.com/ christoph.hochstrasser
3. Gründer & Inhaber Ing. Christoph Hochstrasser Digitale Lösungen für mehr Geschäftserfolg
4. HTL Waidhofen etec Abschlussjahrgang 2009
5. Techniker
6. Web Designer
7. Entwickler
9. Self-Taught
11. Lebenslauf • HTL Waidhofen/Ybbs, Höhere Abteilung Elektrotechnik; Abschlussjahrgang 2009 • 2010–2011: SZENE1.AT — Web Entwickler • 2011–2013: Talenthouse — Senior Web Developer, Product Owner talenthouse.com, Web Developer updatemi.com • Seit 2014: Selbstständig • Seit 2016: Co-Founder helloplace.net
12. Ing. Christoph Hochstrasser • Websites • Online-Shops • Softwarelösungen
13. hkw.cc
14. purecaps.net (+Grafenberg)
16. helloplace.net
17. helloplace Blog
18. updatemi Installation auf Cebit 2016
19. helloplace • Co-Founder • Visual Identity • Logo • Farben • Schriften • Web-Design • Design des Business Models • Entwicklung des Produkts
20. Worum geht’s heute?
21. Worum geht’s heute? • Was Design ist • Was euch Design bringt • 3 Design Prinzipien vorgestellt: • Job Stories • Orthogonality • Prototyping
22. Design Essentials
23. Grundlegendes über gute Gestaltung
24. Jeder ist Gestalter
25. Gestaltung ist überall und passiert überall
29. (Bad Design can kill people)
30. Was bringt Design?
31. Bei Design gehts um Empathie.
32. Bei gutem Design fühlst du, dass es einen Menschen gab, der sich die Mühe gegeben und sich die Zeit genommen hat dich zu verstehen.
33. Benutzer spüren gutes Design.
34. Design liefert nicht was Benutzer wollen, sondern was sie brauchen.
35. Bei Design geht es darum Entscheidungen zu treffen.
36. „If I had asked people what they wanted, they would have said faster horses” —Henry Ford “
37. Nicht nur irgendwelche Features, sondern die richtigen Features.
38. „Feature-itis”
39. Gutes Design begeistert.
40. Es geht darum die richtigen Fragen zu stellen.
41. Was sollen wir entwickeln?
42. Welche Features soll das Produkt enthalten?
43. Job Stories
44. Wir können nicht alles machen. Unsere Ressourcen sind immer begrenzt. Zeit, Geld, Entwickler und unsere eigene Aufmerksamkeit.
45. Wir sollen nicht eine Lösung vorantreiben und danach nach einem Problem suchen. Zuerst kommt das Problem, dann die Lösung.
46. Wie geht’s dem Menschen zu einem bestimmten Zeitpunkt, in einer bestimmten Situation?
47. Welchen Job, also welche Aufgabe, wollen sie erreichen?
48. Welche Ängste und Sorgen haben sie?
49. Beispiel • Wenn ich eine Aktivität für meine Familie suche, dann frage ich mich was es alles in meiner näheren Umgebung zu tun gibt, weil ich möchte nicht zu weit weg fahren oder nur spontan irgendwas unternehmen. • Ich mache mir Sorgen in der Nähe etwas Interessantes zu übersehen, das ich mit meiner Familie unternehmen hätte können.
50. Situation • Wenn ich eine Aktivität für meine Familie suche, dann frage ich mich was es alles in meiner näheren Umgebung zu tun gibt, weil ich möchte nicht zu weit weg fahren oder nur spontan irgendwas unternehmen. • Ich mache mir Sorgen in der Nähe etwas Interessantes zu übersehen, das ich mit meiner Familie unternehmen hätte können.
51. Sorgen und Ängste • Wenn ich eine Aktivität für meine Familie suche, dann frage ich mich was es alles in meiner näheren Umgebung zu tun gibt, weil ich möchte nicht zu weit weg fahren oder nur spontan irgendwas unternehmen. • Ich mache mir Sorgen in der Nähe etwas Interessantes zu übersehen, das ich mit meiner Familie unternehmen hätte können. • Ich mache mir Sorgen darüber ob das Ausflugsziel seriös ist.
52. Mögliche Lösungen • Damit Familien sehen was es in Ihrer Umgebung als Aktivitäten gibt, wollen wir in der Umgebung in einem Umkreis nach Aktivitäten suchen. Daher wollen wir nicht nach Bundesländer, Bezirke oder Gemeinden einteilen. • Um Familie die Sorge zu nehmen ob das Ausflugsziel seriös ist, werden alle Ausflugsziele von der Redaktion persönlich geprüft bevor sie angezeigt werden. • Oder alternativ: Die Ausflugsziele müssen einen bestimmten Betrag bezahlen bevor sie auf der Website angezeigt werden.
53. Wichtig zu Job Stories • Gute Job Stories sollen zu offenen Problembeschreibungen führen. • Job Stories sollen das Problem festlegen und Fakten schaffen. Das schafft Freiheit für viele Lösungsmöglichkeiten. • Die Story soll nicht die endgültige Lösung beinhalten. Es soll möglich sein viele mögliche Lösungen zu erforschen um die beste Lösung für die Story zu finden. • Eine Story soll nicht existieren, nur weil ein gewisses Feature entwickelt werden soll.
54. „You have a hard time collaborating on building a bridge when you can’t agree on the laws of physics.” —Ryan Singer, Basecamp “
55. Und jetzt?
56. Und jetzt? 1. Lösungen zu einem Prototyp machen. 2. Prototyp an echten Nutzern testen. 3. Gewonnene Einblicke in Ängste, Sorgen, Probleme in die Job Stories einarbeiten. 4. Zurück zum Start
57. Und jetzt? • Job Stories in eine lose Reihenfolge einordnen. • Das nennt man dann Roadmap. • Die wichtigsten Job Stories arbeitet man zuerst ab. Beim Kern des Produkts beginnen: „Was kann man nicht wegnehmen?”
58. Orthogonality
59. orthogonal = rechtwinklig
60. Das macht es nicht besser
62. Zwei Dinge die sich unabhängig voneinander bewegen können.
64. Wenn zwei Dinge zusammengehören, sobald sich eines ändert, das Andere aber von der Änderung nicht betroffen ist.
65. Beispiel
67. Messenger Phone • Wenn Software ein neues Bedienelement am Device braucht, dann muss sich der Kunde ein neues Device kaufen. • Ändert sich die Software, hat sich die Hardware zu ändern. • Daraus folgt: Software und Hardware sind nicht besonders orthogonal zueinander.
69. Smartphone • Wenn die Software ein neues Bedienelement braucht, dann ist sie nicht von der Hardware abhängig. Software kann rascher entwickelt werden und besser auf Kunden eingehen. • Software und Hardware können sich relativ unabhängig voneinander entwickeln. • Daraus folgt: Software und Hardware sind mehr orthogonal wie vorher.
70. Prototyping
71. Job Story sind immer noch unsere Vorstellung von dem, was wir glauben was das Problem ist.
72. Wir glauben das wir wissen was das Problem ist. Glauben ist nicht wissen.
73. Bis jetzt haben wir nur Annahmen getroffen.
74. Wie können wir jetzt herausfinden, ob unsere Annahmen auf die Wirklichkeit zutreffen?
75. In dem wir so oft und früh wie möglich einen Prototyp mit echten Kunden testen.
77. Prototyping • Design • Test • Build • Repeat
78. Prototyping • Nur so viel wie unbedingt notwendig in den Prototyp investieren. • Die Feedback-Schleife soll so klein wie möglich sein um keine Zeit mit Lösungen zu verschwenden die nicht funktionieren. • Fake it till you make it.
79. Prototyping Tools • Stift & Papier • Powerpoint • Smartphones • Business Model Canvas • Website
80. Beispiele
81. Beispiele • Ein Business Model auf einem Business Model Canvas mit potenziellen Kunden besprechen. Beim Kunden am Canvas Sachen ändern. • Die App als Powerpoint-Folien gestalten, auf ein Smartphone laden und dann echten Benutzern zeigen. •  WATCH Prototyp war ein iPhone, wo die Software innerhalb einer Abbildung der Watch auf dem iPhone Display lief. • Im  Design Studio stehen gleich die CNC Maschinen um Designs sofort an Ort und Stelle in Prototypen umzusetzen und zu testen.
82. Designing for Future Hardware https://developer.apple.com/ videos/play/wwdc2015/801/
86. Danke!
87. Fragen? christoph@hochstrasser.io twitter.com/hochchristoph facebook.com/christoph.hochstrasser