ia play

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

SharePoint search allows you to create Best Bets. They can be created by the Site Collection administrator.

If you go to Site Settings, you should see ‘Search Keywords’ under the Site Collection Administration heading.  If you don’t see it you probably haven’t got the right permissions.

You create a keyword, associate some synonyms with it and then add one or more Best Bet links. You can set it to expire and/or be reviewed.

Keyword: The search term that will generate the Best Bets and also is displayed above the Best Bet e.g. PenFriend

Synonym: Other search terms that will also generate the Best Bet. These aren’t displayed e.g. Pen Friend

Best Bets: The editorially picked search result e.g. Penfriend Audio Labeller

I can’t for the life of me figure out how to delete a keyword (Best Bet, yes. Keyword, no). Maybe it’s a permission thing again.

This article is part of a series about our e-commerce redesign.

Analysing your search referrals only tells you about the traffic you were successful in attracting. Even if you are getting lots of traffic for a particular keyword that might be a tiny fraction of the number of people searching for that keyword. And the referrers says nothing about what you missed out on completely.

So it helps to look at search engine traffic for keywords in the kind of space your website sits in. The free tools like Google AdWords keyword tool have generated lots of debate about how useful they are but I tend to see them as worth a look if you’re just looking for rough ideas about language and relative popularity.

With our shop research, I didn’t get much data for easy to see, easy to read, giant print, big print, canes, liquid level indicators, and (my favourite) bumpons. I couldn’t find information about Moon (the alphabet) because it was drowned by references to the satellite and all the other things called moon.

What I’ve learnt:

Generally people refer to concrete properties of the product rather than their condition. So it is ‘big button phone’ rather than ‘easy to see phone’ or ‘low vision phone’.

Singular is much more important than plural for objects like clocks and watches but the opposite is true for book formats e.g large print books. Which is kind of obvious…you only want one watch but you may want many books. This might have a bit of effect on our labelling policy, but not much as Google doesn’t seem to make a huge deal about singular verus plural.

There’s clearly a big opportunity around low vision products. The interest in products for blind people (like Braille) is less significant, which makes perfect sense when you compare the size of the audiences.

And loads of people are interested in magnifiers.

SharePoint search features are managed at 3 levels

1. Farm level (configure the search service, configure crawler timeout settings etc…)
2. SSP (Shared Services Provider) level
3. Site collection level

The SSP functions are accessed via the Shared Services Administration.

SSP search functions:

• add sources to the crawl
• block URLs and URL patterns from the crawl
• define crawl schedules
• inspect crawl logs and troubleshoot crawls
• emergency removal of items
• install IFilters to support non-default file types
• add/remove file types from the crawl
• specify authoritative pages
• create scopes for all site collections (you can also create at a site collection level)

And in theory specify noise words and create a custom thesaurus.  See Inside the Index and Search Engines
chapter 5 for more.

You can by default index these types of content source:

• SharePoint sites
• Non-SharePoint websites
• Windows file shares
• Microsoft Exchange Server public folders (you can index exchange mailboxes with a 3rd party add-on)

Crawl management:

• Full crawl: indexes all content
• Incremental crawl: only accesses content that has been updated since last crawl. Faster, but slow if  accessing an external website
• Crawl schedules can be specified for each content source
• Crawls should be scheduled for low usage times

Crawl rules

• content can be excluded by defining a rule
• rules are applied in the specified order so you usually need to move exclude rules in front of include rules.
• a URL can be excluded by adding it as an exclude rule
• URL patterns can also be excluded and help keep the management of rules neat e.g. http://www.bbc.co.uk/* or http://www.amazon.co.uk/*/dp/*
• Exclude rules will remove any matched URLs during the next crawl
• If you need to remove a URL in an emergency you do this via “Search Result Removal” instead

Resources elsewhere:
Introduction to SharePoint Search Indexes for DPM Administrators
Enterprise Search administration

I haven’t really mentioned the knowledge management aspect of my team and my role much. And as we’re putting that area of work to one side for a while it now seems a bit remiss.

So first some organisational context:

The RNIB is a charity for blind and partially sighted people. By partially sighted we mean sight problems that cannot be corrected with glasses or other solutions. This covers more people than you think.

The charity also employs a number of blind and partially sighted people and this changes the organisational environment. There are a lot of guide dogs for a start. There are guide dog toilets and there are water bowls in the meeting rooms. There are guide dogs in the lifts rolling their eyes at you, guide dogs lying under the meeting room tables and yawning loudly when you make a boring point, and guide dogs under people’s desk vomiting in the floor boxes and causing power cuts. Seriously.

It is inevitably a very verbal culture. You won’t see whiteboards in all the meeting rooms and powerpoint presentations are unusual. There are quite a lot of conference calls, this is something that comes easier to this organisation. But we also employ deaf staff so you have to think very careful about how you are planning to communicate.

It is a large organisation with a multi million pound budget and a few thousand employees. This is pretty big in charity terms, but not colossal.

