ia play

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

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.

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.

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.

My basic librarian-ness is always a bit shocked by finding writing in books. But this is a bit different:

At first I suspected a personally prudish but meticulous scribbler. But there’s a more obvious explanation, of course. This book was used to record a Talking Book, a structured audio book that blind and partially sighted readers use.

Talking Books are recorded in DAISY format, a XML based markup language.

“A DAISY book is a digital audio book, designed to allow you to move around the text as efficiently and flexibly as a print user. You can:

• make bookmarks
• pause books
• speed up or slow down
• read or ignore footnotes
• jump easily from chapter to chapter, heading to heading and page to page.”

Daisy 3 Structure Guidelines, for those that like this sort of thing.

I’ve started work on a project for RNIB Rushton School and Children’s Home.

Rushton provides education, residential care, and therapies  for young people with sight loss, multiple disabilities and complex health needs.

I’m capturing requirements for an information system for the school and home.

Some of the constraints (like complying with the Care Act 2000 and OFSTED inspections) are rather less negiotiable than is usual on my typical IT projects.

And for many of the staff, their daily lives do not revolve around a desk and computer.

It’s interesting stuff and I’m looking forward to getting to know more about how Rushton works (even if that does mean a lot more travel to Coventry!)

Asking about a typical day is always an interesting question to ask in job interviews. All sorts of stuff gets chucked in job descriptions but there’s often no indication of whether that tasks represents something you’ll need to do every day or once a year.

A fairly typical day for me recently went something like this:

9am

Attend our ‘Knowledge cafe’ . This is an informal weekly meeting in a coffee shop with the project managers, business analysts, and knowledge managers. There’s no agenda, just a chance to recharge, share stresses and pass bits of information around. Nice, social and deeply useful.

10am

The rest of the morning is spent doing research, analytics, thinking etc. I might be buried in Google Analytics, auditing competitors, reading up on the technology or messing around with index cards, big bits of paper and a lot of furious hair twirling.

1pm

Meeting with content owners. Listening to them and their experiences/knowledge. Sharing IA insights. I used to find these depressingly familiar battles but I’ve tried to reposition them in my head. I’m not going to learn about IA in these meetings but that doesn’t mean there’s nothing to learn about. Showing interest in the subject matter has actually helped make these meetings happier places.

3pm

Travelling to suppliers. They’re not too far but other days can involve lengthy treks to other offices.

3.30pm

Developers at the suppliers demo us the last few weeks work. We plan the next two weeks, flesh out user stories. The PM is usually there, often the web manager and accessibility consultant too.

The battle here can be to keep the focus on the important stuff. Making sure we’re working on simple, high value stuff rather than stuffing it full of bells and whistles. Suppliers generally just want to keep client happy, with the least effort. Mostly we have to be the voice of the user here, although occasionally the developers will argue than something isn’t user friendly (especially if it is complicated to develop).

5.30

Go home

The big shock for me, coming from a huge UX team at the BBC is there’s no designers involved, UX or otherwise. Visual design was outsourced, the details will be handled by the client side developer. Functional design and usability is the combined responsibility of me, web editors, business analysts and the accessibility consultants.

I produce very little documentation or deliverables.  Maybe a sitemap and some sketches for the content authors to think about. Some mock-ups to talk around, once we know what the site will look like. Mostly I think then talk.

Sometimes I”ll do whole days of each activity. Sit at home doing in-depth research, have all-day content workshops or be all-day on site with the developers. But more often than not days are mixed up like this. Makes me think of the polar bear venn diagram.

Related posts:

• IA deliverables
• The manager’s schedule and the maker’s schedule

One of the things about being the only IA/UX/ID type in the building is I tend to work on a lot more things at once than I did at the BBC. As well as the e-commerce project and trying to get the new website live, I’m also working on (to varying extents)

• shared drive folder structure
• replacing various ‘company’ directories
• investigating care management systems
• a new library system
• thinking about the next phase of intranet/teamsite development
• supposedly a reference data management strategy, although I keep having to postpone this