ia play

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?

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.

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.

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.

A while back I read The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn’t

Back then I was in daily contact with someone who could have been the inspiration for Sutton’s book. Some of you will have had your ears bent about that delightful situation.

I’m far luckier in my working environment these days. My current boss and colleagues are all pretty much universally supportive, considerate and rational.

Occasionally I still encounter less pleasant folks but they are mostly at arms length which makes them far easier to deal with.  My most recent encounter sent me back to my book shelves to read Sutton’s book.

The book makes a distinction between people who demean others and people who are constructively argumentative and challenging.  Sutton describes two tests for spotting the former:

• Test One: Does the ‘target’ feel oppressed, humiliated, de-energised, or belittled by the person? In particular, does the target feel worse about him or herself?
• Test Two: Is the venom aimed at people who are less powerful rather than at those people who are more powerful?

Sutton argues that the bullies cause obvious damage to their immediate targets but they also damage bystanders, themselves and the organisation.

There’s a good section in the book called “Teach People How to Fight”.

I’ve been struck that through bullying these individuals can control what people do but they can’t control what people keep from them. No-one is going to voluntarily help them out.  People will let them shoot themselves in the foot.

The main memory of my school’s careers advice was an interaction that went something like this:

“You appear to be rather good at science…have you thought about being a scientist? No? How about a science teacher?”

I don’t remember anyone ever suggesting that there were hundreds of thousands of jobs out there that don’t appear in Happy Families.

And the range of generic professions suggested seemed to be based on what subject you were better than your peers at. Enjoyment didn’t come into it.

I was very good at physics and I even found the lessons moderately enjoyable.  But left to my own devices, physics didn’t particularly feature in the way I spent my time (barring a bookish interest in astronomy).

I played with my dog, went swimming, spent a lot of time on the swings, read heaps on books, wrote stories, sketched, painted, cooked, drew maps of fantasy places, drew plans for imaginary buildings and gardens, and made models of buildings and towns.

That stuff made me happy (and it still sounds pretty good today).

Reading that list, it does sound like architecture (the proper kind) would have been a sensible direction. At 15 I did a stint of work experience at an architects practice and I had great fun clambering around building sites and drawing up plans.

The architect got me to draw up a plan for my dream house.  He had a look at how I was getting on and suggested I should be more ambitious because:

“this is the last chance you’ll have to design a house that you actually like”

And that was the end of my career as an architect.

At the heart of his comment was a real problem with careers advice. Even if we can direct children to learn crafts that they will enjoy that doesn’t ensure they will enjoy the day-to-day realities of their work.

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

The browse structure of any website is always controversial within the organisation. I’m always struck by the discrepancy between how interested the organisation is in browse (as opposed to search) and how interested the users are. I’m not saying users don’t want a sensible, intuitive navigation scheme but they also want a really effective search engine. Most web design project involve huge amounts of effort invested in agreeing the navigation and very few discussions of how search will work.

Partly this is because navigation is easy for stakeholders to visualise. We can show them a sitemap and they can instantly see where their content is going to sit. And they know the project team is perfectly capable of changing it if they can twist their arm. With search on the other hand, stakeholders often aren’t sure how they want it to work (until they use it) and they’re not sure if it is possible to change anyway (search being a mysterious technical thing).

Even forgetting search, the focus on navigation is almost always about primary navigation with most stakeholders have very little interest in the cross-links or related journeys. The unspoken assumption is still that the important journey is arriving at the homepage and drilling down the hierarchy.

So I went into the e-commerce project assuming we’d need to spend alot of time consulting around the navigation structure (but knowing that I’d need to make sure I put equal energy into site search, seo and cross-linking, regardless of whether I was getting nagged about it).

A quick glance also showed that the navigation wasn’t going to be simple to put together. Some of my colleagues thought I wasn’t sufficiently worried but I’m used to the pain of categorising big diverse websites or herding cats as Martin puts it. I participated in at least three redesigns of the BBC’s category structure, which endeavours to provide a top-down view of the BBC’s several million pages on topics as diverse as Clifford the Big Red Dog, the War on Terror and Egg Fried Rice.

My new challenge was a simple, user friendly browse structure that would cover a huge book catalogue,  RNIB publications, subscriptions to various services, magazines, and a very diverse product catalogue of mobility aids, cookware, electronics and stationery. And those bumpons, of course.

