Session Notes: Lean UX @ BostonPHP

Presented by: Jeff Gothelf, the Ladders

Principal at Proof, @jboogie, jeff@proof-nyc.com

Lean UX is one solution to the Agile problem

  • Focus on delivery, not deliverables (build SOMETHING)
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Lean Startup

  • Every startup is a grand experiment that attempts to answer a question: not “CAN I build it,” but “SHOULD I build it?”
  • How do you spend the least amount of time designing/building the wrong thing?
  • Steps:
    • Formulate concept and create minimum level of fidelity to communicate and validate
    • Validate internally: stakeholders, developers, other designers, etc.
    • Prototype: get something out quickly so you can get it in front of customers or proxy customers
    • Test externally: get someone in front of your prototype and see what happens; is it usable? Is it USEFUL?
    • Learn from user behavior
    • Iterate
  • Designers need to step from behind their monitors and show early work much earlier and more often

First five things you need to do in order to make Lean UX happen:

  • Solve the problem together; don’t implement someone else’s solution
    • Bring the team you’re working with further into the process
    • Involve them in ideation and problem solving
    • Build shared understanding, which relieves the focus on deliverables
    • Let people know why certain decisions are being made
    • There’s no reason a developer can’t contribute to the design phase of a product and vice versa
  • Sketch
    • Remember, you’re not DRAWING; you’re sketching ideas together
    • If you can draw a circle, a square and a triangle, you can draw every interface that exists.
    • Work together on sketching and iterating, then work in parallel to build the thing
    • By working together, you don’t need to document things because you’ve already talked about it
  • Prototyping
    • Get your experience out, not the document
    • Validate hypothesis
    • What is the fastest way to get something into peoples’ hands that helps communicate the concept and its usefulness?
      • Axure
      • Straight into code
      • Other prototyping frameworks
  • Pair up cross-functionally
    • designer with developer
    • builds a common language and trust between the pair
    • makes the team more efficient
    • “design in the browser”
    • helps develop working code really quickly
  • Style guides are ESSENTIAL
    • could also be pattern or component libraries
    • make it a living document
    • make accessible to the entire team
    • button styles and logic
    • color palettes
    • default values for drop down menus
    • add code assets where applicable
    • helps the team put things together more quickly over time; assets can be grabbed and “dropped in” to a prototype
  • Critique early and often on designs that don’t feel “finished”
    • Designers have trained their clients to believe that the first thing they see will always be beautiful and “right”
    • NOBODY gets it right the first time, and nobody else is expected to.
    • It’s about getting concepts out early, and moving towards the “right” solution based on validated learning
  • It’s not the “Spec” that gives control
    • Lead with conversation, trail with documentation
    • designers are there to lead and facilitate the design process
  • Keep everyone moving forward
    • Provide team members with insight into the design process
    • Build momentum and engagement
    • Build shared understanding

How to manage quality vs. speed

  • “Speed first, aesthetics second” — Jason Fried, 37Signals
  • “It’s not iterative if you only do it once”
  • Iterations mean quality continually improves.
  • Move from minimally viable (simply works) to minimally desirable (works well, looks good, people want it)
  • Once you’ve validated your concepts, demo to the team
    • get them started building on a parallel path while you work on exception cases

Everything you put out into the world is a hypothesis. Your goal is to validate that hypothesis as quickly as possible and learn from the results.

  • Lean UX builds user testing into every sprint cycle
  • Don’t build things that people don’t want
  • Use data to settle subjective issues
    • A/B testing
    • Qualitative testing (user testing, etc.)
    • Use qualitative data to find out what people prefer; use A/B testing to validate that they prefer it.
  • Fill in the gaps through shared understanding
    • the more you talk about it, the better people understand why decisions were made, and more easily they can put the pieces together.
    • allows for estimation and prioritization within the flow of the building the project
  • Form factor is ultimately irrelevant
    • Many ways to test hypothesis
    • Testing doesn’t have to be expensive
    • Proto.io

