Recently an Experience Architect colleague pointed out some UX flaws in the way home improvement stores label their paint. He showed us a label that was very cryptic, failing the “Don’t Make Me Think” test. Worse, the name of the paint colour was truncated, so that two paints beginning with “Inspiration” might not be uniquely distinguished.

In my mind, that was just the tip of the iceberg. I recollected the cans of paint in my basement with the markup that I had added with a sharpie (“Family Room Baseboard”, “Martin’s Study”), and got to thinking how the overall labelling process could be integrated, for both user and business benefit.

I imagined a scenario where the staff at my home improvement store asked me for a personal label (“Martin’s Study”). Then they could print a label for the can including both the paint description and my personal label. Sure thing. From my point of view, a slight simplification of overall process, and a bit of cool factor to boot.

This store has thought about the bigger picture. They ask me if I would like an emailed copy of the composite label. Sure thing. Sometimes I throw out nearly empty cans, so this gives me a permanent record.

The store also asks if I want them to retain the label digitally. Sure thing. I don’t need to hang on to the email or the empty paint can.

So far, the store has provided value adds that its competitors have not. Perhaps these small services will encourage me to preferentially shop there for paint.

The store has actually thought about a much bigger picture. A week later, I get an email from them hoping that I enjoyed the look of my new study. Would I like to send a picture for their gallery? I might be selected to win a gift certificate, and by the way, here are some ideas for lamps and cushions that might look nice in your study.

I’m sure you can think of other business and personal uses for this combined information.  As a starting point, think about the life cycles of the paint can, the paint job and its maintenance, and how the room use or fashions change.

Announcing two new lessons in “Successfully Designing with Information”.

These introduce the end-to-end process of building a richly connected microsite.  They fit into the lesson plan like this:

• the brochureware approach and its limitations
• exploring the domain
• choosing an initial scope
• information design
• initial user interaction possibilities
• assessing the user experience
• refined user interaction.

The skills introduced here are applicable when designing large richly connected sites such as the BBC, and in portal-like integrated intranet solutions such as those that can be built in SharePoint.

We’re back with a new series for those of you practicing in the trenches, perhaps as UX, IA, Visual or Interaction Designers, BAs or developers.  It will provide you with practical and reusable techniques that even experienced professionals seldom get exposed to.

You are the ones responsible for designing information rich solutions, where information has to be found, shared, managed, and used.

When it is done right, everyone is a hero.  But it is not that easy. You have heard the stories: we can’t share information across business units, our users can’t find  stuff on the intranet, our clients can’t find what they need online.

This series uses real-world examples to show the techniques in action.  Even more, you will learn the thought processes needed to apply these skills in messy and problematical situations.

Hopefully, you will become one of the heroes.

Check out the what we will be covering in the first couple of topics, each a few posts in length, to gauge if they would be useful to you.  If so, stay tuned for a new post every couple of days.

1. Building a Richly Connected Microsite

Given the task of designing a micro-site that showcases a consulting group’s capabilities and track record, the marketing department has a number of case study brochures, and wonders if they could just put them online.

We blow holes in this approach.  By considering the structure of the content, and the user’s goals, we can create a microsite which is much more engaging, informative and sticky.

Topics Involved:  user goals, information analysis, information modelling, evaluating user interaction, wireframes.

2. Recipes for Success

On-line recipes sound simple enough, but there are many design considerations at play.  A variety of tasty examples show how we need to consider site goals and audiences, and how these are reflected in the structure of the recipes, access methods, terminology, and their relationships to other entities in their information ecosystem.

Topics Involved: site and user goals, information modelling, access methods, curated content, reusability considerations.

I’ve extended some of the core pieces of my blog into a course for classroom delivery which is now available. See  Foundational Skills in Information Design for a course summary.

Last time we spoke about letting users interact with search results, either by letting them go somewhere useful, or doing something useful.

But often search is part of a larger exploratory or investigative activity that is long-lived. In these situations, one consideration that helps me think about systems design is the relationship between REPRESENTATION and RESULTS.  Informally, we might say:

• Representation: the structure of the set of information I am processing with the help of search

• Results: the pieces of information that I dealing with, through my discovery process including search.

We can think about two types of relationship between these:

• the representation is well-known, and results are sought that fit into it
• the representation is not well-known, but evolves from working with results.

