Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Desigining Today's Web

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.

jeremyloyd

April 16, 2015
Tweet

More Decks by jeremyloyd

Other Decks in Design

Transcript

  1. @katiekovalcin
    @jeremyloyd

    View Slide

  2. View Slide

  3. #brworkshop

    View Slide

  4. Wifi:
    Soco-Guest
    PW: hellosoco

    View Slide

  5. Collaborative notes link:
    http://bit.ly/1ayGSSG

    View Slide

  6. About Us

    View Slide

  7. About You

    View Slide

  8. What We Wanted to Talk About
    ‣ Typography
    ‣ Hierarchy
    ‣ Layout
    ‣ Examples
    ‣ Other awesome nerdy design stuff

    View Slide

  9. What does it mean to be a
    web designer today?

    View Slide

  10. Let it go!

    View Slide

  11. Topics
    ‣ Designing for Speed
    ‣ Design Pairing
    ‣ Designing Systems
    ‣ Designing Client-Proof Layouts
    ‣ Anything Goes

    View Slide

  12. What We Wanted to Talk About
    ‣ Typography
    ‣ Hierarchy
    ‣ Layout
    ‣ Examples
    ‣ Other awesome nerdy design stuff

    View Slide

  13. Let’s make this a
    conversation.

    View Slide

  14. DESIGNING TODAY’S WEB
    DESIGNING 

    FOR SPEED

    View Slide

  15. How we used to design for it

    View Slide

  16. We didn’t!

    View Slide

  17. View Slide

  18. View Slide

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

    View Slide

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

    View Slide

  21. View Slide

  22. View Slide

  23. Let’s take a look at some of our own
    examples…

    View Slide

  24. This happens when designers control
    every aspect of the visual experience,
    not the full browser experience

    View Slide

  25. “How is this a design problem? I want
    my sites to look good! Developers can
    make it fast, right?”

    View Slide

  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

    View Slide

  27. View Slide

  28. Let it go!

    View Slide

  29. LET GO OF EVERY
    POSSIBLE AESTHETIC
    OUR LITTLE DESIGNER
    HEARTS DESIRE

    View Slide

  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

    View Slide

  31. Project Timeline
    Design
    Development

    View Slide

  32. Design Reviews
    Design
    Development
    Performance Checking:
    • Are there red flags?
    • Can you offer a solution?

    View Slide

  33. Carousel Red Flags
    • Push back on priority
    • What alternate solutions can
    we offer?
    Design Reviews

    View Slide

  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

    View Slide

  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!

    View Slide

  36. Performance 

    Budgets

    View Slide

  37. Establishing

    View Slide

  38. Important Metrics
    1.Page weight (kb/mb)
    2.Start Render (s)
    3.Fully Loaded (s)

    View Slide

  39. Page Weight

    View Slide

  40. $500 monthly budget
    1.$100 Clothes
    2.$100 Groceries
    3.$300 Rent

    View Slide

  41. $400 monthly budget
    1.$100 Clothes
    2.$100 Groceries
    3.$300 Rent

    View Slide

  42. $400 monthly budget
    1.$100 Clothes
    2.$100 Groceries
    3.$300 Rent

    View Slide

  43. $400 monthly budget
    1.$50 Clothes
    2.$50 Groceries
    3.$300 Rent

    View Slide

  44. $400 monthly budget
    1.50kb Fonts
    2.50kb CSS
    3.300kb Images

    View Slide

  45. $400 monthly budget
    1.100kb Fonts
    2.50kb CSS
    3.200kb Images
    4.50kb JavaScript

    View Slide

  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:

    View Slide

  47. Curveballs!!!!

    View Slide

  48. 3 options:
    1.Optimize Existing Feature
    2.Remove Existing Feature
    3.Don’t Add

    View Slide

  49. $400 monthly budget
    1.0kb System Fonts
    2.50kb CSS
    3.350kb Images

    View Slide

  50. View Slide

  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

    View Slide

  52. Alternatives
    Speedy Fonts
    Futura: 268kb
    • book
    • book italic
    • bold
    • bold italic
    Speedy Fonts

    Brandon Grotesque: 133kb

    • book

    • book italic

    • bold

    • bold italic

    View Slide

  53. “Is the extra 135kb worth
    the aesthetic change?”
    “Does the heavier font kit
    better represent the brand?”

    View Slide

  54. Fonts:
    Book—20kb
    Book Italic—20kb
    Bold—20kb
    Bold Italic—40kb
    Groceries:
    Veggies—$20
    Pizzas—$20
    Fruits—$20

    Meats—$40
    $100 100kb

    View Slide

  55. Curveball!!!!
    I had to spend $60 at the vet

    View Slide

  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

    View Slide

  57. View Slide

  58. View Slide

  59. View Slide

  60. Images

    View Slide

  61. Image Quality
    Default: 971kb Quality 60: 213kb
    http://responsivedesign.is/articles/reducing-image-sizes

    View Slide

  62. Image Quality
    Quality 60: 213kb Quality 60 + blurred: 152kb
    http://responsivedesign.is/articles/reducing-image-sizes

    View Slide

  63. Which image format?
    http://larahogan.me/images/

    View Slide

  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

    View Slide

  65. DESIGNING TODAY’S WEB
    DESIGN 

    PAIRING

    View Slide

  66. PSD
    SKETCH
    CODE

    View Slide

  67. (weeks later)
    Coded site only 

    resembles the PSD

    View Slide

  68. View Slide

  69. Who’s been here?

    View Slide

  70. Comping every detail on
    every unique template

    View Slide

  71. View Slide

  72. Let it go!

    View Slide

  73. LET GO OF OUR DESIRE
    TO CREATE “PERFECT”
    COMPS OF EVERY PAGE.

    View Slide

  74. Let’s do just enough in
    static design applications

    View Slide

  75. Design Pairing!
    CODE
    PSD
    SKETCH

    View Slide

  76. What is Design Pairing?
    Periodic sessions during a project
    where designer and developer sit
    together and collaborate.

    View Slide

  77. “Let’s change the phrase
    ‘designing in the browser’ to
    ‘deciding in the browser’”
    – Dan Mall

    View Slide

  78. There’s value in
    deciding together.

    View Slide

  79. Fosters an environment
    of iteration

    View Slide

  80. Allows for periodic
    refinement during the life
    of the project

    View Slide

  81. Design Pairing helps
    designer and dev
    level up.*
    * This is super important

    View Slide

  82. Designers learn how the site is built,
    development techniques

    View Slide

  83. Developers learn about design,
    what the vision is for the site

    View Slide

  84. The next time they pair,
    it will be that much easier

    View Slide

  85. View Slide

  86. View Slide

  87. Humility

    View Slide

  88. Empathy

    View Slide

  89. Developers can 

    contribute creatively!

    View Slide

  90. View Slide

  91. View Slide

  92. View Slide

  93. View Slide

  94. View Slide

  95. View Slide

  96. View Slide

  97. View Slide

  98. Client gives thumbs up.

    View Slide

  99. View Slide

  100. When we met

    View Slide

  101. Set a regular schedule

    View Slide

  102. When there were questions
    or problems

    View Slide

  103. View Slide

  104. View Slide

  105. View Slide

  106. View Slide

  107. When the scope changes

    View Slide

  108. View Slide

  109. View Slide

  110. Sometimes static explorations
    are needed.

    View Slide

  111. View Slide

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

    View Slide

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

    View Slide

  114. Take good notes.

    View Slide

  115. View Slide

  116. Pairing is not a
    replacement for UX design
    DISCLAIMER:

    View Slide

  117. It’s helpful to think 

    through interactions before 

    pairing takes place
    DISCLAIMER:

    View Slide

  118. Remote Pairing

    View Slide

  119. Make a list of things that are hindering you
    from pairing effectively with developers.
    DISCUSSION

    View Slide

  120. DESIGNING TODAY’S WEB
    DESIGNING
    SYSTEMS

    View Slide

  121. How we used to
    design pages

    View Slide

  122. http://www.slideshare.net/danielmall/design-deliverables-for-a-postcomp-era

    View Slide

  123. We can control every last pixel
    placement on the page*

    View Slide

  124. We can control every last pixel
    placement on the page*
    At every breakpoint

    View Slide

  125. We can control every last pixel
    placement on the page*
    At every breakpoint
    *LOL we know this never actually happens

    View Slide

  126. View Slide

  127. Not only time consuming, but also can
    lead to a messier, heavier design

    View Slide

  128. View Slide

  129. Reducing the amount of styles we use
    reduces the amount of CSS, 

    optimizing performance

    View Slide

  130. Let it go!

    View Slide

  131. LET GO OF
    CONTROLLING THE
    LAYOUT OF 

    EVERY SINGLE PAGE

    View Slide

  132. Step 1

    Find an Aesthetic

    View Slide

  133. Element Collage

    View Slide

  134. Element Collage

    View Slide

  135. codepen.seesparkbox.com

    View Slide

  136. Element Collage

    View Slide

  137. Style Tiles

    View Slide

  138. Style Prototype
    http://building.seesparkbox.com/style-prototype/

    View Slide

  139. Step 2
    Design a Key Page

    View Slide

  140. Design a page as you do

    View Slide

  141. It’s a means to an end. Whatever tool
    you prefer, we still aim to 

    get into code ASAP

    View Slide

  142. Epicenter Design

    View Slide

  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

    View Slide

  144. View Slide

  145. View Slide

  146. View Slide

  147. View Slide

  148. Realistic Fidelity

    View Slide

  149. View Slide

  150. What needs to be shared with client?
    VS
    What does the developer need?

    View Slide

  151. Step 3

    Track Your Styles

    View Slide

  152. Keep an open, blank document and
    copy styles over

    View Slide

  153. View Slide

  154. Step 3.5

    Condense Your Styles

    View Slide

  155. Are my type styles different enough to
    warrant the style change?

    View Slide

  156. What’s the purpose of a UI element?
    Are they similar functions?
    Where can I condense?

    View Slide

  157. View Slide

  158. ‣ Buttons
    ‣ “View All” vs. “Read More”
    ‣ Type Hierarchy
    ‣ Similar modules—can they be the
    same with slight modifications?

    View Slide

  159. Step 4

    Extend Your Modules

    View Slide

  160. “Focusing on creating healthy
    front-end modules instead of
    complete pages can help break
    complex page layouts into
    reusable solutions.”
    – Dave Rupert

    View Slide

  161. http://daverupert.com/2013/04/responsive-deliverables/

    View Slide

  162. Embrace Constraints

    View Slide

  163. What do you hate including in your
    designs that you know you have to
    anyways?

    View Slide

  164. View Slide

  165. Step 5

    Piece Design

    View Slide

  166. Interior vs. Homepage

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  170. * Example screenshot mockups

    View Slide

  171. * Example screenshot mockups
    This is a screenshot of the same module from the
    homepage. Does not need designed!

    View Slide

  172. * Example screenshot mockups
    This was already established—does not need
    designed!

    View Slide

  173. * Example screenshot mockups
    Only these two patterns
    needed to be designed for
    this entire page!

    View Slide

  174. Important: stay
    organized

    View Slide

  175. View Slide

  176. Proper document organization means
    folders start to look like…

    View Slide

  177. Pattern Libraries

    View Slide

  178. “Responsive deliverables should look a lot like fully-
    functioning Twitter Bootstrap-style systems custom
    tailored for your clients’ needs.”
    –Dave Rupert

    View Slide

  179. DIY Pattern Libraries

    View Slide

  180. View Slide

  181. View Slide

  182. Atomic design

    View Slide

  183. View Slide

  184. View Slide

  185. View Slide

  186. Kickstart pattern
    library in design

    View Slide

  187. General Styles page

    View Slide

  188. View Slide

  189. View Slide

  190. View Slide

  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

    View Slide

  192. DESIGNING TODAY’S WEB
    DESIGNING
    CLIENT-PROOF
    LAYOUTS

    View Slide

  193. The scenario.
    (You know what’s coming…)

    View Slide

  194. View Slide

  195. Have you been here?

    View Slide

  196. The client is going to
    push our layout and design
    to its limits.

    View Slide

  197. Let it go!

    View Slide

  198. LET GO OF THE
    ASSUMPTION THAT
    CLIENTS WILL
    AUTOMATICALLY USE
    THE SITE THE WAY WE
    INTENDED

    View Slide

  199. We don’t effectively
    communicate the design
    intent to the client.
    THE PROBLEM:

    View Slide

  200. http://bit.ly/1BQQW2r

    View Slide

  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.”

    View Slide

  202. Be intentional about
    educating the client throughout
    a project’s life.
    WHAT WE CAN DO:

    View Slide

  203. Add documentation to 

    pattern library or style guide.
    WHAT WE CAN DO:

    View Slide

  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:

    View Slide

  205. We don’t plan well for 

    varied content length.
    THE PROBLEM:

    View Slide

  206. View Slide

  207. View Slide

  208. View Slide

  209. Prototype with a developer
    or use responsive tools.
    WHAT WE CAN DO:

    View Slide

  210. View Slide

  211. View Slide

  212. View Slide

  213. Design Pairing!
    WHAT WE CAN DO:

    View Slide

  214. We design with 

    ideal content.
    THE PROBLEM:

    View Slide

  215. View Slide

  216. View Slide

  217. Design for the worst
    case scenario.
    WHAT WE CAN DO:

    View Slide

  218. Develop with real content
    if possible.
    WHAT WE CAN DO:

    View Slide

  219. We try to force
    design asthetics.
    THE PROBLEM:

    View Slide

  220. Design modules that achieve
    both beauty and utilitarianism.
    WHAT WE CAN DO:

    View Slide

  221. Embrace the fluid nature
    of the web.
    WHAT WE CAN DO:

    View Slide

  222. We don’t plan well for the
    addition of new content.
    THE PROBLEM:

    View Slide

  223. View Slide

  224. View Slide

  225. Design Modularly.
    WHAT WE CAN DO:

    View Slide

  226. Stack content.
    WHAT WE CAN DO:

    View Slide

  227. View Slide

  228. View Slide

  229. Others?
    THE PROBLEM:

    View Slide

  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

    View Slide

  231. Congratulations!
    You have made the first 

    step in letting go!

    View Slide

  232. Description here
    http://eepurl.com/bj0QSL

    View Slide

  233. THANKS!

    View Slide