Lean UX is NOT

  • Lazy. You still have to work hard, perhaps even more than what you did before
    • Collaboration level is significantly increased
    • What’s being removed is the WASTE that comes from the traditional UX process
    • Using the right tool at the right time
  • Design by committee
    • Yes, you’re involving other people, but it’s the DESIGNER’s job to synthesize that info into a concrete design

Getting started: in-house

  • Start small on an internal project
  • Ask for forgiveness
  • As you build camaraderie and start seeing results, others will start to notice and build interest
  • You are in the business of solving problems; you don’t solve problems with design documentation

Getting started: startups

  • This is the way to go, particularly in B2C

Getting started: interactive services/agency world

  • It’s a tougher sell, because agencies are in the deliverables business.
  • Give your clients the power. They like that.
    • Concept
    • Validate with client
    • Iterate
    • Validate with client
    • Prototype
    • Learn from user behavior
  • Can you get to the clients’ customers, or a similar proxy?
  • Gives clients the ability to see their “fingerprints” in the work; increases ownership.
  • Prevents “seagull management” — “swoop in and poop on it” — they can’t blame the agency anymore
  • Builds a more collaborative, less adversarial, relationship with clients

Getting started: Consultants

  • Consultants are mini-agencies

Distributed teams

Considerations

  • With content heavy experiences, some up front planning is necessary
    • Must understand what those content blocks will be, where they come from, and what they’ll contain
  • Highly experiential consumer sites may suffer under lean; hard to gauge experience with a usability test
  • Letting people into the design process makes them realize that design is HARD
  • Designers must evolve in order to stay relevant

 

Session Notes: Tapping into the power of user narratives [Drupalcon 2012]

Presenter: Michael Keara, MyPlanet

What is a user interface systems architect?

  • equal parts listener and software developer
  • Listens to users and finds pain points
  • Understands software and how to build the technology
  • Focus: how to bridge the gap between the two.

Two doors:

  • The user happy place, where they understand the user interface they’re dealing with
  • The development environment, where people need to understand how to make the system work
  • Opening both doors opens new conversations, and leads to new insight

Three UX Fundamentals

  • Usability is a lack of suffering on the part of the user
  • Usage context: Functionality has no meaning outside of a usage context
  • Primary questions:
    • Who is the user?
    • What are their tasks?
    • These are “simple” questions, but very difficult to answer.

Case study: a registration system for music exams in US and Canada

  • Two websites, two separate usage context
  • Examinations are key to their business model
    • Registration must be easy
    • Multiple types of users involved in the system
  • Design and testing
    • Started with “pilot” for US school
    • Prototyped the solution in a rich HTML prototype, then created a testable site
    • In user testing, discovered:
      • Structural issues: how to improve the location and function of key components
      • “Language” issues: issues around the language being used to navigate around

