Save 37% off PRO during our Black Friday Sale! »

Desigining Today's Web

D91a97c5250fc5b34092f165b5b0499b?s=47 jeremyloyd
April 16, 2015

Desigining Today's Web

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

D91a97c5250fc5b34092f165b5b0499b?s=128

jeremyloyd

April 16, 2015
Tweet

Transcript

  1. @katiekovalcin @jeremyloyd

  2. None
  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!

  17. None
  18. None
  19. $3.83 to visit your site in the best case scenario

  20. Almost 50% of daily income to see your designs

  21. None
  22. None
  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
  27. None
  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

  50. None
  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
  57. None
  58. None
  59. None
  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

  68. None
  69. Who’s been here?

  70. Comping every detail on every unique template

  71. None
  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
  85. None
  86. None
  87. Humility

  88. Empathy

  89. Developers can 
 contribute creatively!

  90. None
  91. None
  92. None
  93. None
  94. None
  95. None
  96. None
  97. None
  98. Client gives thumbs up.

  99. None
  100. When we met

  101. Set a regular schedule

  102. When there were questions or problems

  103. None
  104. None
  105. None
  106. None
  107. When the scope changes

  108. None
  109. None
  110. Sometimes static explorations are needed.

  111. None
  112. It’s good to get our hands dirty in the code.

  113. http://bit.ly/1NJkSae

  114. Take good notes.

  115. None
  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
  126. None
  127. Not only time consuming, but also can lead to a

    messier, heavier design
  128. None
  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
  144. None
  145. None
  146. None
  147. None
  148. Realistic Fidelity

  149. None
  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

  153. None
  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?
  157. None
  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?
  164. None
  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

  175. None
  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

  180. None
  181. None
  182. Atomic design

  183. None
  184. None
  185. None
  186. Kickstart pattern library in design

  187. General Styles page

  188. None
  189. None
  190. None
  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…)

  194. None
  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:
  206. None
  207. None
  208. None
  209. Prototype with a developer or use responsive tools. WHAT WE

    CAN DO:
  210. None
  211. None
  212. None
  213. Design Pairing! WHAT WE CAN DO:

  214. We design with 
 ideal content. THE PROBLEM:

  215. None
  216. None
  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:
  223. None
  224. None
  225. Design Modularly. WHAT WE CAN DO:

  226. Stack content. WHAT WE CAN DO:

  227. None
  228. None
  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!