ia play

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.

The RNIB intranet project is over but a couple of people have asked me about intranets recently and I’m putting together a intranets special FUMSI ‘folio‘ so intranets are on my mind.

I’ve made a new intranet resources list of the places I go back to regularly. I’ll add to it over time.

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

One of the blogs I follow faithfully is The Simple Dollar. In  The Variables of a Purchase: Is Price the Ultimate Bottom Line? Trent says

I place a significant extra value on buying local produce and dairy products versus buying items that are shipped in. I place a slight premium on the ethics of the business, but I often find that companies with questionable practices often have many competitors and it’s trivial to simply use more ethical businesses. I have something of a minimal standard for customer service and shopping experience – if a company doesn’t meet that standard, I just don’t give them my business, regardless of price, but above that level, I view all competitors roughly equally.

So  Trent has a ‘minimal standard’ for shopping experience but there are other factors that he places higher value on.

I came back to this thought when reading yet another perplexed UX blogger, wondering why the field isn’t sufficiently respected or valued.  As usual, I thought of iPlayer.

The user experience team that worked on iPlayer had many anxieties about the product that launched.  The UCD process hadn’t been followed as faithfully as it could have been. Everyone felt the UX could be better (although we didn’t necessarily agree about what was wrong).

And yet, iPlayer has been a massive success for the BBC. And appears to have turned the guy in charge into The Man Who Saved the BBC and gave him the opportunity to say in print “I only do things for the user”. Those users were delighted to get their favourite shows for free,  so appear to have put up with the clunky bits of the UX.

(Now Five On Demand. That’s a different matter. The UX sucked, I was only mildly interested in the product and they were expecting me to pay. No thank you.)

With free services, I definitely put up with some rather undesirable user experiences. Google apps are a mess when used on my EEE and the keyboard shortcuts are patchy but I stay faithful. I use Swapshop all the time and that’s a shocker.

But is it different when I’m paying?

I like the user experience of Waitrose way more than Morrisons. But I go to Morrisons. Mostly because it is near my house and a bit because they stock the things I buy regularly.

We also buy meat direct from farmers and I can assure that the user experience of that process is absolutely awful. But we persist. We like the pigs.

When travelling I buy the cheapest, direct flight and then complain about the customer experience when I get home. I can’t stand American Airlines but when my parents lived in North Carolina I flew with them many times a year. I still get mad when I talk about their flight attendants but they were the only airline that flew direct from London.

Some services I do care about how good the UX is.  Others it isn’t the deciding factor.

It isn’t enough for UXers to say “UX matters”. Because sometimes it doesn’t matter enough to stop someone making money. You have to have a developer otherwise you won’t have a site. But it is possible to launch a successful website without a UX designer and even without a particularly good UX.

Not always, but sometimes.

So when does UX matter? And how do you know if this is one of those times?

I’m never quite sure I’ve ‘got’ what Bruce Sterling is getting at…but there’s always something in his non-fiction writing that I feel the need to capture, come back to, mull over. I never read his sci-fi, I picked up one of his novels in the charity box at work and flicked through it. The prose didn’t seem like something I wanted to spend my time with. I’m not sure if that was hasty.

Still, his article in interactions magazine has the usual hints at possible wisdom. Or maybe just comforting statements of the obvious, although he almost certainly doesn’t intend them to be comforting!

“Below the professional level of for-profit publishing, the subculture of science fiction fans exploited early, DIY duplication technologies: Gestetners, hectograph. There were letter-writing campaigns, amateur press associations, local writers groups, regional science fiction conventions galore. One might even argue that contemporary Web culture looks and behaves much like 1930s science fiction fandom, only digitized and globalized.”

“Digital media is much more frail and contingent than print media. I rather imagine that people will be reading H.P. Lovecraft-likely the ultimate pulp-magazine science fiction writer-long after today’s clumsy, bug-ridden MMORPGs are as dead as the Univac.”

“Experience designers are a tiny group of people with a radically universalized prospectus”