User narratives:

  • Role-oriented UX design
    • Is about supplying the right tools at the right time
    • Don’t throw all the tools the user will ever need into one space
    • Provides a way to trace the path from end user to the engineer
    • Roles = a set of tasks
    • Tasks require specific elements on the screen to facilitate completion
    • Has an impact on:
      • Layoute
      • Information Architecture
      • Data Retrieval
      • Data Structure
    • Connecting the dots
      • Handle idioms/terminology used
        • Different cultures have different terms they’re used to
      • Handle roles (mindsets and usage contexts)
        • Student
        • Parent
        • Teacher
      • Applications and tools try to mimic mindsets, but it doesn’t always work out
      • Role-oriented designs handle mindsets comfortably
  • idioms (language beyond “language”)
    • Unfamiliar terms don’t fit
    • Generic terms have rough edges; don’t resonate
    • Familiar terms are comfortable; help achieve “invisibility.”
  • Real-life narratives
    • Life is a sequence of roles, and those roles need tools
      • I’m a cook at breakfast {stove, toaster}
      • I’m a commuter {train, car}
      • I’m an emailer {computer or smartphone, fingers for typing}
      • I’m a [insert role here]
  • How words get to the screen
    • String: set of words that arrives on the screen
    • We all have words that resonate with us in terms of different roles, tasks, mindsets
    • Thoughts come in clusters; so do the words that describe those thoughts
    • Drupal thinks of strings individually and not in clusters
  • Drupal excludes UX designers
    • Drupal defines “roles” differently (as a set of permissions that’s fixed depending on roles)
    • Doesn’t support the ability to express things idiomatically
  • Organization of words for UX
    • Strings have two lives:
      • The ones the user can’t see (internal code)
      • External ‘user’ strings (human names, what users see)
      • Code strings should never change unless there’s some kind of functional change intended by the developer
      • User strings should adapt to users
    • All of the strings (user, internal code) exist in code!
    • The t() function handles user-facing language
      • You can find them and change them, but not to role or idiom-based terms
      • Translation (from English to German, etc.) is there, but not when thinking in terms of different idioms within the same language
  • Inclusive alternative approach
    • Have to go beyond the t() function to fix this issue
    • Extract the user-facing strings from the code using semantic keys
      • ‘name’=>$sm->t(‘LABEL_BLOG’)
      • $_string_array = array ( ‘LABEL_BLOG’) => “Blog entry”
      • Role oriented key: $sm->t(‘LABEL_BLOG__’.$role)
      • $_string_array = array ( ‘LABEL_BLOG’) => “Blog entry” LABEL_BLOG__STUDENT’ => “student’s blog entry”
    • Do this through the user narratives module
      • It’s about organizing strings
      • Takes a custom “adapter” module (uses form API) and routes it through the user narratives module into a different place that the uX designer can evaluate and change to accommodate new needs/mindsets

Session notes: Designing for Media platforms [Drupalcon 2012]

Presenters: Dave Leonard and Samantha Warren, Phase II Technology

What does it mean to design for media?

  • Designing for a site that is meant to reach a large audience with a daily content cycle
    • Newspapers
    • high-traffic blogs, etc.
  • What makes it different is the sheer amount of information
    • Photos
    • Videos
    • Lots of body copy
    • Organizing lots of information in a way that works for the user
    • ADVERTISING
  • Designing for a frequent publishing cycle
    • How do you design for content creators?

