Rating:

4

I learnt card sorting via trial and error, lots of practice, reading the occasional blog or article, fine tuning as you go, that was while ago.

Back then Perth was a little isolated, in has only been recently that web based workshops or conferences have been held in Perth that we have had excess face to face with the best of the web.

This is where practical books like Donna Spencer’s Card Sorting can fill the gap.

Now you would think that this book would be a waste of time for someone like me.   Well that’s what I thought too, but I was wrong.

Donna’s book is filled with the shortcuts, pitfalls, and professional enhancements that you can make to your card sort technique.  It’s a lot more than just usual simple chapter on card sorting basics that so many books have.

It’s a short book (162 pages), one you can very easily read on a 5 hour plane flight (which I did).   However it isn’t light on detail. Donna Spencer seems to have crammed the entire card sorting process along with various case studies into this handy book.

The book begins at the best place, giving you an overview of what card sorting is and isn’t and the best places to apply it.   It’s interesting here as it is suggested that card sorting can be applied to all sorts of things not just web sites.  I can contest to this; have card sorts many a collection of topics or information in a effort to find the magical categorisation sequence.

The Nuts and Bots on How to Card Sort

Next the book launches right into the practical application on how to run a card sort.  It covers the best method to use, choosing the content, participants, card construction,  and session facilitation.  As well as bucket load of tips and tricks to help you out when your card sort is doing pear shaped.

The most important thing is to listen to the discussion. Make notes of the ways people describe what they are doing.

It’s interesting but this quote reminded me that sometimes you can also learn a lot more additional information, such as user stories and the like from just listening carefully to the participants during a card sort.  Hence a card sort can often product a wealth of information beyond the draft information organization.  Your just have to listen and question.

The Data Analysis of it All

This book also takes the time to step through the entire analysis process of the data you have collected during the sort.   It deals with the exploratory analysis process in detail and the intense drilling down into the organisational scheme people use.

Statistical Analysis is also covered, don’t worry you don’t need to be a maths scholar (or Steve Baty) to understand this section.  Card sorting very simply steps through the use of k-means cluster analysis, hierarchical cluster analysis and multidimensional scaling analysis, showing you the outcomes and why you need to use these analysis tools.

Donna rounds the book off with a brilliant summary chapter full of overarching advice.   My favourite is:

Don’t assume anything – think hard about what you have learned from the card sort and its underlying meaning.

Now I think we can apply that to all aspects of user research not just card sorting.

Should You Buy It?

If you’re card sorting guru (like Donna) then maybe this book is not for you.  But if you are a user experience or information management professional and just want to learn or improve your card sorting, then this book is a must have for your bookshelf.

A while back  Matthew Hodgson had a  glance over the usefulness of personas, I have to agree with what he had to say, they tend to be under used.

I have encountered the odd projects where they has been a distinct undercurrent to just jettison personas altogether. After all what are they good for … absolutely nothing.

Okay before you all start jumping up and down. I’m going to add to Matthew’s persona usage list and hopefully dispel this myth. I’m not going to explain how to build a persona, there are plenty of  books and articles on the web that have covered this.

• Matching the Test Participants

  So you have researched the user base for the project, interviewed a bucket load of users, build a few mental models.  Condensed the user pool in to a series of archetypal personas.   May seem a little obvious but have you considered using the personas as a  matching tool on the users that are participating in the user testing later in the project. This assumes you have personas done at this stage.   Okay it’s not as hard and dry as that, but it does help with just giving you a quick idea.

• Personas for Content

  Ever considered that persona’s should be used as a reference when writing the content of a site.  After all they are reflecting the audience.  Sure you are going to write the content in one solid consistent voice  and all that, but how do you know that this content is going to be applicable to the users of the site.   Now if you write the content  with a reference to the personality, interests and abilities projected in the personas you can at least be assured that your are focusing on the needs of audience as well as the information requirement aspect.