As an example of the first case, consider technology watchers researching a new technology and analysing its likely impact.  They probably have evolved a standard approach to this, and access the same resources and authorities over and over, before applying their particular brand of analysis.  Those of us who like to bake regularities into software love this kind of situation.  Regarding the task as a high-level pattern match, we might be able to partially automate this with saved searches, auto-categorize the results in a pre-structured repository, and allow the researchers to add annotations.  And if we find that the researchers present their output (Market Analyst Reports) in a different structure, we could consider viewing their annotations by their research framework or their output framework.

There are some oversimplifications here.  The technology watcher’s approach is actually less rigid than the example indicates; in particular, it will evolve over time as their domain changes.  I found this myself when I was trying to get up to speed on SharePoint 2013 Information Architecture, and deliberately looked for differences via What’s New, Deprecated Features, etc. So in addition to populating a framework with facts, our solutions should help us shape the framework itself.  This assessment may be informed by experience, change in the number of hits in a category, “buzz” about what’s hot and what’s not, or how effective our analysis is relative our competitors.

As an example of the second case, consider the detective work as portrayed in many TV shows.  The detective is trying to find out “whodunnit”, with a set of facts that grows from someone being murdered all the way to the crime being solved.  The detectives stand around a whiteboard with boxes and arrows showing parties involved, their relationships, and timelines. In addition to people and places, the detectives use investigative constructs that have evolved over the years, such as “alibi”, “means”, “motive”, “opportunity”, as well as trust attributes, based on whether  the information came from a DA or a “snitch”.  These don’t jump out when doing information modelling based on physical entities, but do jump out when doing user research. Hypotheses are constructed and deductive logic applied to sharpen focus or rule people out.  The detectives create a representation of the crime, supported by evidence.  For the next crime, they do it all over again.  The constructs will be the same, but their instances and combinations will be completely different.

The requirements for a system to support this type of activity seem to be those that make the whiteboard so effective:

• the ability to create and modify entities of known types, for example the victim and other participants, using conventional iconography
• the ability to create and modify relationships of known types between these entities; these could of various kinds, including space-time trajectories, business relationships, interpersonal relationships, beneficial relationships; these could also be real and hypothetical.

Search for the YouTube video “sensemakeing III” for a discussion.

What has this got to do with search? Well, watching the TV shows, we see both broad based exploratory searches (“interview everyone who was at the reception”), as well as very detailed information seeking searches (“George, find out if Mr. Smithers bought his shoes from Pringles”).  But to a large extent, we have crossed over into specialised sense-making applications and won’t discuss these further.

Stay tuned.

A colleague of mine was asking what unstructured data was, and why it was a concern, and what we can do about it. I gave him a quick explanation.  Here’s a longer one.

First of all, what is unstructured data?  It is data that is not broken down into individual named pieces.  Examples might be a Word document, a web page, the body of an email, a text message, and a tweet.  Contrast this with a name and address record stored in a database, with well defined fields for name, address, email, etc.

Unstructured information is a problem because a huge amount of what an organization could know about itself is stored in formats that don’t lend themselves to finding things.  By the way, it might also be stored in locations that don’t lend themselves to finding things, such as personal folders, email, dropboxes, etc., but that’s another story.

As always, before solutioning, we should have scenarios in mind.  Let’s consider a couple.

• our Helpdesk wants to be able to manage the large number of emails between it and its clients, in order to (a) improve responsiveness, (b) find a particular email, and (c) mine the set of emails for patterns
• the client wants an enterprise search where its users can find intellectual assets as confidently, reliably and easily as they search a large on-line catalog for physical assets (think cameras, DIY products, clothing).

There are two main strategies for handling unstructured data:

• adding structure
• adding description.

We’ll talk about these in turn.

Adding Structure

Although we use the term “unstructured data”, the documents and emails we deal with are not random strings of characters but already have structures that we might be able to exploit.

For example, a news article has a predicable structure; by creating a template in a web content management system with separate fields for title, author, and body content, we can achieve benefits at local and enterprise levels

• locally, we can provide more powerful searches and filter for news articles; for example the query “find articles authored by John Doe” which is more specific than the basic full text search “find articles containing the phrase John Doe”
• enterprise wide, we want the article to show up in a comprehensive set of information about staff; so when we query John Doe, we get

