Blog

[AgileUX Summit] Session Notes: The Design Studio Method

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

[AgileUX Summit] Session Notes: Replacing Requirements with Hypothesis

Josh Seiden: Replacing Requirements with Hypothesis

  • @jseiden; proof-nyc.com
  • Requirements and Hypotheses can both be used to frame the work of teams.
    • REQUIREMENTS: create an Internet Mouse that people can use when surfing the internet on their TV from their couch.
    • HYPOTHESIS: I think people will pay for a device that makes it easier to surf the internet from their couch, and you need to figure out what that might be.
  • For most teams, HYPOTHESES are a more effective way to manage your workload.
    • It's very rare that you're working in a condition of certainty, hypotheses let you operate in uncertainty.
    • Requirements take the THINKING out of implementation; team has no visibility to user/market needs.
  • When you give a team a problem, you engage the team's creativity.
  • But you also need to give the creativity some boundaries, to keep moving the team forward
  • When you are building to an established standard, use requirements; if you're creating something NEW, use hypotheses.
  • Hypothesis = Answer posed as a question; sets up an assumption to be tested.
  • Every design decision is a hypothesis that the market will test for you. If you can reduce the time between the design decision and the market feedback, you can drastically reduce risk.
  • Format of a hypothesis
    • Statement of what you believe to be true: We believe that…
    • A statement about how you'll validate the hypothesis: We'll know we're right when…
    • Example: We believe that people will pay for a device that makes it easier to surf the internet from their living room couches and we'll know we're right when people can use our mockups without trouble and when people offer to pay for what we've built.
  • Process
    • Identify assumptions
      • What assumptions do you have about your customers?
      • That if proven wrong, will cause you to fail?
      • Who are they?
      • How does this product fit into their work or life?
      • What problem does it solve?
      • When and how is it used?
    • Express as hypothesis
    • Test riskiest assumptions FIRST
      • What are the highest risk assumptions that we know the least about? Put those into a backlog.
    • Break them down into testable parts
    • Use MVP concept to test your hypothesis
      • What is the smallest thing we can create to test our hypothesis?
    • Get out of the building: watch people to get feedback.
    • Lather, Rinse, Repeat
  • Use story maps to get all your requirements on one wall

[UXAgile Summit] Session Notes: Learning to play UX Rugby

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.

The Definitive Guide to Drupal 7 is finally here!

Just got word from Ben Melançon that my friend Jacine Luisi now has an actual, printed and bound version of The Definitive Guide to Drupal 7 is now actually in her house. This is the project that I got involved with at the beginning of this year, and it's amazing to finally see it finished. 

If you want to get a copy of the book (written by "many of the best minds in the business" — no, I had nothing to do with that tagline), check out http://definitivedrupal.org/purchase.

Why recipe sites shouldn't be in Flash

Note: This is an entry from August of 2010, but it seemed especially apt, as I've been spending most of my days this week in a frenzy of food preservation. Enjoy.

It is, officially, canning and pickling season. Every year for the last four, I've spent most weekends in August canning a variety of pickles, salsas and other nummies to preserve the massive amount of produce that comes out of New England in late summer. One of my favorite recipes is from Hubert Keller's terrific show on PBS, and it's a sweet pickle with a bunch of different summer veggies. I discovered this one last year and made about a half dozen pints with the last of my farm share. I have yet to bring it somewhere where it doesn't disappear five minutes after it's opened.

Recently, a friend of mine had an abundance of zucchini (like you do) and wondered what to do with it - so I wanted to send her the recipe for Hubert's excellent mixed pickle. I always make it with zucchini, as well as small carrots, radishes, white turnips, pearl onions and cauliflower. Should be easy enough, right?

Unfortunately, Hubert Keller's website is done entirely in Flash.

There are several reasons why this is a phenomenally bad idea. For all the benefits that Flash can bring when well executed, on its best day Flash brings with it three important and tragic flaws:

  1. It forces all of your content into a specific height on the screen, which forces you to use scrollable boxes for any content that is longer than your screen height;
  2. Scrollable boxes in Flash don't behave the way that we're used to online. Rather than being able to use our fingers on the trackpad (for Mac) or the little roller thing on our mouse, you have to actually click on the scrollbar and manually drag it down - a process that is almost always unreliable.
  3. The entire site exists as a single movie - which means (and this is the most important issue) you can't bookmark a single page for later reference.

In practical terms, this meant that, in order to get the recipe for my friend, I had to send her to his site, and tell her to navigate to the PBS show, then Recipes, then scroll down to the episode on Charcuterie, so that she could then download a PDF of the actual recipe.

And, I had to apologize to her for the fact that music would be playing the entire time she was doing this. And the fact that, because it was Flash, there was no way to actually just search for the recipe.

This experience brings me back to a fundamental point - and one that I rant about often. The first questions that should be answered before starting a web project should always be these three:

  1. Who are the people coming to your site?
  2. What are they coming there for?
  3. How are they used to finding that information?

If you don't answer those three questions before you even touch things like what it should look like or what types of functionality you want, this is the kind of thing that happens. And you don't want that to happen.

By the way, should you actually want the recipe, I've shared my adaptation on the recipe blog.

Pages

Subscribe to Blog