ia play

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

My team is hiring two new project managers:

Project Manager x2 – Ref: 5240.

Let me know if you’d like to know more.

I’m probably going to get a new job title. And it won’t be UX-anything, so don’t worry that I’ve had a change of heart on that.

I don’t use my IA title much within the organisation. The web team get it but that’s four people.  I tend to introduce myself by what projects I’m working on. In project kick off meetings and meetings with stakeholders I’ll explain what I’ll be doing on the project but not my title.

A lot of the teams I work with are intimidated by IT projects. And for them the language of user experience design and information architecture is as alienating and terrifying as the language of server architecture and database design. It is all big words from people who get paid more than they do and seem to work in an alternate universe of conferences, social networks and blogging.

So mostly my introductions go something like…”I’m Karen, I’m part of the project team and I’ll be responsible for making sure users can find their way around the new site”. Or “the search actually works this time”. Or “putting your content into the system isn’t such a nightmare”.

So my boss and I are trying to come up with something that both more accurately conveys what I actually do and is also a user friendly one.

Anyone got any examples of doing user research into what their job title should be?

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

The high-level goals are to re-brand, improve the user experience and improve the back-end processes. The rebrand will be to bring the site in line with the rest of the website which will relaunch in September. The user experience goal is not particularly specific but there is also a product backlog that tells a more detailed story.

The pre-existing backlog provided some of the business requirements but we didn’t know how applicable this was, what the priority of each item was and whether new requirements had come up in the interim.

Stakeholder workshops were set up and I attended the workshops covering catalogue and marketing. We’ve now got a fresh, prioritised backlog and we’ve clarified some of the language.

Some IA bits of the wishlist from the workshops:

• more ways to browse the content, including by price and date added
• a more flexible category structure, allowing polyhierarchy
• search that is less divided by our various stores
• recommendations – lots of discussion here about the various types of related products. We have accessories, variants, alternatives and ‘you might also like’.
• a more ‘personalised’ experience, possibly based on preferred formats. I voiced words of caution here about requiring people to express preferences and about boxing them in.
• loads of analytics were desired but everyone was realistic about how much resource there was to interpret them

We got information about volumes and value of various customer groups. And some more philosophical feedback: unlike most e-commerce projects maximising sales and profits isn’t the absolute goal here. Exactly where the line between selling and helping lies will be interesting to see.

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

I had some quiet time over Xmas and did some current state analysis of the online shop then. I’m so glad I did this. As per usual, as soon as the project actually kicks off there is limited time to do this sort of thorough research.

One of our business analysts has done a formal “as-is” review of the back-end processes but I’ve been concentrating on the front end user experience, particularly browsing the catalogues.

For my current state analysis I identified all the existing features. To do this:

• took lots of screenshots, of all the screen variations I found
• made a sitemap
• annotated the documents, identifying each separate element

Now just because we have all these features now, it doesn’t mean we want to keep them. That said, during the website redesign we missed things that are working really well on the existing site. The site looks clunky and old-fashioned but there’s some nice features in there. So I wanted to make sure I genuinely knew the site inside out.

The functionality basically breaks down into:

• arriving on site (including via search engines)
• finding and choosing items
• information about purchasing
• registering
• adding to basket and purchasing
• tracking/cancelling

I’m going to concentrate on the first two areas for now.

Within the main shop (i.e. not the book shop) there are

• a store homepage
• category pages (including sub-categories)
• product pages

There’s also a sitemap, terms and conditions, product news, pricing information, contact forms, and help information but the other three are the main page types.

The project already has a product backlog from an earlier attempt to kick it off. After I have annotated all my screenshots, I compiled a list of features and then compared that to the product backlog.

The backlog was missing the following elements:

• link from product page to product instructions
• link from product page to other product guide/pages
• link from category page to product category guide e.g. choosing a mobile phone
• information about product size
• offer product variations e.g. colour and size
• product image
• product image enlargement
• seasonal offers and selections e.g. Xmas
• alternative ordering information e.g. call this number
• vat price + non-vat price
• login as different types of shopper
• links to t&cs
• communicate different delivery prices (free, special + xmas)

This flagged up for me a problem with the way the backlogs were generated. Stakeholders contributed ideas for features they wanted to see but tended to assume they would automatically get all the functionality they already have. Even with this process, I almost missed out search from the list, as it is part of the main website navigation and I was ignoring the standard page “furniture”.

Some of these gaps would indeed be obvious as we built the site but a number are not standard e-commerce functionality and it is entirely possible that the project team wouldn’t have thought of them independently. So for me the current state analysis catches functionality that might otherwise have slipped through the net.

Next: business requirements

This article is part of a series about our e-commerce redesign. The series includes Current state analysis and Business requirements.

When I tell my friends that I’m working on an e-commerce project they look a bit baffled. It isn’t something that people immediately think of in relation to charities.

But we make/publish and sell a lot of stuff: books (braille, large print, audio etc), magazines, watches, telephones, kitchen equipment, mobility aids, remote controls, headphones, clocks, calendars, software, board games, playing cards, lamps, and batteries.

Our resource centres are also shops, and we have a moderately sized warehouse in Peterborough.

I’ve mentioned the bump-ons before, but some other favourite products include:

• Talking tins
• Audible liquid level indicator
• Braille playing cards

The first thing you notice when you go to the RNIB shop is that this page talks about two separate “stores”.

“At present our Online Shop and Book site are separate. You will need to register in each store to buy a product or listen to  book.”

Obviously less than ideal.

Once you get into the stores it becomes obvious that the shop doesn’t feel like a normal online shop. There’s some basic patterns and conventions about how online shops look that the site isn’t consistent with. That makes the site a bit confusing, you have to actually read everything properly… you have to think about what you are doing. The product pages themselves are ok but the lack of images in the browse pages means the site doesn’t scream shop at you.

We’re just starting the project to relaunch the shop now, so I’m going to be digging a bit deeper. The goals are roughly to re-brand, improve the user experience and improve the back-end processes. At the moment it is just fun to be designing a shop.

Next: Current state analysis