Case studies

  • Take Part
    • Digital media organization and cause services agency that provides content, products and services that inspire, empower, and ignite people to take daily action in making the world better.
    • Visual Design goals
      • Exhibit great storytelling
      • Compel users to take action, get involved in the community
      • Promote sharing: make sure the content doesn’t just live on that site, but belongs to the entire internet
    • UX Goals
      • Take action in the context of a story
      • Support the ebb and flow of topics
      • Make sure that editors have a good UX too!
        • Too many designers don’t take into account the process that editors have to deal with; focus too heavily on end users.
    • Visual Design process:
      • Conduct interviews with stakeholders about their brand and needs
      • Thematic Analysis: find adjectives
        • Engaging, action-oriented, personality
        • usable, present, depth, spacious
        • circulate, community, editorial, content focused
      • Use style tiles to help establish visual priorities
        • Offer one that’s “specifically what they’re looking for”
        • But also offer ideas that speak to the adjectives and themes you’re hearing.
    • UX Process
      • Content strategy
        • Types of content
        • Clasification/tagging
        • Embeddable content types: Put one node in the body of another node
        • Curation requirements: What are the requirements for analyzing and curating content? Are there expiration dates?
        • Curation capacity: What staff and other resources do you have to manage the requirements?
        • Campaigns of varying scale
      • Pair wireframing
        • Flush out misinterpretations early
          • How much fidelity do we really need?
          • Are we being over-specific?
        • Minimize revision cycles
          • Style tiles are done concurrently with wireframes
          • No conflict between UX and visual designer
        • Avoid over-designing
  • Washington Examiner
    • Regional newspaper that covers news, politics and sports in the DC area. The logo was created by William Randolph Hurst and it has a rich patriotic brand.
      • Visual Design goals
        • Feel modern
        • Stay true to history of the brand: wide and loyal readership
        • Promote ease of use: Readability is major; need content to shine through
      • UX Goals
        • Demonstrate breadth and depth of coverage
          • Section based
          • Cover a lot of local news for DC metro area, but also very respected nationally for political coverage
          • Set hierarchy; not all sections are the same
        • Promote top-quality curated content
          • Provided challenges in image handling
          • Challenges in creating hierarchy and ratios
        • Showcase the talent they have in house
          • Challenge: many sources of content coming into the system
            • Feeds
            • Direct to Drupal
            • Imports from AP
          • Need to define how authors are treated depending on where content is coming from
      • Visual Design Process
        • Adjectives:
          • Local, political, regional
          • Opinionated, scrappy, speedy, focused
          • ease of use, decluttered, visual balance, simplified,
          • polished, clean, fresh
          • Flexible, dynamic, Interactive
        • Had done a smaller site project beforehand; had some data on what the client liked and didn’t from the first site.
        • Work elements of the paper (print edition) within the website.
      • UX Design process
        • Sketch session: group brainstorming of UX concepts for a project
          • Got the entire team involved
          • Timeboxed to an hour
          • HAND-DRAWN sketches
          • Come up with ideas, no matter how “crazy”
          • Alleviates the “where do I start?” feeling
        • Wireframes were more high-fidelity because of the collaboration
          • heavily annotation of wireframes to make notes of interactivity, content, etc.
  • Common themes
    • Design a system, not individual pages
      • Clients think in terms of pages; it’s really easy for designers to think of things in pages as well
      • Because of the way Drupal (and other content management systems) handles media, content, etc. you have to think in systems rather than individual pages
      • Create style guides for clients to use and adapt as the site grows
    • Dealing with the author experience
      • Authors can be Drupal users, or they could be organizations
      • Have to consider how different types of authors will need to be treated or highlighted
    • Cross promotion of content is a common theme when designing for media
      • Want multiple page views
      • Make sure people can see additional or related content
      • Helps users find related info; helps the organization get more views on their content
      • How to distinguish between “articles” and “actions” — what’s the different treatment between requests for action and related articles?
    • Lifecycle of Topic
      • How to build a set of tools that lets editors evolve the content and its treatment/important on their own without needing extra developers
    • Commenting
      • Drupal core commenting vs. Disqus or FB comments
      • How to make things visually consistent with third-party integrations?
    • Advertising
      • Designers often have a fear of advertising; it “ruins the layout”
      • How to make it part of the design, and find subtle ways to make it less obtrusive?
      • You can’t get around the need for advertising; it’s the bread and butter of the media industry
      • part of our work as designers is solving problems, and this is part of it.

Session Notes: UX design for every screen [Drupalcon 2012]

Presenter: Aaron Stanush, Four Kitchens

How 4kitchens has been doing websites for the past decade:

  • Requirements and planning
  • Site maps, user flows, wireframes
  • Comps
  • Implementation

The new way:

  • Requirements/planning
  • Content strategy (mobile first!)
  • Design systems > Comps
    • You can’t spend time doing comps for every single device anymore; it’s not an effective use of your time.
  • Prototyping is KEY
    • You can leverage design systems within prototypes to enhance the mobile experience.
  • Build. Design. Iterate. Design. Build. Iterate.

Major changes:

  • There is no more “page”
    • Layout/template are consistent across devices
  • Comps are no longer golden
    • Don’t need one for every single page/screen
  • Elements are no longer static—they adapt to different devices
  • Prototyping happens much earlier in the process
    • Helps define the vision; helps client get it sooner
  • Designer and developers working closer together
  • Higher level of client communication
    • Some clients are skeptical, think there’s too much risk involved.

