Frontend United: Etching wireframes & agile UX

Etching
wireframes
& Agile UX
@royscholten, 2013
Monday, April 15, 13

Design process
Many sessions have been about with how to build something.
Today, I'd like to talk a bit about what you can do to ﬁnd out *what* to build in the ﬁrst place.
Because it doesn't matter how lean and agile your continuous delivery is if you don't start
from an understanding of the problem you are trying to solve
How do you get to that understanding?
That's where the design process comes in. Because design is how it works.

User needs
Business goals
Technology
Before we dive into the process part, lets establish the domain we're working in.
The interaction or user experience designer looks for the overlap between
- business goals
- user needs
- technological constraints

User needs
Business goals
Technology
Only where those three meet there is a chance for a viable product or service
So that’s the playing ﬁeld established.
Now for the process bit…

P.I.S.A.
I studied illustration at the art academy.
One course was called concept development.
It thought a method for generating creative work and drawing it to a conclusion of some
sorts.
It was very abstract…

P.I.S.A.
Problem
Inventory
Selection
Arbitration
This is what it stood for.
We basically got two weeks to work on each stage.
- ﬁnd an interesting problem
- generate multiple ways to solve it
- choose the best option
- improve that and ‘ship’ it, make it presentable.
I’d like to show how I apply this pattern to 3 different but related kinds of creative work

ART
Hi, my name is Roy. I’m an artist.

I make prints. Mostly abstract etchings and monoprints

This is the working environment

User needs
Business goals
Technology
This is the domain.
Let’s go over PISA

Problem?
Me.
This makes it simple. I’m always around me
This makes it hard. Using your own ideas and perspectives to create something.

Inventory
Free experimentation.
Generate lots of material
So ﬁnding an interesting problem in itself requires that I generate stuff.
It’s mandatory to create a lot of waste here.

Etching is where you etch an image into a zinc or copper plate. This allows for multiple prints
from one original
Monoprint comes down to applying ink to anything that will go through the press. Most of
the times this material is brittle and so you can only create only one unique image

Inventory! produce a lot of material

Selection
What’s looking
interesting, surprising,
promising?
Review a body of work to discover trends, relations and identify an area to hone in on

- This is why painters walk back and squint
- This is what happens when you say "lets take a step back"
- Pick a direction and create another inventory of options but this time focussed around the
chosen direction
you look at all the stuff together

Isolate some pieces to see if they can live up to being presented as is

For this particular round of work. I selected these two pieces.
Not because the overall images were the strongest

But there was a certain quality in the detail that I wanted to pursue further, get a grip on this
particular kind of visual language

Arbitration
Reproduce the happy
accidents in a more
controlled way
So where these were mostly monoprints, the non-reproducible technique.
I wanted to ﬁnd a way to capture this on zinc, and apply this to the zinc plate

You cover a polished plate in ground
Remove and apply it again.
It’s very similar to using layer masks in photoshop.

So, applying this to multiple plates, a body of work is generated that once again has to be
reviewed, selected, reordered.
It’s iterative!
And then there comes the moment where it’s time to draw your conclusions and pick the
works that you want to show.

So where this was the starting point for this particular series of sprints.

It resulted in these works.
This is the etched wireframe one

It’s really fun and interesting to have this

Drupal UX
Hi, my name is yoroy. I’m a Drupal core contributor, working on a more usable Drupal

User needs
Business goals
Technology
You could say that in core UX, this is where we work on things

Problems?
No shortage of Drupal
usability problems…
Drupal UX problems?
- Just how serious the issues were became clear in 2008, when two proper usability lab tests
were done on Drupal 6.
- Dries wrote a blog post about not releasing Drupal 7 before 90% of the most serious issues
were ﬁxed.
- I helped organize a usability sprint at Drupalcon Szeged and you could say that that's where
we bootstrapped Drupal UX team.
So, how do we work within core development to redesign and improve parts of the user
interface?

Problem?
Content creation UX not
good enough.
Make it better!
Having a well defined idea of what you'd like to see fixed is key.
Pick your battles. Drupal is huge, don't try to boil the ocean.
Pick a self-contained part of the user interface and get a clear idea of what you want to fix
and what not.
A critical audience is all the content creators and editors
Those people that get to use Drupal content creation forms weekly or even daily, long after
you’ve delivered the project.
Where this used to be a decision made by IT,
These people have a strong influence on which system to use

Simple example. Some serious problems with even a simple version of a content form
- no clear hierarchy to the overall page
- essential options are hidden from immediate view
- people do not know if ‘Save’ means it will be published or not.

Inventory, I
What do we have now?
What are the others doing?
What is contrib doing?
http://groups.drupal.org/node/214898
So we have an interesting problem to crack. Relatively contained problem. Improvements will
have a big impact on general perception of Drupal usability.
So, again, we do the inventory
1, 2, 3

(switch to ﬁrefox)
its important to show your research, you need better foundations for your designs than ‘i like
it that way’

Inventory, II
Sketch!
The best way to get a good idea is to have many ideas
- This is the part where some developers get really nervous!
- Sketching is deliberately open-ended, literally sketchy: vague, half-deﬁned.
- Post your ideas and allow for feedback

Throw out rough ideas. Create multiple options
We had Skype meetings to review our ideas and point out promising areas, problematic
ariesas

Selection
Review & decide
Continue in hi-ﬁ
(Photoshop!)
It makes sense to timebox things a bit.
There comes a moment where you realize that you won’t be coming up with anything new
(for now)

yes photoshop. It’s not an option to dive in and write up the patch that implements this
design in a quick and easy way.
Photoshop is still usefull in those cases where you want to get an idea of what the page as a
whole comes across
Couple of iterations here as well. Exploring particular details.
(switch to ﬁrefox)

Arbitration
Take it to the issue queue
for implementation
Wrap up the design phase, time to bring it to the issue queue
- Create a brief, reference all the prior research and art, outline what you want to see built.
- Ideally, kick it off with a patch
- Developers love patches, it's their source material and gives them something to play around
with and brings things into their domain of expertise
- It can all still totally go off the rails, core issue queues often deﬁne the limits of what core
devs see happening on d.o.
- Usability test if necessary
- From then on, it's mostly monitoring the discussion to maintain momentum, help deciding
on additional issues and generally try to keep things on track
(SWITCH TO FIREFOX)

Wunderroot
Hi. My name is Roy Scholten and I’m a user experience architect at Wunderroot Belgium.
I joined Wunderroot because I want to be there where the rubber meets the road.

User needs
Business goals
Technology
So we've established multiple times that we can do better than producing static wireframes,
mocking up detailed designs in photoshop and the like.
We need to be more agile! Lean! reduce waste and focus on providing Business value asap.
What can you do to help your clients discover the sweet spot?

Agile UX
P. Business & user goals
I. Sketch scenarios
S. Review and select
A. Prototype & Usability test
This is the format I’m applying these days to uncover what we need to build in order to best
help cleints

Problem?
Day 1:
Business objectives
User needs: persona
(recruit test participants)

Inventory
Day 2:
Sketch screens in the
scenarios

Selection
Day 3:
Review all ideas
Get stakeholder feedback
Decide what to prototype

Arbitration, I
Day 4:
Build the prototype

Justinmind.com

Arbitration, II
Day 5:
Usability test
5 participants

roy.scholten@wunderkraut.com
Roy Scholten
Contact

Frontend United: Etching wireframes & agile UX

More Related Content

Similar to Frontend United: Etching wireframes & agile UX (20)

Recently uploaded (20)

Frontend United: Etching wireframes & agile UX