it's all good

Quiet noise made be a single voice

Home

Tag Archive for information architecture

Documents suck, information is cool

(With respects to Aarawak for messing with  their tag line)

I’ve been thinking recently about the role of documents in an organisations process,  and the slowly dawning realisation that they are increasingly irrelevant, barriers to information sharing, and possibly damaging to all that come near them. Ok that may be a little strong, but let me ellaborate.

When the ”document’ becomes the focus of your efforts, and not the information in them then they become a problem, not a solution.  You’ll need document management, audit and access control. when all you really want is the latest info, in an easy to find and use format, also know as ‘a Wiki’.

Worse, documents, when created to satisfy the needs of a process or procedure are often resented by the creator, written after the fact and as quickly as possible, and as a result can include inaccuracies, disinformation and missing details that are needed, in short document suck and act as a barrier to information sharing.

Develop a wiki as part of your project, allow all the actors in your team to contribute as needed, and not only do you have a record of the activity, discussions and decisions made on the project, you have living documentation to support the product once its released.

Now in order to make sure that the information being added to the site is findable,  you still need to have some control over the the structure, language and fair use of the wiki.  The idea is to make sure that on any product wiki, any one type of information (IA diagram for a web site for instance) will always be in the same relative location.  (mysite/ia/diagrams).  How you manage this is up to you, either build the structure and contributors follow it, or you do a little post editing, the end results are the same.

In any event ditch the documents, focus on the information instead.

Users, visitors and audience types

In a recent discussion / interview with a member of the Eduserv research group (previously known as (Eduserv foundation) which focused on a study soon to be proposed into CSM and HEI, I was asked to define the ‘user requirements’ for content management system project.

Users.., what are ‘users’ when discussing CMS requirements, and are they the same as website users?

In a traditional sense users are often regarded as the ‘users’ of a website, UX professionals talk about user testing and user centered design processes, but when it comes to CMS the user can be seen as the ‘site; user or the CMS user, each with very different needs and thus differing impacts on your requirements exercise. It’s important therefore to make sure that you are talking about the same ‘audience’ and that you accurately address their needs.

Site users, (visitors) need to be able to find information quickly and need navigation accessible content, they may ‘use’ the functions of the site in the process of finding content but referring to them as users (in the CMS context) clutters the message. Navigation, clarity, language findability structure and design make for the site visitors experience.

The needs of the CMS user however is concerned with editing interfaces, categorization and linking, they need workflow and accessibility checkers, they need to know who did what when and how, the kind of stuff that CMS (WCMS) should do well.

Most of the time the description of the feature needed will be itself explanatory. However you should never allow ambiguity and assumption into your requirements study. (Similarly words such as ‘solution’ ‘system’ and ‘service’ should also be avoided in this context.

For example

“The solution should be accessible to users with disability”…means what exactly?

Then we get to audiences, now these are different again. An audience, in this instance, could be defined as category or group of users (or visitors) who share characteristics, interests or experience levels.

Parents, teaches and students are all audience types, as a parent I am a visitor to my boys school website. The teacher’s who create the site with their CMS is a CMS User,

Users, visitors and Audiences are therefore interlinked, but have differing views of the solution you are defining, if you are going to meet these needs you need to make sure that you and your project sponsor / customer have a shared understanding of these differences and needs to avoid the ambiguities and, even worse assumptions that add risk to your project.

Content is still king

We spend a lot of time considering the technology of a particular site, customers are always keen to point out the fact that they ‘need’ features and functions to make their site ‘useful’ and attract users, plans involve the development and design of forums, blogs and web 2.0 features that are a must for the new site that will move them into the 21st century, and then as a by line there is content …

I forwarded an article from giraffe forums, which was later twittered to the community regarding the importance of content in the procurement of a CMS for any organisation. it suggested that migration of old content into a new CMS and web design, with the added function and features that a new system offers, but the same content, will effectively achieve nothing,

Content makes a site.

It should be thoughtfully written with the reader in mind and use language that they can will understand, use common language, and avoid industry acronyms.

It should be long enough to inform the reader, but not so long that they don’t want to read the piece. Add a ‘contact us’ link so that the reader can get in touch should they need more information.

Structure the content in a sympathetic manner, the reader dies not know your companies internal structure and probably doesn’t care, structure content in way that the reader will expect.

In a recent thread on the information architects institute mail list, the procurement of a CMS was again the subject of discussion, in this thread, one contributor suggested that the IA focus on the ‘Goals’ of the CMS rather than the features, again positioning the procurement away from the technology and more towards the desired effect.

Informing the user, allowing them to interact with the content and thus the organisation,

Web2.0 is about user generated content not technology, so don’t muddy the waters with unnecessary features, moderate them to the user, what they need and how they expect to be able to interact with you.

Information groups

Many websites will go to significant lengths to mage sure that their navigation is put grouped in a meaningful and logical way, (not always logical to the user but logical none the less)

Others however just don’t get it.

Amazon, a huge success story and still my favourite online retailer, is on my opinion guilty of two major no no’s.

Firstly the criminal use of massively over complicated Captcha images and secondly information grouping.

Where you place links and how you arrange them is extremely important if you are to avoid the ‘oops’ factor, the accidental clicking on a web link that does the exact opposite to the action the user intended

Take for example the illustration below

the links view your wish list and delete your wish list couldn’t be closer, true a simple are you sure message can help avoid the accidentally deletion of a users data, but why add the risk at all?

The way these links are grouped asks for trouble a user in a rush will see wish list, users don’t read but scan pages so there is a high possibility that they will click the wrong list

click the link (yes I tried, nervously) and you are asked to login, odd as I already logged in to view my wish list, no mention of the action you are about to undergo..(I stopped there, yes chicken)

The logical structure of the links is also odd with delete your wedding list in a complete separate screen area to the view your wedding list,

This make more sense separating ‘delete’ actions from ‘view’ actions but it lacks consistency.

The grouping of these links adds to the potential for user error,

Be aware how you group links, group them order or importance and use, user are more likely to want to view their data than delete they whole lot, so why put them together?

actions should implient each other

Clicks on the won link here and you off the site rather than viewing the security notice, only a minor issue but not what the user expects.

Be consistent; make sure that if you follow a logical group for one area of the site, you continue to use the same logic,

If an action for a link may cause user distress, make sure that it’s clear that this link will delete your profile /data

Finally check, then check again “are you sure?” and “An email will be sent to your profile email address to confirm this action”

ezvx4q29fg