• Google is a Persona

  I have worked on projects where the SEO factor of the site was critical.  To the point that to ensure this was reinforced I created a persona for Google.   This user  was particularly finicky on what they could read information wise,  But they where extremely responsive when they found the right information.

• Designing with Personas looking on

  Now, I’m not talking about any wireframe of grey-line designing. I’m talking about the real designing, the one with colour, pictures etc, the graphical elements.  You know the one.  Well to be honest this is often done is isolation. Sure you take into account the wireframes, and the various requirements. However it would be good to have someone to mentally talk over the design with, before you get to the client or user testing.  Someone to just confirm or tell you that your design is shit. This is where the personas come in.   Okay they are not real people, but they are the next best thing.

• Coding Conversations with Personas

  Traditionally this has been the phase of the developmental process you write personas for.  They are used so they can be referenced during the developmental process.  Like a pseudo walk though with the persona being referenced.   But have you also considered taking the persona to a deeper level and having them virtually “question” why you have the interface working a certain way.  Why you need those fields at all.

  With the persona’s you can start to question if parts of the system you are developing is needed at all.  After all people in general respond better to simple systems. Hence personas become great for confirming a walkthrough of a system before you code  anything.

• Ninja Personas

  The researching of personas can often be the problem that we all encounter.   The client can’t see the value, so unless you are bundling it all as just another item in the project, it will often get the flick.  So what do you do.  This is where Ninja Personas come into play, or personas by stealth. 

  What you do is leverage all those participants you are testing with.  When you are chatting with the participants, take a few more notes, ask a few adhoc questions. Do this and after a while you will start to see personality traits, scenarios, and the like. In short the personas you are looking for.  But what if the client will not do any testing.   Well much that I hate them, the fake non researched personas are as good a reference , better than nothing at all.

Still why do we tend to just tick personas off and throw them in the corner instead of letting them become part of the project proper.  There are a number of factors:

• Personas without data

  It does happen, the budget is small, there is no scope for user interviews, not even just a handful, so you are left with personas that are basically plucked out of the imagination and experiences of the IA. Not the ideal solution.  Hence the Ninja Personas above should be applied to this situation.

• Quick and Dirty Sketches

  Again if the budget is tight this can happen too. You do the research and document, but still the personas end up as a series of quick and dirty sketches.  They have no major body, no substance, no detail, no scenarios.  Nothing that can really be used to get an inside into the head of the persona. 

  Really the only solution here is to ensure the personas are completed even if it’s later in the IA. You can at least pass them on to the design and development team.

  Now if you are in an agile cycle, quick and dirty is good for round one, but you should have the personas finalised after a few cycles.

• Have Users, Why Bother

  If you have considerable user input on a project, as you should, you can tend to get an attitude from management that is anti-personas.  This attitude tends to be from the assumption that you have such pool of really to use participants for testing and so on that you can just ask them when and whatever you want.  It is assumed as well that this will be there at anytime during the the project.

  The solution here is to remind management that access to real people is good, but it is expensive in the longer term for every minor issue. The use of personas is the solution.

• Insult to Developers

  All to often the personas are supported and used throughout the IA process, but there is a lack of synergy with the development team and they will reject the use of personas as an insult to their ability.  They have often been working with the developmental process they have been using for years and frankly are usually entrenched in the methods and developmental techniques.  So why should they use personas and change everything.

  The solution here is simple and works best if you are on an agile developmental cycle.   Just get the developers to sit in as observers on a few rounds of usability testing.  This humbling experience will usually make them realise that it is the users they making the system for.   Not having the users present 24/7 allows them to consider the scenarios from the view of the next best thing – the persona.

• Separation of Scenario from Persona

  This one is open to debate, should a persona contain an extended profile information on the user type of should it have the details of the several (or at least one) scenario which the user finds themselves in.

  The separation of the two, can lead to the devaluing of the personas. Potential users of these personas will discard them as not  contain any information they can directly use on the site.  In a way the scenario component allows people to make the leap from the abstract description to a real world and a plausible event they can use and relate to.

