Desigining Today's Web

Slides from the Build Right Designing Today's Web Workshop presented at Converge SE 2015, Columbia, SC.

1. @katiekovalcin @jeremyloyd
3. #brworkshop
4. Wifi: Soco-Guest PW: hellosoco
5. Collaborative notes link: http://bit.ly/1ayGSSG
6. About Us
7. About You
8. What We Wanted to Talk About ‣ Typography ‣ Hierarchy ‣ Layout ‣ Examples ‣ Other awesome nerdy design stuff
9. What does it mean to be a web designer today?
10. Let it go!
11. Topics ‣ Designing for Speed ‣ Design Pairing ‣ Designing Systems ‣ Designing Client-Proof Layouts ‣ Anything Goes
12. What We Wanted to Talk About ‣ Typography ‣ Hierarchy ‣ Layout ‣ Examples ‣ Other awesome nerdy design stuff
13. Let’s make this a conversation.
14. DESIGNING TODAY’S WEB DESIGNING 
 FOR SPEED
15. How we used to design for it
16. We didn’t!
19. $3.83 to visit your site in the best case scenario
20. Almost 50% of daily income to see your designs
23. Let’s take a look at some of our own examples…
24. This happens when designers control every aspect of the visual experience, not the full browser experience
25. “How is this a design problem? I want my sites to look good! Developers can make it fast, right?”
26. “But here’s the thing: the web is far more fragile than we might like to admit. It’s fraught with uncertainty—a connection could be dropped, or a network’s latency could be too high—which means entire elements of our designs might never reach our users.” – Ethan Marcotte
28. Let it go!
29. LET GO OF EVERY POSSIBLE AESTHETIC OUR LITTLE DESIGNER HEARTS DESIRE
30. “Sometimes you’ll make choices that favor performance; other times, you’ll make choices that favor aesthetics. The key is using all the information available to you to make the right decision for you and your site.” – Lara Hogan
31. Project Timeline Design Development
32. Design Reviews Design Development Performance Checking: • Are there red flags? • Can you offer a solution?
33. Carousel Red Flags • Push back on priority • What alternate solutions can we offer? Design Reviews
34. Image However, don’t push back: • If it’s “too difficult” • “Dumb idea” • Subjectively don’t like it • Can’t offer alternatives Social Design Reviews
35. Design Development Mockup designs in code • Run performance tests on early designs • Designer & Developer pair up to refine/address problem areas Get into code early!
36. Performance 
 Budgets
37. Establishing
38. Important Metrics 1.Page weight (kb/mb) 2.Start Render (s) 3.Fully Loaded (s)
39. Page Weight
40. $500 monthly budget 1.$100 Clothes 2.$100 Groceries 3.$300 Rent
41. $400 monthly budget 1.$100 Clothes 2.$100 Groceries 3.$300 Rent
42. $400 monthly budget 1.$100 Clothes 2.$100 Groceries 3.$300 Rent
43. $400 monthly budget 1.$50 Clothes 2.$50 Groceries 3.$300 Rent
44. $400 monthly budget 1.50kb Fonts 2.50kb CSS 3.300kb Images
45. $400 monthly budget 1.100kb Fonts 2.50kb CSS 3.200kb Images 4.50kb JavaScript
46. 1. What is a performance budget? 2. What is this project’s budget? • Cite goals/requirements 3. Why are we using this? 4. How we add new features • (optimize, remove, or don’t add) 5. Every template’s weight 6. Image optimization guide Define for them:
47. Curveballs!!!!
48. 3 options: 1.Optimize Existing Feature 2.Remove Existing Feature 3.Don’t Add
49. $400 monthly budget 1.0kb System Fonts 2.50kb CSS 3.350kb Images
51. “The weight of a font kit is arguably more important to a site’s performance versus other heavy hitters (like images), because fonts are loaded on every single page.” – Alternatives to Popular Web Typefaces for Better Performance
52. Alternatives Speedy Fonts Futura: 268kb • book • book italic • bold • bold italic Speedy Fonts Brandon Grotesque: 133kb • book • book italic • bold • bold italic
53. “Is the extra 135kb worth the aesthetic change?” “Does the heavier font kit better represent the brand?”
54. Fonts: Book—20kb Book Italic—20kb Bold—20kb Bold Italic—40kb Groceries: Veggies—$20 Pizzas—$20 Fruits—$20
 Meats—$40 $100 100kb