Card-sorting is usually the IA’s weapon of choice in these circumstances. Now I’ve got my doubts about card-sorting anyway, particularly where you are asking users to sort a large, diverse set of content of which they are only interested in a little bit of it. Card-sorting for bbc.co.uk always came up with a very fair, balanced set of categories but one that didn’t really seem to match what the site was all about. It was too generous to the obscurer and less trafficked bits of the site and didn’t show due respect to the big guns. Users didn’t really use it, probably even the users who’d sorted it that way in the testing. My favourite card-sorting anecdote was the  guy who sorted into two piles “stuff I like” and “stuff I don’t like”. Which I think also alludes to why card-sorting isn’t always successful.

In any case, card-sorting isn’t going to half as simple and cheap when your users can’t see.

We decided to put together our best stab at a structure and create a way for users to browse on screen. Again not just any old prototyping methods is going to work here – however the browse structure was created would need to be readable with a screenreader.  So coded properly.

I wrote some principles for categories and circulated them to the stakeholders. Nothing controversial but it is helpful to agree the ground rules so you can refer back to them when disagreements occur later.

I reviewed the existing structure, which has been shaped over the years by technical constraints and the usual org structure influence.  I also looked at lots of proposed re-categorisations that various teams had worked on. I looked at which items and categories currently performed well. I reviewed the categorisation structures as part of the competitive review.

I basically gathered lots of information. And then stopped. And looked at it for a bit. And wondered what to do next.  Which is also pretty normal for this sort of problem.

(actually one of the things I did at this point was write up the bulk of this blog post – I find it really, really helpful to reset my thinking by writing up what I’m doing)

Somewhat inevitably I got the post-it notes out. I wrote out a post-it for each type of product and laid them out in groups based on similarity (close together for very similiar products and further away as the relationship gets weaker). This is inevitably my sense of similarity but remember this is a first stab to test with users.

Where obvious groups developed I labelled them with a simple word, some like books or toys. If a group needed a more complex label then I broke it up or combined it until I felt I had very simple, easily understood labels (essentially a stab at “basic categories”).

There were too many groupings and there were also a scattering of items that didn’t fit any group (the inevitable miscellaneous group). I dug out the analytics for the shop to see how my grouping compared in terms of traffic. I made sure the busiest groups were kept and the less popular sections got grouped up or subsumed.

This gave me a first draft to share with the business units. Which we argued about. A lot.

I referred everyone back to the principles we’d agreed and the analytics used to make the decisions. Everyone smiled sweetly at me and carried on with the debate.

After some advice from my eminently sensible project manager, I conceded one of the major sticking points. As I reported on Twitter at the time:

“Have given in and allowed the addition of a 13th category. Will the gates of hell open?”

Luckily at this stage we were finally able to do some usability testing with some real users. Only four mind, but they all managed to navigate the site fine and actually said some nice stuff about the categories. One tester even thought there must be more products on the new site, in spite of us cutting the categories by two-thirds.

So if someone attempts to re-open the browse debate, hopefully we can let usability tester #2 have the last word as in her opinion the new shop is…

“very, very clearly divided up”

Enough navigation, time to concentrate on search….

Related posts:
Re-branding miscellaneous

The eagled-eye amongst you (or those with a fondness for the detail of LinkedIn updates) have noticed that my job title has changed.

I’m now officially “Business Analyst/Information Architect”. Yup, there is genuinely a slash in my job title.

Now part of me is genuinely impressed that RNIB is chilled enough about such things. We all get in a lot of tangles trying to come up with one job title that sums up what we do (both to our colleagues and the outside world). That slash is a nice acknowledgement of a messy reality (although you’d probably need to tack another couple of job titles on end before you had an accurate representation of reality).

So why Business Analyst?

1. IA isn’t well understood inside my organisation, outside of my immediate colleagues and unusually the chairman (and before you start, user experience designer would be even less illuminating). People have a reasonably good idea of the space that Business Analysts work in, if not an understanding of the exact details.

2. But more importantly I was already doing business analyst work. A lot of IA/UX training assumes that no BA work has been done, so you start with that before doing the design work. So I naturally did stuff that my BA colleagues recognised as business analysis.

When I did my BA qualification last year, I was struck by how similar the tools and problem spaces are to those in UX world. The cultural context is different so the language used is more business than design, the outputs are less pretty, and there’s often an emphasis on users being staff not customers. Creating such detailed requirements documents was new to me but everything was familiar.