“I scarcely know what to do about this. As Charles Eames said, design is a method of action. Literature is a method of meaning and feeling. Hearteningly, I do know how I feel about this situation. I even have some inkling of what it means”

via interactions magazine.

One of our biggest challenges in rolling out SharePoint (and in many other projects) is getting an accessible rich text editor that our blind and partially sighted authors can use to enter content with.

We’re looking at XStandard, TinyMCE and Telerick RadEditor.

Any other suggestions welcome. I’ll let you know how we get on.

SharePoint search takes into account keywords in titles, URLS and hyperlinks. In each case the keywords need to be separated by spaces/underscores.

It also favours:

• HTML over documents, PPT over Word, and Word over Excel
• high-level pages
• shorter content pages/documents

These can be changed but it is generally not advised (imagine the manual equivalent of a plumber sucking air through his teeth).

Related posts
SharePoint search: Inside the Index book ‘review’
SharePoint search: good or bad?

We’re working on SharePoint teamsite requirements today. Team-sites are permission controlled “collaboration spaces”.

We’re using them for three types of teams:

• formal organisational teams i.e. teams that share a line manager
• project teams, that might be within an organisational team or cross-team
• network teams, for communities of practice

Because of the accessibility changes required, all functionality requires development so it isn’t the case that we can just stick functionality in and see if people use it.

We’re planning to include content pages, document libraries, search functionality, discussion boards, lists and alerts. We’re not including calenders, wikis and blogs. With calenders we don’t think they’re particularly useful when they don’t integrate elegantly with Outlook- we’re told you can’t send an Outlook appointment to a SharePoint calendar. Wikis are not widely used within the organisation and would require an awareness/training effort so they’re out for now. Blogs are similarly not a common tool at present, and I don’t buy the scenario of blogging for a very limited team audience.

I’ve been researching the reasons for not moving everything from your shared drives to SharePoint. These seemed to be the common factors mentioned (with varying levels of explanation/justification):

1. Storage costs
“SQL Server storage is more expensive and complicated than network storage” -objectmix.com

2. Archives
“The basic collaborative nature of  Sharepoint probably doesn’t support long term historical archives of data.” -objectmix.com

3. Security

4. Backup and restore issues

5. Types of files
File types not to store in SharePoint: scripts, executables, multi files, CIFS links, some access databases, Outlook Personal Folders, Application files (*.exe, *.dll, *.bat, *.log, etc.), large backup files (> 50 MB *.zip, *.iso, *.bak, etc.),DVD images (*.ifo, *.vob).

6. File usage
Usage reasons not to store in SharePoint: files not accessed for months and files without collaborative value

7. Size of files
File size restrictions seems to be the most commonly mentioned point, with most sources suggesting an upper limit of 50-100MB per file.

To maintain optimum server performance and ease navigation of the document libraries and folder structures, use the following guidelines as the upper limits when organizing your files:

 o   1,000 files in a folder

o   1,000 folders per Document Library

o   1,000 document libraries per site

o   50 megabytes (MB) per file”

– tributarysoft.wordpress.com

8. Linked documents
“Linked documents and files cannot be run from a SharePoint site, as the dependency on an external sources isn’t captured in SharePoint.”
– blogs.msdn.com/joelo/

9. Only in SharePoint for search purposes
The files in the drives can still be searched for in SharePoint. “Just index them with Microsoft Office SharePoint Server and they will become discoverable as well.”
– jopx.blogspot.com/

Sources:
http://objectmix.com/sharepoint/337243-sharepoint-replace-network-shared-drives.html
http://blogs.msdn.com/joelo/archive/2007/11/08/what-not-to-store-in-sharepoint.aspx
http://tributarysoft.wordpress.com/2008/08/18/windows-file-share-migration-to-sharepoint-nyc/
http://blogs.msdn.com/mikewat/archive/2006/12/09/file-shares-vs-sharepoint.aspx
http://jopx.blogspot.com/2007/01/sharepoint-document-libraries-or-is.html