55. Curveball!!!! I had to spend $60 at the vet
56. Fonts: Book—20kb Bold—20kb +System Fonts Groceries: Veggies—$20 Fruits—$20 +Pantry Foods I’ve 
 been avoiding eating 
 for 2 months $40 40kb
60. Images
61. Image Quality Default: 971kb Quality 60: 213kb http://responsivedesign.is/articles/reducing-image-sizes
62. Image Quality Quality 60: 213kb Quality 60 + blurred: 152kb http://responsivedesign.is/articles/reducing-image-sizes
63. Which image format? http://larahogan.me/images/
64. Pick your favorite site, or choose one from awwwards.com. Run it through webpagetest.org & sketch/list out ideas for ways the design could be faster. EXERCISE
65. DESIGNING TODAY’S WEB DESIGN 
 PAIRING
66. PSD SKETCH CODE
67. (weeks later) Coded site only 
 resembles the PSD
69. Who’s been here?
70. Comping every detail on every unique template
72. Let it go!
73. LET GO OF OUR DESIRE TO CREATE “PERFECT” COMPS OF EVERY PAGE.
74. Let’s do just enough in static design applications
75. Design Pairing! CODE PSD SKETCH
76. What is Design Pairing? Periodic sessions during a project where designer and developer sit together and collaborate.
77. “Let’s change the phrase ‘designing in the browser’ to ‘deciding in the browser’” – Dan Mall
78. There’s value in deciding together.
79. Fosters an environment of iteration
80. Allows for periodic refinement during the life of the project
81. Design Pairing helps designer and dev level up.* * This is super important
82. Designers learn how the site is built, development techniques
83. Developers learn about design, what the vision is for the site
84. The next time they pair, it will be that much easier
87. Humility
88. Empathy
89. Developers can 
 contribute creatively!
98. Client gives thumbs up.
100. When we met
101. Set a regular schedule
102. When there were questions or problems
107. When the scope changes
110. Sometimes static explorations are needed.
112. It’s good to get our hands dirty in the code.
113. http://bit.ly/1NJkSae
114. Take good notes.
116. Pairing is not a replacement for UX design DISCLAIMER:
117. It’s helpful to think 
 through interactions before 
 pairing takes place DISCLAIMER:
118. Remote Pairing
119. Make a list of things that are hindering you from pairing effectively with developers. DISCUSSION
120. DESIGNING TODAY’S WEB DESIGNING SYSTEMS
121. How we used to design pages
122. http://www.slideshare.net/danielmall/design-deliverables-for-a-postcomp-era
123. We can control every last pixel placement on the page*
124. We can control every last pixel placement on the page* At every breakpoint
125. We can control every last pixel placement on the page* At every breakpoint *LOL we know this never actually happens
127. Not only time consuming, but also can lead to a messier, heavier design
129. Reducing the amount of styles we use reduces the amount of CSS, 
 optimizing performance
130. Let it go!
131. LET GO OF CONTROLLING THE LAYOUT OF 
 EVERY SINGLE PAGE
132. Step 1
 Find an Aesthetic
133. Element Collage
134. Element Collage
135. codepen.seesparkbox.com
136. Element Collage
137. Style Tiles
138. Style Prototype http://building.seesparkbox.com/style-prototype/
139. Step 2 Design a Key Page
140. Design a page as you do
141. It’s a means to an end. Whatever tool you prefer, we still aim to 
 get into code ASAP
142. Epicenter Design
143. “Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward.” https://gettingreal.37signals.com/ch09_Epicenter_Design.php
148. Realistic Fidelity
150. What needs to be shared with client? VS What does the developer need?
151. Step 3
 Track Your Styles
152. Keep an open, blank document and copy styles over
154. Step 3.5
 Condense Your Styles
