The bane of my life when trying to work out what’s gone wrong with a search engine is the hidden thesaurus.
Lots of search software comes with a thesaurus that is referred to ‘behind the scenes’ to expand queries to include other queries that are *known to be equivalent*. Anyone who has spent even a short amount of time thinking about language can see why these things might become a problem.
(these files are doubly irritating as they’re usually set up without any kind of admin interface…the assumption being only the system administrator would or should edit it…and that they will of course be technical)
The expansion happens behind the scenes and the user isn’t necessarily told it has happened. This is usually bad. You need to be really really wary of expanding the users search queries without telling them. Don’t just give them results for aubergine and results for eggplant, when they only searched for Aubergine. You think you are being clever and helpful. If you’re wrong about the expansion then you are just being extremely irritating.
Or possibly worse than irritating.
I read a comment on the Guardian recently that suggested hor = mum in Danish. I thought that was wrong and searched for “hor mum” in Google. It wasn’t my most thought through search query but I didn’t expect Google to automatically convert it into “hot mum”. That was a bit of a surprising set of results.
(the word the commenter had misheard was mor)
This Google example demonstrates how you can end up with a worse situation that the user simply not getting the results they were looking for. But it is also different from the thesaurus examples that I started this talking about. Google do at least tell you what they’ve done and allow you to correct them. Given how uncertain query expansion is, best practice must be to tell the users what you’ve done.
If you tell the users you have two choices about how to tell them:
a) Suggest the expansion but don’t run it for them. Risks them missing it as an option.
b) Run the expansion but tell them you’ve done it. Still risks them missing the option to un-do
Google’s experimented with both approaches over the years. And currently has a bit of a mixed approach. Don’t assume their approach has “cracked” the problem.
I’ve been doing quite a bit of surveying in recent weeks and I’ve been challenged over my liking for free-text fields.
My colleague/partner-in-crime was worried that the data would be too time-consuming to analyse if we didn’t turn every field into a tick box of some form. I’ve always found the free-text fields to be the ones that contain the most interesting responses so I’m willing to wade through the data.
But it wasn’t just on our side of the fence that concerns where raised. In the latest batch of responses to the survey a couple of people wrote things along the lines “why not checkboxes?” in the field in question.
(of course, if it had been checkboxes, the people who’d wanted free text wouldn’t have been able to complain to me)
An unexpected benefit of the free-text field was that I could spot the spam because they faithfully quoted our navigation back at us when asked what parts of our website they read. The humans were mostly more varied than that.
The question was about what Guardian content they read. It was deliberately vague but most people interpreted as a request for genres and listed out four or five of them. It wouldn’t have been a huge problem to have offered them the main genres and asked them to tick. It would have probably involved a little less thinking for the respondents.
I suspect people would have ticked more things if offered a list.
What I wouldn’t have got was the things that people thought were important but we hadn’t thought important enough to put on the list. A lot of people chose something surprising as one of the four or five things they specifically chose to tell us they read.
As well lots of the expected genres, the responses also included:
- specific topics and countries
- things they don’t read
- how they choose what to read
- who they read
- which supplements they like
They used language we don’t use e.g. Current affairs, Entertainment, International, Global, Arts, Finance, Opinion, Economics, Sports, IT.
I was also interested to see people using Guardian specific acronyms e.g. OBO, MBM, CiF.
Most people responded with a comma separated list which was pretty easy to turn into structured data and then just mop up the stuff that doesn’t fit nicely by hand. And that mopping up gave me an opportunity to learn the data and to begin to understand it.
This wasn’t a big scientific piece of market research, just the beginning of a conversation. And that’s best done without checkboxes.
As a classification geek, married to a tree geek I was delighted to discover treen which Wikipedia says is “a generic name for small handmade functional household objects made of wood”.
I may start collecting miscellaneous categories from different domains…
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.
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.”
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.”
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?