So what do you think, should we really just tick the box and move on. Or even bother with them at all. 

Or are you like me using them as a reference when the users aren’t there I look over my shoulder and say “er that’s a stupid thing to do…”?

You’ve done the Information Architecture (IA) of the site months ago, the high resolution (graphic) designs of the side are finished, the site is cut and have been implemented into the CMS. The client has been busy filling the IA structure with content. This is when you discover that the carefully mapped menus are suddenly growing.

Now anyone involved in the web industry knows that a web site will only remain static and unchanged for a few minutes (at best) after you launch. So why the concern about the menu creep. Well just like with your interface style guide you would have left with the client (which they will ignore) you would also ensured that they have a hierarchy and navigation guide.

So how do you tell the client that maybe that new items are a little much, now Donna Spencer ponders this and when is a navigation list too long. As we know the 7 is enough rule is all very well and good but has no real substance in proven research.

In the Past

Interestingly has anyone considered that maybe the 7+2 as the number of items for a navigation list, comes from the the graphical design aspect and not the any IA or wireframing prototype restriction at all.

Let us think back, way back to the early days of the web, back when we were all designing for the base of 640 pixel wide screen. Back then it was about only 7 items that our could get across the top of a horizontal menu system.

As for vertical navigational list, it was around 10 items that drop the list to about 3/4 of the page height. So from a personal view this is where I remember this little gem from. And does it frankly apply to today. No.

Making it Long

Okay so you can have the list as long as you like, as long as it is usable, you have tested it right? That said this still doesn’t allow for the consideration of where you are going to put this navigation. I have seen and worked on some shocker sites, ones with layer on layer of ten to twelve items, and then left and right column lists of 30 to 40 items. Now all these navigation lists may all work well on their own but the total sum on the page is just visual and mental overload. Where do you start. Typically the bounce rate on these sites is very high.

The solution is simple, segment and paint in some white space around it all. Give the eye a break. You can still have your 100 to 200 links off the home page, but by segmenting and categorising on a function or informational level we can present smaller visual segments that can be taken in faster and with ease. Combine this with the use of simple design contrast, to give a little meaning, and a crowded page can be made very usable.

Another consideration is stepping off the grid. Yes, step off the grid, well not really off the grid fully, but the use of minor offsetting and curved elements can force visual direction and breaks.

This use of standard design techniques is something that is some what lacking in the area of wireframing and low resolution prototype development. In a way this is detriment to the overall site design for complex pages. Here is a classic instance where the IA and the designer need to work very closely to formulate the final product. Especially if there is a mandate to maintain the high page link count.

Mind the length

So even if we can have long lists of items, from a personal view I would try and restrict the length of the labels for the navigational items, there is just nothing worse than being presented by a list of navigational items that look like they have been written by a committee of lawyers.

So if the length of the list isn’t important, surely the label length and the placement is, what do you think, right, wrong or maybe?

It’s a bit of an old question, which is important design or the information, why do we really need web design at all. Well Alex Graham highlights the issue in her continuation of her discussion from the Port80 meeting last week. Frankly I agree. We do need design. From my view coming from the fields of user interaction and information architecture design and information are one in the same.

“Hang on”, you say, “one is content and other is just presentation, they are separate.” Yes, I agree in that aspect they are. But the relationship between them is extremely close, to the point that from a different perspective they are same. Design is information, information is design.

Pretty Pictures

Design traditionally is seen as all the pretty pictures, the graphics, the eye candy if you will. Do we really need all this? Well yes, but the design is used more than just to look pretty. In many ways to direct and drive the flow of the information. Good design is subtle, it uses all the techniques of colour, tracking, direction, emotion, flow and contrast to draw and promote the information.

Consider even the use of the basic contrast techniques one is able to promote and enhance information such that you are draw towards the highlighted article. A good example of this is in the base layout of a newspaper front page. If you want people to find information it’s a good idea to wrap it in a good design that promotes the information.