155. Are my type styles different enough to warrant the style change?
156. What’s the purpose of a UI element? Are they similar functions? Where can I condense?
158. ‣ Buttons ‣ “View All” vs. “Read More” ‣ Type Hierarchy ‣ Similar modules—can they be the same with slight modifications?
159. Step 4
 Extend Your Modules
160. “Focusing on creating healthy front-end modules instead of complete pages can help break complex page layouts into reusable solutions.” – Dave Rupert
161. http://daverupert.com/2013/04/responsive-deliverables/
162. Embrace Constraints
163. What do you hate including in your designs that you know you have to anyways?
165. Step 5
 Piece Design
166. Interior vs. Homepage
167. “Once you have your styles for the site established, plugging them into the homepage should be a breeze. You will likely find yourself only writing a couple new styles.” – Marshall Norman
168. NAV FOOTER CONTENT HERO B A C NAV FOOTER CONTENT A NAV FOOTER CONTENT A B C NAV FOOTER CONTENT HERO A template 1 template 2 template 3
169. NAV FOOTER CONTENT HERO B A C NAV FOOTER CONTENT A NAV FOOTER CONTENT A B C NAV FOOTER CONTENT HERO A home template template 1 template 2 template 3
170. * Example screenshot mockups
171. * Example screenshot mockups This is a screenshot of the same module from the homepage. Does not need designed!
172. * Example screenshot mockups This was already established—does not need designed!
173. * Example screenshot mockups Only these two patterns needed to be designed for this entire page!
174. Important: stay organized
176. Proper document organization means folders start to look like…
177. Pattern Libraries
178. “Responsive deliverables should look a lot like fully- functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs.” –Dave Rupert
179. DIY Pattern Libraries
182. Atomic design
186. Kickstart pattern library in design
187. General Styles page
191. Jump into Typecast, choose “Type On Screen” template and play around with typography styles for your own personal blog (or for a ConvergeSE blog) EXERCISE
192. DESIGNING TODAY’S WEB DESIGNING CLIENT-PROOF LAYOUTS
193. The scenario. (You know what’s coming…)
195. Have you been here?
196. The client is going to push our layout and design to its limits.
197. Let it go!
198. LET GO OF THE ASSUMPTION THAT CLIENTS WILL AUTOMATICALLY USE THE SITE THE WAY WE INTENDED
199. We don’t effectively communicate the design intent to the client. THE PROBLEM:
200. http://bit.ly/1BQQW2r
201. “We may pride ourselves on building a great product, but it’s ultimately up to the client to see it succeed or fail. 
 Even the best website can become neglected, underused, or messy without a little education and training.”
202. Be intentional about educating the client throughout a project’s life. WHAT WE CAN DO:
203. Add documentation to 
 pattern library or style guide. WHAT WE CAN DO:
204. Work with clients after the 
 project is launched to measure 
 success and refine to meet 
 their needs. (the web is never done) WHAT WE CAN DO:
205. We don’t plan well for 
 varied content length. THE PROBLEM:
209. Prototype with a developer or use responsive tools. WHAT WE CAN DO:
213. Design Pairing! WHAT WE CAN DO:
214. We design with 
 ideal content. THE PROBLEM:
217. Design for the worst case scenario. WHAT WE CAN DO:
218. Develop with real content if possible. WHAT WE CAN DO:
219. We try to force design asthetics. THE PROBLEM:
220. Design modules that achieve both beauty and utilitarianism. WHAT WE CAN DO:
221. Embrace the fluid nature of the web. WHAT WE CAN DO:
222. We don’t plan well for the addition of new content. THE PROBLEM:
225. Design Modularly. WHAT WE CAN DO:
226. Stack content. WHAT WE CAN DO:
229. Others? THE PROBLEM:
230. Keeping in mind the styles you created in Typecast, sketch a “client-proof” page layout given these content needs: Blog image, article title, author, date, excerpt Featured Blog treatment EXERCISE
231. Congratulations! You have made the first 
 step in letting go!
232. Description here http://eepurl.com/bj0QSL
233. THANKS!