THE PLAN:

  • Future-friendly
    • http://futurefriend.ly
    • We don’t know what will be on the market 2–3 years from now;
    • want to provide advice and design that’s going to be sustainable.
  • Mobile-first
    • Luke W’s book: Mobile first (available on A Book Apart)
    • Focus on three things:
      • Growth = opportunity
      • Constraints = focus
        • Screens have different sizes, different needs
      • Capabilities = innovation
        • Tap the capabilities of the phone—GPS, location, etc.
    • “Designing the mobile app first forced us to strip down to the essentials”—Bill DeRouchey, Banksimple
      • Focusing on app first carried the focus of the project into the rest of the experience
  • User-first is content-first; THEN you worry about mobile strategy.

“Mobile Web”

  • Most clients seem to think folks are on mobile devices “on the go”—grocery store, bus stop, etc.
  • But honestly, that’s not true; people are spending more time on their phones, more time on the site through that medium
  • Mark Boulton: “Start designing from the content out, rather than the canvas in.”

Future friendly content

  • What are the types of content and why?
    • Video?
    • Text?
    • How will it be broken up?
  • Make it modular
    • Drupal makes this easy; you can leverage fields, etc.
  • What’s really important?
    • If something goes away, will users care?
    • If something gets smaller, will that change/decrease value?
  • How will the tool you’re using organize this stuff?
    • Drupal gives you flexibility to organize content in multiple ways.
  • Page tables give hierarchies
    • Title
    • Message
    • Secondary Messages
  • Design strategy
    • Workflows aim for best user experience; focus on task/behavior, not layout
      • Responsive is about providing the best experience, particularly when you focus on content.
      • These experiences can differ between devices; desktop may contain more information; mobile can contain more FOCUSED content.
    • Wireframes can help organize layout and convey content flow
      • Still needed
      • Focus on content, flow
    • Design systems save time, create patterns
      • Styletil.es (@samanthatoy)
        • Using texture, fonts, etc. to capture feeling
      • Build style guides/pattern libraries
      • Comps are probably still needed, but not for every page in every viewport.
        • ICANN: Created 3 comps, for 3 different viewports, AFTER creating and iterating style tiles.
      • Goal: get the design to the browser QUICKLY.
    • Prototypes help the team fail faster, to facilitate better solutions.
      • Provide client value; help them “get it” sooner.
      • We’re focused on much more complex problems now.
      • Clients can get really focused on comps; the browser is where the responsive magic really happens.
      • A “living” design allows richer convos between devs and designers.
        • Developers can talk about content flow and other design decisions
        • Designers have to understand more about how things will actually be built.
      • Fail fast. SUCCEED fast.
        • Agile/Lean
        • All about iteration and letting the team direct changes.
  • Best practices = Best experience
    • Not about convention; it’s about creating the best experience for users.
    • mobilewebbestpractices.com—library of best practices for mobile devices
    • Understand how people use their devices and why
    • Content > navigation
      • Users on mobile are generally coming in through a link; they don’t necessarily care about navigation.
    • Best experience doesn’t necessarily mean limiting choices
      • Stripping the experience down to just links/text isn’t the best experience
      • Users spend more time on their phones than you think; particularly reading.
    • Maintain clarity and focus
  • What makes a good experience?
    • Readable (font size, spacing, contrast)
    • Relevant (most valuable content first)
    • Keep forms to a minimum unless you’re dealing with commerce, surveys, etc.
    • Avoid modal overlays (lightbox, ads, etc.)
    • Make it snappy
      • People want to do stuff, and they want to do it fast
      • Performance management (reduce the amount of time for loading)
      • Get people to the content quickly
  • Layout
    • Design for screens, not devices = Breakpoints
      • You really can’t focus just on iPhones anymore; Android, Windows phone, etc. is growing
    • Be fluid, liquid, flexible
      • Think in proportions, NOT pixels
        • aligns with content strategy; focus on hierarchy
        • aids in fluid grid management
      • Think scale in media, text, images
    • Consider device orientation
    • lukew.com/ff/entry.asp?1514: Looked at a bunch of different mobile-to-desktop layouts; identified patterns for responsive layouts
    • Navigation
      • Starbucks changed their navigation; took a risk on an icon-only navigation with drop down box.
      • Don’t try to make drop downs a work of art; the OS takes care of things in their own way.
      • Put fixed toolbars at the top rather than the bottom.
        • The bottom is where the OS puts its hardware buttons; you don’t want users accidentally clicking the hardware buttons.
      • Consider OS and hardware buttons.
    • Responsive Images
      • How do your images scale for various widths and orientations?
      • Reduce the # of images if you can.
        • Not everyone has super-fast phones!
      • Be careful of using HUGE images
    • Mobile text
      • Make it readable
      • Consider text flow; long headlines might not scale well on smaller viewports
      • Be aware of typeface characteristics
        • Tall, skinny?
        • Short, fat?
        • Test performance with mobile devices; make sure that loading fonts isn’t slowing things down
    • Gestures
      • Buttons are a hack: they’re basically styled links.
        • globalmoxie.com/blog/buttons-inspired-ui-hack.shtml
      • Make gestures obvious.
        • Don’t make your users read a manual
        • There’s no such thing as “hover” on a touch site.
      • Do use visual cues like coach marks.
      • There is a need for universal conventions
        • Current conventions: tap and swipe (pull down?)
        • Consider competing OS/Browser gestures
        • Provide alternatives to gestures
          • All devices aren’t yet touch-enabled
      • Design for humans; embrace the physicality of touch
      • Size elements and space them appropriately
        • rule of thumb: size touch elements at about 40px
        • Remember: not every device is touch-enabled
    • Tools
      • Software isn’t necessarily the answer
      • Start with pen and paper
      • Fluid grids
        • Goldengridsystem.com
        • Github.com/davatron5000/Foldy960
        • csswizardry.com/fluid-grids
        • gridsetapp.com (coming soon from Mark Boulton)
      • Wireframing/prototyping
        • Whiteboard!
        • Pen/Paper
        • Axure
        • Balsamiq
        • Boston Globe used InDesign
          • handles both images and text
          • Can create patterns with paragraph/character styles
      • Responsive media
        • Images
        • Slideshows
        • Videos (fitvidjs.com—takes any embedded video and scales proportionately)
        • Text (fittextjs.com)
        • filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing
        • markboulton.co.uk/journal/comments/responsive-advertising
      • Media queries
        • @media screen and (max-device-width: 480px) { .column { float: none; }}
        • Media type: screen (desktop, phone, tablet)
        • Query for media feature: width, height, orientation, pixel density
      • Prototype frameworks
        • foundation.zurb.com
        • twitter.github.com/bootstrap
        • goldilocksapproach.com
        • html5boilerplate.com/mobile
      • Touch frameworks
        • jquerymobile.com: can create something that looks like an iPhone app within a browser
        • sencha.com
      • Test on REAL DEVICES
        • blackberry
        • Windows phone
        • Kindle fire, iPad2
        • Galaxy tab, etc.
      • Adobe Shadow: labs.adobe.com/technologies/shadow
        • Runs in the background, and has an extension on FF/Chrome
        • Make sure your devices are on the same wifi network; then you can browse on desktop and it shows up on all your devices.
      • Browserstack.com
        • will emulate any number of browsers inside one website
        • Just started adding mobile VMs.
          • Won’t get the same fidelity as an actual device, but you can get a general overview
        • Subscription is pretty cheap.
      • Blaze.io/mobile
        • tests mobile performance
        • Gives load time and other factors
      • mattkersley.com/responsive
        • Type in different websites, and it’ll show you how it looks in different browser widths.