Think about a map without design, how good is the information contained without the rapid visualisation that the map presents. Web page design is similar. The key is the representation of the information via spacial and visual elements to promote the ease of information uptake.

It can be stated that design can be very subjective. Well if the site is developed based on a user centric design methodology this element of subjectivity can be reduced. Even so a good design is something you are not likely notice.  Bad design however sticks out a mile and will inhibit the findability of the information.

Information and Data

In the early internet there was organisation of the data into information. We had various methods of displaying the simple text (pre web) in organised visual elements. This made the information readable, easy to use (in a relative sense). Without this basic organisation the information would be presented as massive blocks of unusable data.

Take this to another level the semantic nature of the web is in part a layer of the presentation, the design on the base information to enhance and organise it into meaningful information. The use of lists, data tables, blockquotes and the like, all contribute to the layout, the design. Without these the information would start to become confusing and meaningless. It would degrade from information into data.

Even at a base level the structure of the information and the use of paragraphs, titles, headers and the rest provide an element of organisation, and of design. So if we don’t need design then lets just take it away. Now try reading a basic report without the logic of the document.

You could say that the search engines don’t care about the layout, just the information. True, but they do care about the semantic nature of the information presented. So they in turn promote a well semantically design page of information over one that is just a block of data.

Organisation is King

We can take this one step further, lets consider the categorisation of the information. Again this is organisation and the application of logical derivation on the taxonomy of the elements, the language. You could argue that this is in fact the merging of the data into meaningful information. We are taking it a step further with the application of information architecture and applying the visuals and logic of design to the grouping of raw information into a meaningful information design.

Overall as you have information you must have a control, a layout, the organisation, the displacement of the information on the visual field. Once you start to do this. Design becomes part of the information.

Hence without all the components of design, information becomes just data. Data is meaningless. So do we need design. Well even through I’m bias, design as critical as the information. Maybe they are the same.

How many times have you heard this: “Well the site / design / label / content has been done like this on this site, so it must be right, we’ll just copy that!”

We have all encountered it right? The premise that because someone has done it before us that is must be the correct path to take. This assumes a number of predetermine aspects:

• The site in question has the exact same budget, market and audience.
• There has been an extensive use of industry best practice and the application of user centred design principles on the site.
• Nothing has changed.

And just like night follows day, in most cases none of the above applies or has been done at all. It is this constant following of trends and sometimes poorly considered techniques that has lead to such labeling abomination’s as the “click here” link and the lesser “download now” and my personal hate “publications”. Now I’m not going to go down the path as to why this happens, that’s a completely different avenue (and another post).

So what is causing this blind faith in following the leader (or loser). Well in generally it’s going to be a lack of understanding of the web and the associated methodology. The same problem still existing in the software development arena I’m told.

With all that considered it may also be due to a lack of focus when we are allowing features to overtake problem solving as Tom Watson points out.

Now contrary to what Matthew Hodgson has found recently, maybe it’s just all a lack of application of good Information Architecture initially that has just propagated throughout the web industry. I still find that today I spend most of my time explaining to clients what Information Architecture is, what an IA does, and the benefits to their organisation. However this could just be a symptom of my local community, that doesn’t seem to have moved on from 2004, in some areas, as I note other Australian cities seem to be years ahead of the local scene.

Then again as Kay Smoljak considers maybe we are focusing a little too much on the development end of our web sites and not considering the important aspect of the interface. We all know the interface is important, that it is the area where one will win or loose a customer. So like we employee a specialist for the back end why not consider a specialist for the front end of your web site.

Needless to say too often it comes down to people being willing to bet an entire web project, big or small on mirroring someone else’s research and development or lack there of.

In an industry with no regulation, no standards, and guidelines that are only being applied by a small percentage of professional end of the industry. It does pay to stop and think, are the past example implementations on the web really the best, do you know all the internal decisions and effectiveness of the web site. Can you afford to get it wrong.