RAPID UI DEVELOPMENT FOR WEB APPS


Jon Lay & Matthew Lenzi


FIRST, A LITTLE ABOUT US

and why we work like this...


We are a distributed team based in London, Norway, and Russia.

Most of our clients are remote, too.

So we use lots of web apps and communication tools to make this process work.

BUILD IT BETTER

  • Transparent - involve clients at every point
  • Lean - build faster + get better feedback
  • Iterative - use this feedback better
  • Ship - do it sooner
  • Repeat

Rapid != Fast



It's about getting to your destination in the shortest period of time.

Why Process?


Design = problem solving

Rapid = Strategic

Unearthing problems quickly

HOW IT STARTS

Tony sends us an email...

"Hello, Hanno! I want to build a new website for Frontenders in Valencia, called FrontendBook. It'll be just like Facebook! How much would this cost?"

STEP 1:

GETTING TO KNOW TONY


  1. Who is he?
  2. What does he 'really' want?
  3. Timescale
  4. Budget




  • Talk about the project
  • Teach him about the process
  • Find out about his vision for the app.
  • Get the budget and timeframe

MAKE SURE THE FIT IS RIGHT


A collaborative process: it requires committed product owners who will give good feedback.

The client needs to understand, and agree to this.

BE PREPARED TO SAY NO


Not all clients are prepared for this process.

Some are too big.

If you're not comfortable with the client, just say no.

SO...

Tony is happy, and understands his role in the project.

Let's take things to the next stage.

STEP 2:

IDENTIFY THE PROJECT FEATURES


  • Which are most important
  • Which of them would be nice, but aren't essential

    PLAN A PRODUCT ROADMAP


    1. The Core
    2. Iteration 2
    3. Icebox

    We use Trello


    The Core

    First iteration features: essential functionality and elements.

    Prioritised by the client

    An MVP product.

    Iteration 2

    Planning desirable, effective but non-essential features.

    Not necessary for the first iteration app.

    Potentially implemented through effective use of budget.

    Icebox

    Features that might be great in the future, but right now, would weaken the core app.

    Keep clients focused and keep development on-track.

    So let's see how it works...

    https://trello.com/board/fbk-frontendbook-roadmap/51ac9da8411c61033b003856

    WHERE ARE WE AT?

    ✔ Client is happy

    ✔ Roadmap is approved

    STEP 3: BUILD IT!

    But, where do we start?

    Where to start?

    • Build core functionality first
    • Don't waste time on the basics - leave these till last
    • Build quicklyexplore, get feedback.

    Which pages are important for FrontendBook?

    https://trello.com/board/fbk-frontendbook-build/51b90105f6115f5558002c43

    OUR TOOLS:

    A Frontend Framework

    Twitter Bootstrap vs. Zurb Foundation

     

    Why use a framework?

    • Quicker to build prototypes
    • Quicker to experiment with UI components
    • Clean, generic design - help clients to focus on structure

    Which one?

    • It doesn't matter which one you choose
    • But to prototype quicker, you need to know it well
    • More experience with a framework = quicker prototyping

    Why not use both?

    We use:

    Foundation
    For most projects.
    Especially if they need to be responsive.

    Bootstrap
    We use it less often.
    For control panels and complex web apps.

    Why Foundation?

    • More design flexibility - easier to design on top
    • It's mobile first
    • Most importantly, we can build faster with it.


    A very rough first step

    Building the Single Event Page for the next Frontenders VLC event.

    Let's jump into the prototype for a few minutes...


    Working transparently and collaborating with your client


    1. Build the page
    2. Commit & push to git repo
    3. Automatically deploy to development server
    4. Get feedback!

    Automate Deployments

    • Use post-commit hooks
    • DRY: Don't repeat yourself
    • Automate the process, so you can build quicker!

    We automate with

    DeployHQ.com


    Collecting Feedback

    1. Specific feedback
    2. General feedback

    Specific Feedback

    BugHerd.com


    General feedback

    Trello


    Basically, Hanno <3 Trello

    Build → Get Feedback → Iterate

    Let's jump back into the prototype to see how it works...

    STEP 4:
    LAYERING THE STYLE


    • As the app's structure becomes clear, we can look at styling
    • Style is layered on top of structure
    • Styling is iterated too


    Efficient time to look at visuals

    Visuals in the context of the structure

      Creating a common visual language

        Designing Identity

        Translating client vision

        Steering vision into focus

          The Style Tiles

          exploration, navigation, discovery


          Evolution of Moodboarding

          Assembling a visual tool kit


          Opportunity to:

          reinforce design objectives

          validate assumptions

          Here's a quick moodboard example...

          App style and UI elements


          Interactions


          It's not a one-way street

          Style Tiles and Moodboards often give us creative ideas for app functionality.

          This is why we do both at the same time.

          STEP 5:
          ITERATE UNTIL YOU SHIP

          Keep going until the client is happy.

          Ship it, and gather data

          Then iterate more.

          Nothing beats real user feedback.

          Build it better


          @jon_lay and @teolenzi


          wearehanno.com
          @wearehanno

          Rapid UI Development for Web Apps

          By Jon Lay

          Rapid UI Development for Web Apps

          We spoke at Frontenders VLC (http://valencia.frontenders.me/) on 13th June 2013 about the process we've put together to help build web apps rapidly and get clients more engaged in the process.

          • 2,343
          Loading comments...