Don’t get lost in solutioneering When you’re asked to build a solution to a given problem. First, Make sure the problem is well defined and that the right questions are being asked.
You gotta have a process, right?
So, I attended art academy, studying illustration. During art academy we were tought a class called “ Concept development’
Let’s take a look at some of the documents designers might produce in order to document their design.
Helpful in getting the main hierarchies in place You’ve probably noticed yourself that a site map often gives a good idea about the taxonomies, vocabularies and terms you’ll want to use as well. So a very useful tool, every one can read it, and defines scope of navigation pretty well. But, to me, Below level 1, 2, maybe 3 it starts to get tricky, It’s not really about explicit hierarchy anymore, On those levels, content is more often connected through context , not hierarchy. And that’s where you’ll hit the limits of what a site map can do here. You’d need ever larger screens and paper A similar problem exist in the fine art of origami
Step by step instructions don’t scale very well for complex designs. For complex origami designs, you’d need 100+ step instructions. That’s unmanagable. So, how did they solve that problem in origami?
They show just the crease pattern of the folded - and - unfolded again design. Experienced origami practicioners can read this diagram and fold this design from just this pattern
With a crease pattern and a picture of the end result, all the steps in between are not needed. Pretty advanced yes, only readable by expert folders. Now, If the site map is similar to the step by step instructions, A step by step, or level for level, map of what’s in there. Then what is the UX design deliverable that matches this ‘exploded’ view of an origami design?
Concept models. A concept model maps out all the objects and their relations in your app. Concept models are great. Where site maps show a map of the information architecture, A concept model maps out the different interactions that exist in the system.
So, concept models are useful for mapping out your application. How does it do that? 1. List the nouns 2. Map them out 3. Define the connections using verbs.
Concept maps are quite high-level but can be very enlightning. This is one I did for Views 2, somewhere during the first half of the development cycle. It took a lot of talking back and forth before we got to this level of abstraction, But it proved to be a key graphic that did a good job at explaining the concepts that were being built.
The bride stripped bare by her bachelors, even. By Marcel Duchamp. One of the most influential and mystereous works of art of the 20th century.
Another well known design document: the wireframe. Where site maps and concept modules try to map out the scope of your entire site / application, Wireframes pull all elements together that live together on a single page.
Working with Drupal, you’ll easily see how wireframes map out regions, blocks and content areas.
Lo fi for on the spot discussion, inside the team Try out variations! Hi fi for communicating to stakeholders But, beware. Wireframes easily get you locked into this ‘page’ paradigm. Especially with web apps, the concept of a ‘page’ doesn’t really hold up. For every two pages, there’s a transition between the two as well, And paying attention to this transition is at least as important as the screens them selves.
But, Back to PISA, These deliverables are all PROTOTYPES These happen during the ‘S’ in PISA: you select 3 of the best ideas and prototype them Thing is, as we just saw a bit with the wireframes: there’s a risk that your design thinking is keeping literally INSIDE the box that is a Page So what about the ‘I’? Making the inventory?
The design deliverables we just saw are actually still too high in fidelity, too much work basically for the inventory phase. There’s a very specific technique for this.
It’s called sketching! This drawing is not really the kind of sketch that we’ll be discussing here, but there’s a few interesting things about this particular artist. (anyone know who this is?) This is Albrecht D ürer, a German renaissance painter and print maker, working around the year 1500 and onward, That’s from the same period as Michelangelo, Leonardo and those other two teenage mutant hero turtles. Interesting thing 1: He’s one of the first ones to draw self portraits. He’s one of the first ones that started signing his work (see the little A, D up top) Before that, in the Middle Ages, the individual wasn’t that important, the church was the Microsoft of the time basically. And the church was the institution that artist worked for. Interesting thing 2: Durer even signed his sketches. So, quite an ego. And decidely not very open source, what with putting his little logo on all his output. But the point here is that by the end of his life he said something like “ A great artist can make a much more meaningfull work on a little scrap of paper than a lesser artist could ever achieve on a much bigger canvas.‘ For the UX design discussion we’re having here, the take away is that regardless of fidelity / medium / level of detail, the best ideas often start life as a little scribble on a little piece of paper. As designers, and especially as designers in the open (source) world, we need to get comfortable with getting our sketches out there. Design is iterative and open-ended as well, not as closed and controlled as it’s sometimes made out to be Opening up the process of searching, trying, failing, SKETCHING towards a proposed solution should be helpful in getting others follow your reasoning and build support for your ideas.
We need more sketching happening. Before diving into wireframing, sitemapping, concept modelling, Be sure to sketch. A lot. What is a sketch: Quick: you can make it fast Timely: you can make it here and now Cheap: so you don’t get too attached to it. Disposable: It shouldn’t hurt to throw them away. Plentiful: more than one, seen together. So that they can feed of eachother. Refined: don’t make a pixel perfect mockup during the beginning stages. Also, a little doodle on a post-it note probably doesn’t cut it further down the project.
But opening up the sketching process also asks something of the observer: Just like a developer might say ‘patches welcome’… Instead of critiqueing or reviewing ideas offeredup during sketch phase, it should be more something like ‘sketches welcome’. Because I’m seeing the ‘bikeshedding’ verb tossed around more and more. I’d like that to stop. What I’m seeing when people call a certain discussion a bikeshed discussion, Is people feeling uncomfortable with having an ‘anything goes’ design phase The explicit goal of the sketching phase is to get as much different approaches out there. You’ll need to get the few standard answers out of your head and on paper. First diverge (I in PISA) Then converge: S in PISA First sketch, then select and prototype.
See graphpaper: concepts
Skitch rocks. It’’s very quick, It’s timely and cheap But more importantly, allows you to document your own process through annotations. This was a dialogue between caroltron, sam boyer and me, talking about Panels ui Look how based on a photo of carol and sam sketchin ui on the whiteboard, How annotations and boxes over it highlight the main concepts And another review in the green ovals. Definately not one to show your clients, but very very helpfull in discussing ideas among peers.
UX sketching, communicating design Roy Scholten | yoroy