Session Notes, Sessions 7–9: Agile UX Summit, 2/25/12

Anders Ramsay: Learning to play UX Rugby

  • Feeding the beast
    • Whole team of devs and they’re building shit faster than I can design it
  • Half-baked UX
    • PO’s under pressure to deliver the next release and signing off on crap
  • Sprint-tunnel vision
    • Yes, we delivered all the features we were supposed to deliver this sprint, but the design is an incoherent mess!
  • Why the dysfunction?
    • Playing the old waterfall game on an Agile playing field without knowing it.
    • Lacking the thinking tools to understand how the Agile game is played.
      • Scrum is not an acronym; it’s related to rugby.
      • “stop running the relay race, and take up rugby.”
  • Relay race
    • Team members run alone
    • Collaboration isn’t built into the game; the baton is handed to the next person
  • Rugby game
    • Intensive and continuous collaboration is core to the game
    • Reach the goal line again and again to win the game
  • Rugby in design
    • Team communication
      • Workshops, not meetings
      • Intensive passing game across roles/perspectives
      • Iterating towards shared understanding
      • Move away towards “debugging,” more towards a collaboration-centered design process
    • Collaboration-centered design
      • Shift towards facilitation as a core skill set
      • Cardstorming
      • Collaborative Chartering
      • Dot-voting
      • Story mapping
      • Card sorting
    • Ideation clearinghouse
      • Capturing the imagined final product.
      • Complete in an hour or less
      • There is a tremendous cost to not knowing what’s in the head of your project’s stakeholders (i.e. cutting off the project because you didn’t “get the vision”)
      • Step 1: Set focus/boundaries for the workshop
      • Step 2: Do a warm up; introduce people to the raw materials
        • 4-5 minute time window
        • Write every feature you expect on a separate sticky
        • Becomes a feature palette for sketching
      • Step 3: Sketching timebox
        • Give 5 minutes
        • Ensure safety; it’s okay if you “can’t draw”
        • Everyone in the room sketches SOMETHING
        • Sketch individually
        • No rules — someone wants to write text, they can
        • Clarify that this is research, NOT design.
      • Step 4: Critique
        • 2-min round-robin where people explain the vision/design
        • Take careful notes, attach to respective sketches
        • Look for and work to resolve differences in vision among stakeholders
    • Designing with workshops
      • Learn, apply and recombine workshop patterns
      • Cardstorming + dot-voting + sketching, etc.
    • Pairing
      • an intensive one-on-one passing game
      • Continuous problem debugging and knowledge distribution
      • One person “drives” and the other “navigates”
      • Use to debug and fix code in a continuous and collaborative way.
      • Change partners each day
    • Cross-functional pairing
      • Designing in multiple dimensions at the same time
      • Better collaboration means less/lighter documentation
      • Move from whiteboarding/sketches straight to building things together.
      • Developers can help with the transition from talking about building to actually building
      • Each medium/perspective informs the other
      • Move from wireframes to building the structure to HTML/CSS in a simultaneous process.