Sometimes a technology change will make it easier to add structure.  For example, if we replace emails to helpdesk with web forms, we are more likely to get a well formed request, improving cycle times and enabling analytics to be generated more easily. For example, contrast an unstructured email

Hi, helpdesk!!! I just finished putting in a bunch of entries and got an error and now I can’t do anything.

with a structured form

As a final example, we can add structure to short text messages using understood codes, for example, to vote for John Doe, text this number with LUVJD.  This approach works fine for text messages.  Unfortunately, it is often used for structuring names of documents, so we often see document names like

RFP Response for Big Enterprise – final v 10 – Joe’s comments.

When we have a folder full of names like this, we realise we have a problem of clarity.  Full text search will not help, as all versions of this document will likely show up in the same search.  That’s why we need the other approach to handling unstructured data, namely “Adding Description” and that’s what we’ll talk about next.

Adding Description

Whether or not we can add structure to unstructured content, we often want to add description.  This is done by adding metadata, information external to the content that describes some useful aspects of the content.  Much of the time, this is done to help us search or file the content, but different metadata can be used for other aspects of information management, for example describing how long the content is to be retained, or whether it is to be archived.  We will focus on metadata for categorizing and finding content, but wanted to make it clear that this is not the only possible purpose for metadata.

One part of the information architect’s job is to help the client define suitable metadata. We explore with the client how they might want to search, filter, and categorize their information. If we were dealing with a library of sales collateral, for example, we might considering searching it by product or business sector, and filter on whether it was overview material or detailed, or whether it was aimed for a business or a technical audience.

Coming up with initial metadata ideas is not too hard, but additional work is needed to turn it into a practical tool. The sales collateral examples illustrate various situations that might be encountered:

• Product
  • there might already be a product catalog that we can leverage
  • products might have both numbers and names
  • products can often be arranged in a hierarchical structure (look at a complex parts catalog or a consumer electronics site)
  • a document might refer to several products or product categories
• Business Sector
  • this might already exist in the organization
  • if it doesn’t, we should consider looking for a scheme that could apply enterprise-wide, not just to sales collateral
  • we can help the user develop this scheme using card sorting and other familiar techniques the final result is likely to be comprehensible to users tagging content and viewing content
• Overview or Detail
  • this might not already exist
  • it might be difficult to get a definition of what we mean by Overview and Detail
  • even if we did, the final result might not be reliably comprehensible to users tagging or viewing content
  • we might have an ah-ha moment and realise that the sales staff already talk about their documentation in terms of Two-Pager, Briefing Notes, etc., and that Collateral Type might be a more useful piece of metadata, especially for internal audiences
  • going with Collateral Type, this metadata is likely to be applicable just to the Sales Department rather than being enterprise-wide.

The next part of the information architect’s job, now that we have got the client excited, is to raise the question of how the metadata will get assigned to content.  There are two options: adding it by hand or adding it by program.

In a few lucky cases, adding metadata by hand is feasible.  This is the case where we have professionals whose job is corporate communications or corporate librarianship, who believe in the importance of tagging content, who understand the domain they are working in, where the volume of publications is small, and where the metadata structure is simple.  A feasible example might be corporate communications tagging internal news releases with category, any applicable departments, and any applicable projects.

Otherwise, there are a lot of “ifs” that might not pertain.  Some employees might not care about tagging the content they create.  Some metadata might be so complex that is would not be feasible to reliably tag a big document with all applicable instances of metadata.

In this case, we will need autotagging software to do the job of tagging.  We still need to define the  metadata that we will use. The autotagging software scans content and applies metadata tags based on rules that are set up and maintained by the organization.  For example, an HR department might have the rules:

If the document contains the words “Human Resources”, tag it with “Human Resources”
If the document contains “HR”, tag it with “Human Resources”.

The software makes it easy to test the applicability of rules and tweak them based on what we find.  For example, when we run the second rule on a set of documents, it will show which documents match the rule, like this

….. contact HR at hr@ourco.com …
… the HR Department provides services …
… to get a horizontal rule in your web page, use the hr tag …

In this case, we have learned something and can modify the rule.

If the document contains “HR” and not “tag” and not “HTML”, tag it with “Human Resources”.

Retesting the rule will now exclude the document talking about horizontal rules.

There can be quite an elaborate syntax for building tagging rules.  Some things that we can handle are Booleans, words that sound alike even though they have different spellings, and pattern matching.