The RNIB is involved a vast array of activities. It campaigns and fundraises but it also provides lots of services to blind and partially sighted individuals; library services; physical and online shops selling all sorts of gadgets and aids; emotional support; employment services; schools; colleges; care homes. We work with all sorts of industries to make them more accessible; from audio description of Bollywood films, accessible JK Rowling websites; to more user friendly shower design. Sadly we are not responsible for guide dogs.

The management team became aware that like many organisations of their size and diversity that they could probably share information and knowledge a bit differently. They probably didn’t think much about formal distinctions between those two terms (it is a very special kind of person who does and they’ll probably be thinking about  a pyramid). They also decided to build a knowledge management team within the IT department, which may or may not tell you something about what they thought the solution might be. It might have just been a convenient spot on the org chart.

Our team was not exclusively about knowledge management. There was myself (the IA), a knowledge facilitator and a knowledge support officer. Then there is a team of IT project managers and a team of business analysts. The team sat quite happily together; we’re all examining the way of the organisation currently works, helping to prioritise and improve processes going forward and generally bringing more conscious process to the way the RNIB operates.

From a knowledge management perspective, we ran a knowledge sharing consultation where we interviewed individuals from around organisation and asked them about the information they needed, who they needed to share with and what problems they encountered. From this the knowledge sharing strategy was developed to address four key issues; organisational culture; intranet findability; finding people; problems with storing and sharing documents.

Some of the proposed solutions were IT based but others were merely changes in the ways of working. Embedding information sharing into job descriptions and appraisals, faciliating workshops and lessons learnt sessions.

A big piece of work was around setting up communities of practice; groups to share ways of working and advice. The cultural resistance in some areas was surprising to me. Some employees couldn’t see the value of meeting their peers without a concrete piece of work to deliver. Others were concerned that the groups were not reporting to a director. Some managers were uncomfortable with this being a bottom-up initiatives. And many teams simply didn’t have the travel funding to send their members to meetings.

The IT based solutions revolved around a new SharePoint intranet. This incorporated a new people finder and also private collaboration spaces. But IT solutions were not limited to the intranet and many investigations showed that problems could be resolved with a shared drive and better network speeds. IT solutions can be very expensive, not least because the RNIB has to ensure all systems are accessible to staff and beneficiaries which can be a challenge, particularly with enterprise software.

Investigations also showed that some requests for IT systems were attempts to solve problems that couldn’t be solved with technology. Where staff were resistant to a current system, it was clear that a simple replacement wouldn’t remove any of the issues.

The key lesson for us has been not to take requests at face value. Often we’ve had to keep digging  and then choose the appropriate solution even if it isn’t the sexiest option. Often the cheaper human approaches can bring greater benefits than massive IT projects.

I’ve been working with a few new IAs recently, all hoping to get their first jobs.

Some common themes have come out of those conversations about things they need to learn or prepare, in order to get that job.

1. A portfolio, showing a range of UX activities

Mostly people know they need to do this. And even more frequently they are concerned that they don’t have enough material or enough worthy material.

Often you’ll be asked to bring a portfolio to interview. It’s worth bringing even if not asked as you may need to illustrate your answers to questions.

Make sure the portfolio covers a full range of UX activities. Even if you haven’t got professional experience doing user interviews, producing wireframes and running usability tests, you need to find a way to get something in your portfolio to demonstrate what you know. That might be academic projects, volunteering/work experience, or stuff you’ve done purely for your own development. These *may* not be rated as highly as professional experience but they are far far better than having nothing to show.

(don’t be afraid to re-do documentation as you learn more)

2. Ability to do test UX exercises

Increasingly employers will set you an IA/UX activity to complete either before the interview or on the day. Typically you’ll get a brief describing the problem and you’ll need to describe the steps/methods you’d use, propose at least a partial solution and maybe some documentation.

So you need to understand the methodology and what tools are used when and why. Don’t over agonise about the solution you propose – just make sure you show your thinking and where you’ve had to make assumptions. Also don’t over-do the detail of the documentation – if you’ve already got high fidelity wireframes in your portfolio then it may be just as effective to do sketches and very rough documentation for this “think-piece”.

3. Experience with the software

Entry level IA/UX jobs often involve taking on a lot of the effort of producing the documentation from your senior colleagues. Often what is needed at the junior level is not about what makes a successful experienced IA. Whilst employers are looking for evidence of creative UX thinking and the potential to become one of their superstars, they also want someone who can contribute in some way whilst learning and developing.

Many junior roles will inherit a set of complex wireframes in the organisation’s preferred software (Visio, Axure, Omnigraffle, Illustrator and so on) and so the preference is for someone who can hit the ground running.

The software isn’t cheap, so can be difficult to skill up in if you don’t already have access to it. Trial versions are available for some and it’s worthwhile getting these and spending some concentrated time learning how to use them and producing some deliverables.

It’s also worth finding out about the strengths and weaknesses of each package for producing UX documentation. You might get asked.

4. Knowledge of the basic design patterns