Todd Zaki Warfel: The Design Studio Method

  • Borne out of architecture and Industrial design
  • Three phases (charette):
    • Create: generate and prototype the concept
    • Pitch: presenting the design concept
    • Critique: talking about the design concept
  • Approach: 6.8.5
  • Tools:
    • Butcher paper
    • Sharpies (rougher feel; it’s about generating ideas)
    • Personas
    • Design challenge/scenarios
    • Templates, e.g. 6-up or 1-up grids
    • STOPWATCH
  • Teams should be CROSS-FUNCTIONAL. Represent 3 viewpoints:
    • Design side
    • Business side
    • Development side
  • Each team gets a different persona, and ONLY focuses on their persona for the duration of the studio
  • Design studio kicks off the design process
  • Step 1: Create
    • Create 6-8 concept sketches individually, within 5 minutes
    • Give templates with 6-8 blocks (like a storyboard) with grids and space for notes
    • Either storyboard a flow, or use the time to sketch multiple approaches to the same screen
    • Don’t forget a warmup session
    • Use paper and pencil to get people out of their element/comfort zone
    • Don’t worry about details; just get the elements down
    • Goal: get just enough of the concept on the page to be able to pitch your idea to the team
    • Don’t create more than you can pitch in 3 minutes
  • Step 2: Pitch
    • Put all sketches on the wall with personas, “inspiration gallery”
    • Everyone gets 3 minutes to pitch their idea:
      • What did you intend to achieve?
      • How does your idea achieve that goal?
  • Step 3: Critique
    • While someone’s pitching their concept, nobody is allowed to speak.
    • Once the 3 minutes is over, team gets 2 minutes to critique the concepts.
    • This is NOT feedback, i.e. “I don’t like this” or “I like this.”
    • Critique based on the goals for the design: where it achieved or failed to achieve the goals.
      • 2-3 ways it achieves the goals, EVEN IF YOU HATE IT (green markers)
      • 1-2 ways it can be improved upon, EVEN IF YOU LOVE IT (red markers)
  • Step 4: take feedback and iterate on designs
    • Stealing is highly encouraged; if another team does something you love, steal it and make it better.
  • Benefits
    • Generate two weeks of work in less than six hours (420 different design concepts)
    • Instant buy-in from team members: since team members help create the designs, they’re already buying into the concepts
    • Get team members to own and invest in the concepts
    • Engineers said their estimates on time were 50% more accurate
    • Having five minutes as a rule means you don’t have time to worry about it; just execute
    • Everyone gets to vet concepts as they go: it’s not as good as usability testing, but the benefit is that only the strongest concepts survive