By the way, pattern matching has some interesting uses.  For example, we can use it to tag documents that contain email addresses or phone numbers.  This is useful if want to scrub a set of documentation  to make sure that it does not contain any personally identifiable information.  And of course, using the rules, we could also test for the anti-bot form of email, name[at]provider[dot]extension.

I heard an excellent radio program about the future of the book a few days ago. Some of the points raised in the context of digital books align with the future of the content web and other channels. Here’s my mashup.

Future “books” will redefine the “reading” experience by :

1. letting the author augment their content with structure and linkages
2. letting the reader augment the content with their own annotations
3. letting external sources augment the content with their own commentary

Let’s talk about these, taking as an example “Lord of The Rings” for fiction, or a biography of Henry Kissinger for non-fiction.

First, content augmentation by the author. Currently the author provides ample structure through plot lines as characters and events unfold. Some of these represent relationships in physical space-time, others reflect unfolding in social and psychological spaces. Regardless, in a complex book, we sometimes have to work hard at keeping all the events, players, and locations straight. When reading a physical book, we might keep a thumb in the map, chronology, and dramatis personae, but soon run out of thumbs. In digital books, the same artefacts, suitably architected, could be integrated into the content; they could even provide alternative visualizations of the entire book’s content. Different readers would have different preferences for using these tools. Some would trust the author’s aesthetic and follow along for the ride, agreeing to work hard when the author wanted them to; others might use the tools as a cross reference and crutch; yet others might rely on the alternative visualizations as their primary access to the material.

Second, content augmentation by the reader. Making annotations and margin notes is straightforward enough, but this is taking a book-centric point of view. A more user centric point of view might ask why the user is reading a book, and allow the annotations to be semantically tagged with categories meaningful to the user, for example “Going On A Quest”. And of course, the reader might be reading several books to support their goals, so would want the annotations to be structured consistently across all books, but aggregated outside of any particular book.

Third, content augmentation by external sources. Right now I often read a book with Google at the ready, but this is a hit-or-miss proposition. I know there are resources out there, and I would appreciate it, even pay for it, if someone had curated some good resources for me. We could imagine an ebook offered with options for plugins of curated study notes, literary criticism or historical context, written by an authorities and cross linked to the book.

So those are the three takeaways from the radio program. By the time we have done all these things, the book will have acquired additional structure, content and interaction. The book business will have new players and institutions.

I really have to sympathize with one of the speakers in the radio program. They were asked why they kept talking about the “Future of the Book” when it would feel and behave nothing like a book. The somewhat plaintiff answer was, “we don’t have a name for it yet”. But we will one day. Ten years from now, we will have new vocabularies and patterns for this sort of thing.  I look forward to helping us get there.

I’ve done a lot of intranet work and, in makeover situations especially, almost always run across the Worst Intranet Mistake.  What is it?  Simply stated, it’s the failure to distinguish between resources that a business unit creates for their own use, and those they create for other audiences.

Without prejudice, let’s use the HR department to illustrate.  The tiniest amount of user research will show something like this: for other audiences, let’s say the general employee, HR will create all those policy and procedures documents, benefits, etc. that we are familiar with; for themselves, HR will have discussions about new plans and providers, meeting minutes, and work-in-progress documentation not yet made public.

I can’t tell you how many times I’ve seen proposals for HR landing pages combining resources for themselves and for other audiences.  This is a huge structural misstep with many repercussions.  Here are some:

• unclear expectations of what you will find when you click the link to the HR page, and confusion when you get there
• compromised terminology – HR should talk to employees with different terminology than they use to talk among themselves
• lack of alignment with the security model
• lost opportunity for thinking about audiences at an enterprise level.

The last point is especially fruitful.  If we do a “for the department / for others” analysis for all departments, we might not only solve the Worst Intranet Mistake many times, but might find alternative useful ways of presenting corporate information.  For example, we might find that HR, Office Services, MailRoom and IT all offer services to the general employee. Given this, we might propose a Quick Reference area for the general employee, aggregating services from all of these groups.  We might also find segmentation of “others” beyond the general employee, for example “managers” or “construction services”, with specialized content aggregations for them too.

To be honest, I’ve described the most blatant case, but mixed-audience thinking shows up in many guises. So whether you’re doing a makeover or net new intranet work, beware the Worst Intranet Mistake.