Enabling Design for a Complex Reality

Responsive Design was the reaction of creators on the web to cope under the mobile revolution. Exponentially growing fragmentation in screen resolution and density, processing power and memory, input devices and bandwidth pushed classic design approaches to it’s limits.

With the rise of the ‘internet of things’, the second coming of Augmented Reality and the ‘ubiquitous browser’ we have reached an unseen level of UI complexity. — Strategic design for this new reality requires better tools than box models and Photoshop.

Prototypes to the rescue! — The web and the browser as platform have become truly ubiquitous and allow us to build prototypes for a large variety of web and non–web environments with a well understood, progressively developed and comparably simple technology stack in very small time frames. Design for complex circumstances becomes transparent, tangible and before all else — it becomes fast again.

This talk will explore our approach to design through prototyping, show why we believe that prototypes are the way to go and explain how we’re using a technology stack selected for change to our advantage.

Transcript

1. DESIGN FOR A COMPLEX REALITY
2. TRUTH
3. ”If good design tells the truth, poor design tells a lie, a lie usually related to the getting or abusing of power.” ! ROBERT GRUDIN
4. The missing design proof
5. Deceptive design vs. Incorrect design
6. http://darkpatterns.org/
9. “Agile” all the things!
10. The wrong tools
11. A complex reality
12. How did we get here?
14. http://wikipedia.org/
15. http://flickr.com/photos/adactio/
16. Responsive design
18. Fragmentation of screen sizes is just one of many symptoms
19. Mobile first
20. Offline first
22. But wait, there’s more!
23. http://macrumors.com/
24. http://pcmag.com/
25. http://androidpolice.com/
26. http://androidpolice.com/
27. The “tweeting fridge”–problem
28. http://wikipedia.org/
29. Still more?
31. The upcoming generation will exclusively use mobile devices
32. The upcoming generation will no longer distinguish between online and offline
33. It’s a blurry mess but at least it plugs into the internet.
34. Blaming the tools
35. ”Men have become the tools of their tools.” ! HENRY DAVID THOREAU
36. (WARNING: Metaphor ahead)
38. — And that’s pretty much it.* (*Slight exaggeration for effect. Please don’t send me angry emails.)
39. Just kidding, we still have box models.
41. We need new tools
42. Prototyping as Tool for Strategic Design
43. ”We can only see a short distance ahead, but we can see plenty there that needs to be done.” ! ALAN TURING
44. A design proof
45. Work across silos
46. Support short iterations
47. Involve the user
48. Involve designers early–on
49. Enable sustainable solutions, not just another product
50. The 10.000ft view
51. POC Business prototype Production
52. The rules
53. Assumption is the root of all evil. 1
54. Every step of ideation must be followed by a step of validation. 2
55. Design should happen as close as possible to the client. 3
56. Constant change is not only anticipated but supported by all used tools. 4
57. 5 Prototypes don’t have to be dead ends.
58. The expectation
59. Allow for high development speeds
60. Adapt to change
61. Increase transparency
62. Simplify variations
63. The process
64. Prototyping Business prototype Feature Prototype Production Invalid feature Validation Integration
65. Workflow Concept Design Implementation Prototyping
66. A word on education
67. Prototyping using Web Technology
69. Enabling Innovation
70. 1. Web technology (HTML, CSS, JavaScript) 2.Meta languages (Haml, Slim, Sass, CoffeeScript) 3.Development stack built on interpreted languages (Ruby, JavaScript) Speed
71. 1. Deployed to publicly available servers with no dependencies on other systems 2.Accountability of the design 3.Accessible through modern and widely available browsers / no prerequisites 4. Higher availability of experts 5. Lower learning curve to build the skillset up Transparency
72. 1. Different takes on features – support for branching and merging through SCM (Git) 2.Visual variations for e.g. map skinning, app skinning or condition-based permutations 3.Variations of UI features per device/client Variations
73. 1. Multi-screen prototypes 2.Various input methods (touch, indirect, sensory) 3.Communication between devices (e.g. location sharing via a socket server) 4. Technology embeds Extending the browser
74. 1. Tangible design process 2.Present design intent clearly or even bypass steps like wire framing 3.(Very) short iteration cycles 4. Enable user testing or validation early on 5. Possible to utilize web analytics to track user behaviour, detect potential pitfalls and identify opportunities from data with less resources Validation
75. Example
76. 1. Flexible 2.Extendable 3.Modular 4. Convention over configuration Requirements on the stack
77. Example stack Server Client Instances WS Server External inputs
78. Server Server 1. Ruby 2.Middleman 3.Rack
79. Client Instances Client instances 1. HTML 2.CSS 3.JavaScript 4. SVG templating
80. WS Server 1. JavaScript 2.Node.js 3.Express 4. Einaros/WS 5. API/Access WS Server
81. Components 1. Mark–up 2.Styles 3.Functionality
82. Shared resources 1. Versioned 2.Isolated 3.Development using Bundler 4. Distributed as Ruby Gem via Github
84. Danke! florian.plank@siili.fi / @polarblau www.siili.fi