Jonathan Berger, Code Literacy for Lean Teams

  • Coding as literacy
    • gets rid of the binary nature of “you can code or you can’t”
    • If you work in technology, the medium is power
    • “I can get this code to work or not” can be frustrating to those just learning
  • LITERACY DOES NOT EQUAL FLUENCY
    • Just because you can code doesn’t mean you’ll be good at it
    • Getting technical doesn’t have to be a full time commitment
    • Many resources available (books, sites, tutorials, etc.) are geared towards people who want to be full timers
  • More and more shops won’t hire designers who can’t code.
  • How does code literacy help lean teams?
    • More literacy leads to more sustainable projects and more successful outcomes
    • Fine details are important, but often get shoved to the wayside by devs moving on quickly to the next feature
    • There’s a whole class of things that are easier/less time consuming to do than to explain
    • Being able to fix details yourself saves the developers time,
    • Gives team more hands on deck, fewer bottlenecks
    • Builds camaraderie
  • How does it hurt?
    • Time/cost in learning curve
    • Potential for overstepping bounds (humility is important)
    • Harder to look at things with an “innocent” eye (i.e. without thinking about how it can be made)
    • Tunnel vision in devs can skew priorities towards problems that are “easy” to fix
    • DON’T LET CODE OVERSHADOW DESIGN
  • Ways to become literate
    • Use in browser mockups (HTML/CSS/JQuery)
    • Use Inspector (Chrome) or Firebug (Firefox) to inspect and change elements, then import changes into code mockups
    • Align product/development/design
    • Set up a local dev environment (e.g. MAMP, Rails)
    • Get started with Git
      • Designers can contribute small changes, e.g. copy or CSS, and push to production without interrupting the developers’ workflow
      • You can make the fixes that matter to you but aren’t crucial to the developers
      • Watch out for breaking tests (e.g. when copy is changed)
    • Learn JQuery & the DOM
      • Make better mockups—directly in the browser
      • Make more changes for the team
    • Learn the language your team is developing in—PHP, Rails, Drupal, etc.