ia play

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.

Some tips:

• 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.

Keyboard shortcuts/controls:

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.

Marty Cagan ran a product management workshop for us yesterday and I spent some of this morning reading Inspired: How To Create Products Customers Love. The workshop was based around his top product mistakes.

My background has often blurred the line between product manager and UX person, and I was interested to hear some tension(?) at London IA last month about IAs being perceived as claiming product management territory.

Inspired is mostly a practical, sane book exploring familiar (to me!) problems. It deals with UX a lot and is definitely worth reading if you are working in an environment that has both UX and product manager roles.

Marty suggests (p6) that the right ratio of roles to have is one product with:

• one product manager
• ½ interaction designer/information architect
• ⅛ visual designer
• 5-10 developers

He sees 4 ux roles, which maybe be separate individuals or not (p18)

• interaction design (deep understanding of users, tasks, flows, navigation, wireframes)
• visual design (precise layouts, colours, fonts, emotions)
• rapid prototyping
• usability testing

There’s some supportive stuff about the timing of UX work (p117)

• UX work should be done before implementation,
• using a sprint zero approach, maybe one or two sprints ahead for an agile team.
• need to give UX team some (but not loads) of time and space to research and design

Some good advice for working in large organisations (p170) and with your manager (p63)

• measure and plan for changes in plans
• conduct the real meeting before the official meeting
• be low-maintenance to your manager (use someone else as your mentor)
• learn how decisions are actually made in your organisation
• do skunk works projects/seek forgiveness not permission
• build relationships before you need them

Other interesting points

• doesn’t recommend outsourcing interaction design because it takes time to develop the deep understanding of the users, they need to be on hand throughout the project and UX is just too core to the business. (p19)
• recommends that Product should be “organizationally on par with engineering and marketing” and that ideally Product should include the UX team (p53)
• recommends high fidelity prototypes as the product spec (p113)
• product manager should attend every usability test (p133)

The Guardian was my first job out of university.  I’m back 10 years later and the office is a whole lot shinier and is also closer to my house. So far, so good.

I’ve been surprised at how pleased I am to be getting back to the media.  I think it’s the culture of trying new things, of  exceptionalism and something about being engaged with the outside world.

But the very, very exciting bit is I get to work with Martin again.

On the downside the dogs in office count is likely to be zero.

Constraints was another topic of conversation in the coffee breaks between The Story sessions. I’m not sure how much it was inspired by the presentations or was just the direction the discussions went in.

At the BBC, our attitude to constraints and their role in design was one of the sources of friction we identified between our (finely defined) UX sub-disciplines. Those with ‘architect’ in their title tended to be very conscious of the constraints. The IAs often spent longer working with particular products and were more likely to be embedded with the product team. They developed a detailed understanding of the content structures, technical systems and the organisational politics around a product. The interaction and visual designers were more likely to work from the design hub with other designers and to work on products for defined projects. They came to projects fresh and unblinkered. Neither situation is wholly good or bad. Both bring insights.

But it did result in the designers feeling that the IAs were too aware of the constraints and were unambitious in pursuing the best solution for the users. Conversely the IAs often felt the designers were being idealistic and naive, and that’d they never get anything built.

(these are broad brush generalisations, there were some great examples of successful partnerships between the teams but there were certainly issues)

In these conversations somebody usually brings up the serenity prayer:

“God grant me the Serenity to accept the things I cannot change, Courage to change the things I can, And Wisdom to know the difference…”

My instincts are often on the side of accepting many of the organisations constraints. I like realistic plans, and I’m aware how deep seated some constraints can be. I don’t see how designs that never see the light of day help the users. But it would be simplistic to say I’m always on the side of conservatism.

In my last team, our troubleshooting explicitly involved dividing problems into ‘change’ and ‘accept’ categories but I surprised myself at how uncomfortable I felt at some of the things that ended up in ‘accept’. I wasn’t happy to just leave them like that.

This all reminded me of a creativity course that I found helpful in accommodating the instincts of both dispositions. One of the techniques the course taught was to explicitly structure ideas generation into phases:

• firstly unshackled ideas generation (everyone is reminded they’ll be able to bring the constraints in at the next step)
• then a step where the ideas are filtered with the constraints. Ideas are divided into do-able now or soon, and ideas that require work to tackle the constraints (which may require another ideas generation session!)

The approach helps me to use both my desire to make things better and my desire to get working stuff out the door. The different types of ideas could be taken forward by different teams but I suspect most of us would be happier if we could accommodate both types of challenge in our our work

The Story was a satisfying and intriguing day out. Chatting to @lynsey_s in a break, we reflected that it felt different to the usual speaking events we get to go to.

(although I’ve not been to much in recent years…my charity days have been focused on very tangible tactical events on topics like RFID and SharePoint).

The eclectism of The Story is often present at web/ux events and many of the topics were familiar but there was something else. There was a continuous sense of being exposed to depth, detail and obsession. these speakers were talking about things they’d been doing for years and years (often every day of those years).

Updated: I think Phil Gyford’s comments about his presentation fit with my impressions:

“It turns out that I need to run a website on a very specialised topic for eight years before I’m in a position to feel confident talking about it.”

http://www.gyford.com/phil/writing/2011/02/20/pimping.php

The Web Strategy Programme of work that I’ve been working on at RNIB has been completed and in the current climate there’s not likely to be big new web projects coming up. So it’s time for something new.

It’s tough times in the sector and it looks like I won’t be replaced with another IA.

I’m probably never going to work in an office quite as purple again.

And it’s really unlikely I’ll work in an office with this many dogs again (and that makes me very, very sad). I’m also disappointed that I won’t see the new online library through to launch.

Things to take away:

• sight loss is something that happens to lots and lots of people as they get older. Accessibility is just as much about partially sighted users.
• don’t do large scale customisations of commercial software (knew this already but seem to need reminding)
• proper lunch breaks, with nice people sat round tables eating nice food are a wonderful thing

A lot of goal setting articles include the assertation that “you overestimate what you can do in a day but underestimate what you can do in a year”.

A similar quote is attributed to Bill Gates:

“We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten.”

via The quotable Bill Gates | Developer World – InfoWorld.

There’s a long view planning technique based on these concepts. It asks you to “Describe your life in the future”:

• 50 years from now
• 25 years from now
• 10 years from now
• 5 years from now
• 1 year from now

I write the descriptions as  prose but I’ve seen this done in a more structured tabular way so that the same topics are covered each time.

50 years is so much time, it makes most things seem achievable. In fact when I’ve done this I usually find I can’t imagine much difference between 25 years and 50 years, as I usually assume I can get my goals sorted in 25 years. 50 years takes me to 82 but my life expectancy is longer than that even without taking scientific/medical advances into account.

Of course, the time points are completely arbitrary, so long as the final point is sufficiently far in the future.

It’s a good activity for planning and prioritising the meaningful stuff, and for when you need an optimism boost. It’s also  useful for “future now” activities. It challenges you to think about making 1 year look a lot more like 50 years.

A slightly uncomfortable but sometime useful variation is to include 100 years time, or after you are dead! How will you die, what will you be remembered for and by who, and what impact will you leave behind?

One of classic IA arguments is about why New Service X shouldn’t be added to the primary site navigation.

Users aren’t *generally* just wandering around the internet going “ooh, what’s that? I have no idea, why don’t I click it and see”. If you just add random new stuff to the primary navigation, the main thing that will happen is it will get ignored as users carry on their journeys to wherever they were already going.

It can work ok for a new product category e.g. groceries but it really isn’t very effective for a new brand or unfamiliar feature e.g. X-PIL.  Combined with a big marketing push it might work, so you can get away with it if you have reason to believe this is going to be a really big new feature e.g. iPlayer *and* you are going to heavily marketing the brand.

1. Ranking

This is the least visible thing, that you might not consider a feature, that mostly gets ignored and is absolutely the most important thing for you to dedicate time to getting right.

If the query isn’t particularly ambiguous then you need the top results to be right, without asking the searcher to do much else.

Ranking isn’t sexy and it takes care and attention. But isn’t magic, it’s just rules. Ask what the rules are. Don’t be fobbed off. If no-one knows, work it out yourself.

2. Manual Suggestions (query expansion/narrowing)

This basically means Best Bets.

I’m very, very attached to Best Bets. This is mostly because I’ve been a search product manager as well as an IA on search re-design projects. Once the project team has packed up, the product manager (or web manager/editor) can still improve results and resolve problems using Best Bets. And they will need to. Promise.

3. Automated Suggestions (query expansion/narrowing)

We can’t spell and we can’t type. And then we blame the poor old search engine when it doesn’t find what we were looking for.

Any decent search solution needs to have some solution to misspellings (where to put them is a problem for another day!). You can do some of this with Best Bets, but with a big and diverse enough set of users you’ll probably need something a bit more automatic like Google’s Did You Mean?

A related but broader concept is suggesting related searches. You might have spelt your query correctly but there’s a similar term that would get you better results. Ask.com used to do this.

It might seem perverse to prioritise the manual intervention over the automated one. I’d usually expect to have both but I have a few reasons for picking manual if it comes to a choice:

• the manual option is probably cheaper to add on if neither comes as standard
• automated suggestions often get better over time but might start a bit ropy
• automated suggestions may be ‘black-box’ you might not be able to do anything with them if they are wrong/misleading. And every system I’ve worked with and/or used makes mistakes sometimes.

It’s worth asking whether there is any control over the automated suggestions. Is there a dictionary? Is the right language (esp. UK v US English)? Can we edit it? How?

4. Filters and sort options (after you got search results)

These tend to get missed by users or interfere with their understanding of the page. Not all users will understand them, especially complex faceted filters. The positioning of filters/facets is very difficult to get right. Users home in on the top results, so above the first result is most likely to get noticed and also most likely to get noticed for being in an annoying position.

If you are doing product search then I’d probably still prioritise 1-3 but I’d strongly argue you need 4 as well.

5. Clever query language

Quote marks seem to be reasonably widely understood, so I might argue these should be higher up your expectation list.

But unless you’ll have access to your users and be able to train them all… I wouldn’t prioritise operators like wildcards, NOT/And/Or etc..

Find out what you get out of the box. Make that information available to interested users. But don’t invest lots of development effort and money here.

6. Filters and sort options (before you run the search)

a) Radio buttons and drop-downs.  These get missed, people don’t think about using them, they tend to just stick words in and hit go. Other users won’t use them because they don’t know they need to use them until they see the search results aren’t focused enough. So then they have to go backwards. So you might as well go with (4).

If you can sensibly default them then they can be more useful but establishing what the sensible default  is problematic.

b) Advanced search pages.
These are basically a collection of filters for the user to set before you run the search. Search specialists inevitably find advanced search useful but your average end-user doesn’t. The exception here is power users  but be sure the users actually are “power” users.  You are likely to find power users where there are time/cost pressures around searching e.g. staff answering customer calls or researchers using databases where they pay for searches. In these situations even reasonably techno-phobic users are motivated to get to grips with advanced searches including some of the more complex query building ones.

Another reason advanced search might be worthwhile is if your power users are also your most mouthy. If the segment of your audience that blogs/tweets is also the segment that might demand power features then you might consider the feature as marketing.

(Don’t be worried by people being intimated by the label “advanced”.  If they are intimated by the word then they’ll be intimated by the features. )