3. There’s more business analysis work that needs doing than there are business analysts. Now you might say that there is surely a lot of IA work that needs doing, and only one IA. And there is. I’ll be putting IA problems on the backburner that need fixing. But I’m comfortable with this because the BA role puts a greater emphasis on ensuring the right problems are being solved, rather than just implementing the chosen problem well.

Again I know there’s plenty of folks who’d say that IA (and UXDers more so) should absolutely be part of the process of picking the problems. That’s fine, you can say that. I’d support you pushing for that to be the case. But the reality on the ground for many IA/UX types is they get told what the project is.

There’s a greater expectation that the business analyst shapes the projects. So for me that route is the fastest way to my destination. And that destination isn’t championing a professional cause. It’s about making sure the money given to the charity is spent well on the people who need it.

This article is part of a (rather drawn-out)  series about our e-commerce redesign.

Competitive reviews do what they say on the tin: they review what your competitors are doing. They are particularly useful in a busy, well-developed marketplace where you can find good matches for your site/product.

With our e-commerce project, my first step was to identify what I meant by competitors. The definition is much wider than other charities for blind and partially sighted people with online shops. You are looking for sites that your audience will be familiar with, with similar product sets, with similar challenges and sites that may be interesting/innovative in general. They don’t have to be all of these things.

Some are easy to identify. If you are looking for market leading commerce facing sites that you can probably reel them off yourself.

You can also:

• ask your colleagues
• ask your network (Twitter is pretty good for this)
• do some Google searches (try searching for all the sites you’ve already thought of, this often brings up other people’s lists)
• look for market reports from Nielsen, Forrester etc…

I then bookmark the websites, using delicious. This means I have quick access to the set as I can reopen all the websites in one go (or in smaller tagged sub-sets) by selecting “open all in tabs” (I think you need the Firefox plugin to do this, I can’t see a way from the main site).

My four main sub-sets for the e-commerce project were

• mainstream shops
• charity shops
• alternative format bookstores
• disability/mobility stores

1. Mainstream shops (link to delicious tag)
These are sites that UK webusers are likely to be familiar with e.g. Amazon, Argos and John Lewis. I chose some for the breadth of their catalogue (a problem we knew we were facing) and some for specific range matches e.g. Phones4U or WHSmiths

Where these sites consistently treat functionality or layout in a particular way, I considered that to be a standard pattern and therefore something the users might well be familiar and comfortable with.

(it is worth noting that we don’t have definitive data on the extent to which RNIB shop customers also use other online shops. On one hand their motivation to use online shopping may be stronger than average UK users as they may face more challenges in physical shops, but on the other hand the accessibility of mainstream shops may discourage them)

2. Charity shops

These sites are slightly less useful as competitors that it might appear at first. They were useful when considering elements like donations but in many cases the shops were targeted at supporters not beneficiaries and they carried much narrower ranges. There are however some very high quality sites where it is clear that a lot of thought, time and effort has been invested.

3. Alternative format bookstores

This included mass market audiobook stores and some that are targetted particularly at people with sight loss. Most of these sites were dated and a little awkward to use. I reviewed them briefly but mostly didn’t return to them.

4. Disability/mobility stores

There are quite a number of these sites. They often feel like print catalogue slung on a website and weren’t very sophisticated from an IA perspective. I did look in detail at the language they used to describe products as there was likely to be a heavy overlap with our product set.

I had a number of initial questions that I wanted to research.
1. The number of categories on the homepage
2. Other elements on the homepage
3. How they handled customer login

I created a spreadsheet and when through the sites one by one, recording what I found. It took me about 2 hours to review 60 sites against this limited set of criteria.

I did the original review ages ago but I went back to the sites reasonably regularly during our design phase, usually when we couldn’t reach agreement and we needed more evidence to help make a decision. Sometimes I would just add a column to an existing spreadsheet e.g. when checking which sites had a separate business login. At other times I created whole new spreadsheets e.g. when auditing how the search function worked.

These later reviews took less time, either because I was checking for less criteria or because I dropped less relevant or low quality sites. I’m still going back to the competitive review even during testing, as various testers start finding their own favourite website and asking “why doesn’t it work like this?”.  It is always useful to know if they are right that “normal” websites do X. The competitive review  saves a lot of argument time.