Because it's about the interactions. (Better UX through prototyping)

Speakers: 
yoroy

This session is about making the shift from documenting a design in static wireframes to prototyping in HTML and from creating screen designs in photoshop to creating a library of design components.

We'll focus not so much on the "how" of frontend tools, but more on the "why" this process works better for all involved.

You'll learn about:

  • What you need to know before you can start prototyping a design
  • Why prototypes are more convincing, engaging and "real" then wireframes
  • How UX, design, frontend and backend can collaborate more closely
  • How to base your (static) HTML prototype on a Drupal base theme
  • What you can do to transform the prototype into a design component library
  • Why this way of working is a better fit for agile teams
Schedule info
Track: 
Frontend
Experience level: 
Advanced
Drupal Version: 
Drupal 7.x
Time slot: 
Thursday · 10:45-11:45
Room: 
G103 · Rackspace

Comments

Drama’s picture

Drama commented

First of all; thank you Roy for doing this session. Given the discussions after the talk I'd say it's a topic that I'm sure will continue to pop up on future 'cons, and for good reason! Below are my $.2 about that discussion:

It seems that from a developer point of view, there is always this notion that if we can't reuse the code produced when the prototype took shape, we've somewhat wasted that effort and duplicate work is needed to get the expected end result. I think this has to do with what preconceptions you have about what the deliverables are from this stage in the project. The thing to realize is that the end goal here is to test ideas, and test them early. The primary take-away is an assurance that the concept is doable and works well, not production-ready .scss or html. In fact, I'd argue that since a fast iteration process is very much preferred at this stage (quickly throwing together and testing different solutions to a given problem), worrying about modularity and performance on a html/css-level at this point would slow that process down considerably. And if you're testing four different scenarios and only keep one in the end, you have three production ready component blocks that you'll just have to leave at the door.

Also, if you happen to be the front-end engineer tasked with building both the prototype and the end site you'll have plenty of ideas and code-concepts already worked out when the prototype is up and running. You can then build on those concepts to produce leaner and meaner production code when you've picked the solution to pursue further.

JurgisG commented

I agree. Otherwise it would be like: why model new car and waste time on it if you should just construct it immediately. Or build a new type of block house without a model, it's just waste of time.. yeah... that would not end good. And for some reason no-one thinks modeling prototype there is waste of time. But each new webpage to a client is unique building - that can collapse if not done properly from the start.

yoroy’s picture

yoroy commented

Thanks for your comment, spot on. It's about validating the concept quickly and effectively. At this stage we explicitly do not focus on producing production ready code or invest time in reusable components because indeed, that woud slow us down. Maybe once we've built up more experience with the process we'll look into this. For now, we intentionally keep the approach simple and relatively rough. The risk is getting so much invested in a single idea that you become reluctant to change it.