In the UX field the stated emphasis is on user research and new creative designs. In reality a lot of designs are primarily composed of reasonably standard design patterns.

You need to know these. You need to know the ordinary but basically effective patterns for navigation, search, article pages, video and so on. Norms are probably more established in web publishing and e-commerce than social media and mobile design.

You might have a great and innovative idea for doing things differently. But you need to show you understand where you are innovating from (at least in most conventional recruitment scenarios).

So explore published pattern libraries, create your own for your organisation, or just collect your favourites.

The error reads “Etsy server is meditating. Our server may be experiencing momentary personal introspection”.

I am a bit obsessed by ‘when recommendations go wrong’ scenarios like the JustRabbitHutches incident.

iPlayer hasn’t done anything that silly, but it does seem to struggle with the recommendation concept. They sit particularly uneasily alongside the new Favourites functionality.

When the latest incarnation was in beta, I was quite excited by the prospect of favourite programmes and categories functionality. This had the potential to meet some of the needs that the absence of sophisticated browse function left. If I could tailor the content more then I’d need to browse less.

But the new site makes surprisingly little use of the favourites functionality. After you’ve put the effort into setting your favourites, it pretty much ignores all the work you’ve put in.

The favourite programmes bar is always closed. The favourite categories are similarly always closed. The radio stations box doesn’t remember your selection.

The homepage is dominated by four sections: Featured; For You; Most Popular; and Friends. None of these areas seem to be influenced by your own preferences.

Featured is rarely of interest to me but I get the editorial need to have some promo space.

For You is where the recommendations kick in but at least initially I had no idea what this section was supposed to be doing. A good design pattern is to explain recommendations ala Amazon and to let you know if there is anything you can do to make the suggestions better.

Most Popular is ok for me. Occasionally my interests overlap with the majority and then this spot is useful. Friends might be occasionally interesting, although “a people like you like” might have been more valuable. It seems a bit odd for the area to persist if you don’t login/specify any friends.

All these sections are potentially useful but the best predictor of my interests is my interests. It seems that in this design My Favourites and My Categories are given lower emphasis than *everything* else.

This is compounded by the presence of the For You section. As another commentator put it:

“why on earth would the site suggest I watch Eastenders? It’s been on TV for over 25 years and I’ve never once felt inclined to watch it, so what intuitive masterstroke has been developed to think that I may now wish to start?”.

Once you give recommendations personal labels like “For You” then people start to take your recommendations personally.

I’m annoyed that I told iPlayer what I like and it still insists on telling me that BBC 3 sitcoms are “for you!”. It’s started reminding me of my grandad and that’s not a flattering comparison.

As a  general principle it is best not to go overboard on defining SharePoint content types. They add power to information retrieval but also add content creation overheads. Keep the number of types reasonable and also the number of metadata fields. (Obviously the art is defining what ‘reasonable’ means)

A list of reasons to define a specific content type:

• you want to attach a document template for that content type
• there’s a standard workflow for that content type
• there’s a standard info policy for that content type
• you want properties of the content type to be possible to search through advanced search
• you want to restrict a search to that content type
• you want to be able to sort a list or library by a specific metadata field of the content type
• you want to categorise a list or library by a specific metadata field of the content type

See also Microsoft’s Managing enterprise metadata with content types

The classic usability complaint is that projects just tack a usability test on at the end of development when it is too late to make any changes. Which leaves the usability consultant in the uneviable position of having to tell the project team that their product doesn’t work, when they can’t do anything about it.  It can feel like a waste of time and money.

In reality these sessions are rarely entirely useless and I’d prefer to run them rather than having nothing at all. A lot of feedback is often about content which can usually be changed at the last minute.  You can also capture general customer research insights that can feed into the next project.

A couple of projects I’ve got involved with recently have involved late stage usability testing . We need to tackle this but we’ve got some bigger challenges than usual in bringing in a better approach to usability testing.

1. The organisation can’t afford rounds of testing

This is hardly unique to us and I fully expected this when I took the job. The answer usually involves the word “guerrilla” at some point.

2. We have some challenges in doing guerrilla testing

Our target audience (blind and partially sighted people)  is a small section of the population and can’t easily be found by popping into libraries and coffee shops. Everybody else really isn’t representative and would give completely different results. Although admittedly our target audience can often be found in our own offices, or rather in the public resource centre downstairs. But you can’t just get them to test on your laptop as you need to have the access tech that they are used to using. We might need to try and find folks who are both willing to test and also use the access tech we have available. Not insurmountable problems, but will take a bit of planning.

3. Can’t easily do paper-based testing or flat onscreen mock-ups.

I’ve mentioned this particular challenge before. We can survey and interview quite easily. We can test existing or competitor systems. But when it comes to trying out how well new designs are working, our options get a lot fewer. Whilst it would be interesting to experiment with tactile mock-ups, the admin overheads and learning curve probably aren’t justified.  Really we should just concentrate on working prototypes, rather than getting carried away with how cool an IA presentation idea “tactile wireframes” is.