Archive for the ‘deliverables’ Category
When we reviewed job adverts at the BBC to understand how the market was defining the various UX job titles, the unifying part of information architect job descriptions was creating wireframes. It seems to remain the main deliverable IAs get asked to produce.
But ‘wireframe maker’ is a label that pretty much everyone would deny (except in their most maudlin moments) and it hardly covers the breadth or the essence of what we do.
I’ve been relieved to see a designer producing wireframes, as it (might have) indicated a UX style approach to design. But I’d have been upset if they’d told me my job = wire framing so it was probably a bit perverse to be particularly reassured.
It seems at the moment wireframes are being squeezed by sketching on the one side and prototyping on the other (although I’d argue these are part of same tradition rather than a revolution). But still the wireframes get produced.
So what do they prove?
- they show a way of thinking: what things, what relationships, what priority, a below the surface layer way of thinking
- they are a way of communication: one that encourages focus on things+relationship+priorities again, one that helps with building and enables it to begin earlier, and possibly one that invites more collaboration because it says “this isn’t finished”
I don’t think these proofs mean the wireframes are especially necessary, just that these are things that creating wireframes might signify about the person who made them.
I’ve been experimenting with wireframing using Google Drawing. And not entirely because I like making my life hard.
(and yes, I’ve been doing lots and lots of sketching too, so there’s no need for the sketching mafia to scold me)
I’ve started off at the Guardian with a PC but we were a bit uncertain if I would switch to Mac+Omnigraffle. I could have got Visio but as I’m working in an office that uses Google Docs I thought I’d give Google Drawing a go.
The big advantage is that I can share the wireframes with anyone in the office without creating PDFs. We could in theory collaboratively edit them but at the moment we’re still in a world where I produce and the others read. Another advantage is that everyone is always accessing the latest version.
And you never have to save. Drawing does sometimes crash but never when you’ve forgotten to save for the last 30 minutes of intense productivity (I’m looking at you Visio).
Morten has produced some basic wireframes which are a good place to start but as he acknowledges one of the big limitations is the lack of customisable stencils. He gets around this by keeping his shapes in the gutter. I’ve tended towards keeping them in a separate document and then copying them to the web clipboard. For some reason you can’t just copy and paste shapes between documents, you have to use the web clipboard option on the toolbar. Lack of stencils was a real pain getting started but I’ve pretty much adjusted now.
There’s also no layering, which would be a shop-stopper for anyone producing large multi-page specifications, that need to be regularly updated. I don’t do that kind of wireframing very often so this is actually less of big deal for me.
Drawings are single page only. If you want to print, you’ll have to create every page in separate drawing. If printing doesn’t matter so much you can just create multiple wireframes on a very big Google drawing page. Where I’ve been creating a series of wireframes, I’ve created separate drawings in a folder and then just shared the folder with everyone else. This is probably the thing that feels hardest to get around.
Which all sounds pretty awful for keen wireframers but I’ve quite enjoyed it really. It worked best when I was drawing a single new component and then needing to share it quickly and widely.
Drawing is more straightforwardly suited to flows and sitemaps as they are likely to be single page, not need layers, and only use a couple of shapes (probably ones available in the fixed set of stencils).
Oh, and it’s free.
- Objects pasted within the document are pasted on top of the copied object, regardless of where you’ve scrolled to. If pasted from another document then they appear in the position they would have in the original document.
- Keep the text boxes as small as the text allows (other wise you may find it hard to select other ‘smothered’ objects)
- Similarly putting frames or boxes around other object stops you selecting the objects within
- To make the page larger, zoom out so that you have more grey space to drag into.
- You only need to highlight any part of an object to select it.
Move a gridline : Up / Down / Left / Right arrow
Move a pixel : Shift+Up/Down/Left/Right
Move up/down in Z-order : Ctrl+Up/Down
Move object to the Top or bottom : Ctrl+Shift+Up/Down
Group selected objects : Ctrl+G
Ungroup selected objects : Ctrl+Shift+G
Delete and add to clipboard :Ctrl+X
Add selection to clipboard : Ctrl+C
Paste clipboard contents : Ctrl+V
Duplicates selection : Ctrl+D
Delete selection : Delete, Backspace
Smooth drag : Alt/Option while dragging an object.
Restrict to vertical or horizontal dragging : Shift while dragging.
Copy an object : Ctrl + drag the object to copy
Preserve aspect ratio while resizing: Shift while resizing an object.
Rotate in 15 degree increments : Shift while rotating an object.
A recent conversation with a friend generated shock (and even a little scorn) that I’d been producing wireframes. I was firmly entreated to sketch instead. Around the same time a recruiter approached me with information on a job that would require detailed annotated UI specs of around 40 pages every fortnight.
The profession is still judged, by and large, by the quality of our documentation. Most recruiters and hiring managers seem more interested in the quality of annotation than the quality of thinking.
I’m rather inconsistent in my approach to documentation. Mostly the medium is picked for the context. Is the project agile? How good are the developers? Is there a remote team? Do lots of people need to be consulted? What are their reading preferences?
Whilst I’m happier with pen and paper than computer, I think it is far to say that I doodle a good deal more than I sketch. Now there’s always a way to get chickens into a blog post… this little trio were sketched during a conference presentation, presumably a scintilating one and probably about something 2.0 related given the labelling of the fowl.
In fact, it appears I doodle most when irritated by the speaker. In this case , rather than asking an insightful question to highlight the cliched and superficial nature of the argument, I wrote “blog, wisdom of the crowds, whatever”. That told him, I’m sure. I do still want this mug though:
None of this is what my friend had in mind though. She’d like this more: part user journeys, part concept map, but mostly not very pretty. Not really for sharing (apart from with you lot, of course) but it could be re-jigged into something more respectable.
I do these little pages all the time but again they aren’t for collaborative purposes. This one was so I could sanity check we had all the functionality we’d need on the product backlog before the supplier drew up the drawbridge.
Then of course, there’s cheating. Those search forms I shared recently were created in Visio but with the sketchy stencil:
But, horror of horrors, a lot of my documentation these days is actually reasonably high-fidelity mock-ups. These are really aimed at the business stakeholders. Colours and fonts are pretty much fixed by our visibility requirements, so the business units know better than to ask for their favourite shade of puce. And they worry less if they don’t have to try and visualise from wireframes. It doesn’t take me any longer as I’ve got a colour stencil and the choices are pretty limited.
Is this ironic? I’m working for an organisation of and for blind people and I’m producing the most colourful deliverables ever. But then you should see the colour of the office floors.