The table below shows the current rankings for the same keyword phrases selected before. The numbers in brackets show the previously recorded ranking.

So there is clear improvement in some areas. And the number of leads coming in from search engines on certain keywords has increased considerably.

However there are still some areas for improvement, in particularly around the “chakra crystals” phrase and anything related to locality (ie Sydney, Australia or Bondi). And the Page Rank has gone from 3 to 2, so that’s something I will have to investigate further.

It has been pointed out to me that I may have left this re-assessment a bit too long, and that I may have missed the main affect of the improvements when it was its greatest. In other words, the rankings might have improved a lot more at first, but then slipped back down to where they are now. I’m not too worried about this, if it’s indeed correct, because we’re not after short-term gains but long-term benefit.

From here, the plan is to continue to get good quality incoming links. For example, a recent piece in body+soul magazine was great, hopefully the first of many!

Related posts:

1. SEO improvements to Chakra

More than likely your content management system (CMS) will have many usability problems if you just use it “out of the box”. Having been involved in a number of projects tasked with implementing a these types of systems—including content management systems for websites, intranets and wikis for knowledge management—I’ve noticed that there are a number of key areas of the user interface that frequently need fixing from a usability point of view.

All the usability tips you see here link back to general usability principles, and they apply to any software package or web application, it just seems that they are an issue in most CMS implementations.

Use these tips to improve your current CMS or to help you when implementing a new one.

1. If in doubt, leave it out

The user interface should be devoid of everything that is not necessary in terms of users completing their tasks. Most CMS products will have capabilities in excess of what is being used, but don’t show it if they don’t use it. And many products will have optional extras and upgrade possibilities, so your version might not have all the bells and whistles. For better or worse, some vendors will leave a stub to these missing features (possibly to help encourage up-sell). Don’t show it if they can’t use it.

Use CSS to hide stuff if you have to, but clean up that interface. We’re talking about main navigation, links, and irrelevant details spat out by the system. This also applies to words; as Steve Krug said “Krug’s third law of usability: get rid of half the words on each page, then get rid of half what’s left”. Each page title, sub heading, button label, navigation label, form field label, icon and graphic should be useful and meaningful, clearly communicating what it should.

2. Shield users from the complexities of the system

Your CMS might be complex and all powerful, but users don’t care. The user interface should provide a level of abstraction away from the inner workings of the system, performing a translation between what users want to achieve and the technical functions that make it happen. Don’t expose the user to the inner workings of the system by referring to things such as “asset models”, data structures and other things found under the bonnet. These things relate to how the system performs what the user needs it to. Users do not need to know about these things and will be confused by them. They are a dead giveaway that an interface has been built “by developers for developers”.

Frequently you’ll find this kind of thing popping up in “error” messages and terminology used. But also in the convoluted processes users have to go through and the assumed knowledge they need to interact with the system in even the most basic ways. For example, a common problem in many CMS products is ‘pogo-sticking’ or ‘hub and spoke’ where users are forced to go back and forth between different parts of the system to complete their task, usually with some degree of ‘double handling’ or duplication.

3. Speak the users’ language

On that note, the user interface is fundamentally about communication. You have to communicate clearly, using terminology the user will understand and in a way that allows them to take the necessary action and continue with what they were doing. This effects navigation, notifications and messages, button text, form labels. Of course, it goes without saying that jargon and internal system techno-talk should be nowhere in sight (although you might want to use business jargon that is specific to your particular organisation, see tip 10).

User research can help uncover the language that should be used, and Defensive Design for the Web by 37signals gives excellent advice on error messages, notifications etc.

4. Know your real users

What the heck, let’s go all the way and find out who it is we’re creating the system for. Who are the end-users? Chances are they are not techies; they’re not developers and they’re not systems administrators. Which is a shame because they won’t get how perfect the database schema is or how scalable the architecture is. In fact they don’t care about how it’s built at all!

Sure, developers and sysadmins may be users of the system, but they unlikely to be the majority of the users. The end users are going to be writers, producers, product managers, sales people, editors…human beings (ok maybe not the sales people :).

Do some research, find out what, how, when and why these users are using the system. Talk to them, watch them, crunch some server logs, do a task analysis. It’ll all inform the design and help you work out how to apply the tips you see here.

5. Don’t forget the real-world purpose

The acronym “CMS” is made up of three words, one of which is much less important than the other two: the S. Don’t get caught up in the magnificence of the system and forget its true purpose, which is to manage (and create) content. That’s why users are using it!

Everything in the design and construction of the system should keep this in mind. The purpose of the system is not scalability, data synchronisation, referential integrity or network security. These are simply a means to an end, and should stay behind the scenes. Techies will focus on these things, which is fair enough, it’s their responsibility and their reason for being. Which is why there needs to be someone calling the shots in the project who understands that the job of the user is not these technical aspects, it is about creating and managing content.

6. Do a few things really well

Getting to know your users should include some kind of task analysis, find out what the most important tasks are that your users perform. Prioritise and focus on these key tasks, do them well. Customise the interface, automate some tasks to simplify processes, whatever it takes but make doing those tasks as easy as possible for users. Allow them to initiate those tasks from the home page.

For a busy, content heavy website, a key task might be writing content. This is “on the critical path”, to use project management parlance, so ensure you get that right if nothing else. Similarly, for a very large site with tens of thousands of content pieces, a key activity might be searching for content (either to re-use it or attach it as a related item). In this case make search work really well, perhaps structure the system around searching.

7. Use natural mappings where possible

In the case of a CMS, a natural mapping is where the user interface mimics the action being performed. A great example is when editing the placement of items on a web page. Typically in a CMS this is achieved using a form to capture input (unless you’re using “in-place editing”). But this isn’t natural, since the form doesn’t bear any resemblance to the finished product. It seems trivial but re-arranging the form fields on the edit page to be similar to the finished page being created, will make it much easier to understand which bit is which and where they should type what. Or provide a visual map that illustrates that each form field relates to in the real world. Or your could just label each field so it makes sense :)

A good user interface mirrors the mental model of the user as opposed to the internal system model.

Another example is if dealing with images, show them. This could be thumbnails when searching or listing, or bigger versions when viewing properties. It’s much easier to identify content by visual attributes that will appear in the end product, such as what an image looks like or title text or name of a page. Compare this to an arbitrary system generated ID, which means nothing to a user.

8. Be consistent

The user interface should be consistent across screens, pages and components. This includes navigation, buttons, form controls, text styling, link styling, form layout, terminology and feedback mechanisms (ie alert boxes or ‘yellow fade’).

This is especially the case if certain parts have been customised, which normally stand out as being substantially different in look and feel. Delivering a “Frankenstein” is a sure fire way of making the system look like a hodge podge which won’t help user’s perception or acceptance of a new system. They must feel it’s a quality product.

9. Stick to established conventions

Not only should the CMS be consistent within itself, but it should also be consistent with what users are likely to expect from other similar systems. For example, if the CMS is a web application, standard website conventions apply, such as the placement of the search box, use of form controls such as dropdowns, and single click links. As Rich Internet Applications become more prevalent, additional conventions will emerge, but this is not a licence to do whatever you please. Functionality hidden behind unconventional methods of interaction (such as right-click or double-click for web) will not be discoverable because users will not expect they can interact with the interface in that way.

10. Tailor to suit your specific environment

Consistency also extends to making the CMS look and feel like other tools and applications provided to your users in their Standard Operating Environment (SOE). Integration with these tools will be hugely beneficial, be it ensuring content from the SOE word processor can be easily copied and pasted into the CMS, or ensuring the web-based CMS works in the SOE browser, or perhaps integrating the CMS into the organisation’s single-sign-on so that users don’t have to login separately.

Tailoring the CMS might also mean using consistent visual design and branding, making users feel like the CMS is “theirs” can go a long way towards them accepting the new system and creating emotional investment.

This tailoring should also include removing unnecessary items (tip 1) and abstracting a simpler interface (tip 2) especially for key tasks (tip 6) and speak their language (tip 3). For example, if the specific purpose of the CMS is for an intranet, then the user interface should be tailored to make reference to that, rather than a “website” which might be the out-of-the-box terminology.

11. Create an effective “home page”

A home page or start page or dashboard for the CMS is a great idea if well crafted, containing useful items. Don’t load it up with out-of-the-box clutter (typically “workflow” related items) find out what your users need to know when they first login. Use this page to give easy access to key tasks, by prioritising all the things that the system can do, and giving prominence to the core tasks users need to perform (displayed bigger, higher on the page and perhaps with icons). Infrequently used or less important items can be smaller and further down the page, if they’re shown at all.

Hand in hand with this is streamlining the login process itself. If the CMS allows editing of multiple sites, but a user only ever edits one of those sites, then don’t make them have to choose the site every time they login; an unnecessary step standing between the user and them getting on with their work.

Furthermore, consider dispensing with a dashboard or home page altogether and take users straight to the single most common task (if there is one) and let them navigate to the home page when they need to.

12. Get the forms right

The primary method of data entry in most CMS products is a form. And typically they’re not very usable, so get this part right. The forms should be well designed, with logical structure, meaningful labels, proper validation and a clear call to action. As mentioned in tip 7, making the form more natural in terms of its relation to the end-product will make it much easier to use and understand. Web Form Design by Luke Wroblewski is an excellent reference for creating usable forms.

13. Get a designer in on the action

Don’t leave the design of the user interface up to the developers who are building/installing the system. Even if they do have the required skills for interface design, they necessarily lack the perspective because they have been involved in the nitty gritty of the inner workings of the CMS. Even experienced UX practitioners find it hard to maintain an end-user perspective if they get wrapped up in the technical complexities of building the system.

Most organisations would not think to use their graphic designers or UX people on the tool as opposed to the end-product. But this underestimates the importance of what is often a mission critical tool, particularly if you’re in the business of publishing information on a large website.

14. Don’t rely on training

Training users will not completely resolve usability issues. Long after training sessions and user manuals have been disregarded, an unintuitive interface or overly complex system will still be causing problems. In the worst case, even the trainers themselves will have difficulty explaining how the system works and how it should be used, as they try to bridge the gap between the technical system and the users.

While CMS training programmes make everyone feel better, they are rarely effective in my opinion. Why not just spend that time and money making the system easier to use? Then anyone should be able to use it without needed repeat or refresher training sessions.

15. Provide user assistance

Training won’t save a poorly designed system, but you should provide help. This might involve some instructions that explain what users are supposed to do. These can be shown during a “training wheel” stage or in a “n00b” mode, such that they turn off once users are comfortable with using the CMS.

Other than instructions, there should be help content in-situ, when and where it’s needed to help users perform a task. As with notifications and “error” messages, the help should be helpful. It shouldn’t simply re-state what users can already see for themselves on the user interface (eg “this screen contains the XYZ buttons”) but should tell them how to use a function or feature, what’s expected from them and how to recover if something goes wrong.

Of course, there are ways to reduce the need for instructions and help content, simply through the design of the interface making it more obvious how users should use it: good labelling for buttons and navigation, clear visual hierarchy for pages and forms, and prominence given to the most important items on a screen or in a list. The sequence a user should follow, and what they should be focussing on at each step, should also be clearly indicated.

16. Consider an expert interface

There will be some (if not a lot) of push-back from developers when it comes to these tips: “but it is useful…for developers”. And, there is certainly an argument for this if developers and other technical roles will be using the system alongside normal users (although perhaps fewer in number). You want to give them access to use the power of the system and the information they need to administer the CMS and the end-product site, without affecting what normal users see. The view a user sees could be based on their login.

17. Don’t release something half cooked

There is also usually a really strong push to do the bare minimum and then fix it later. That is, launch the CMS out-of-the-box and then “take care of usability later”. This is a bad idea. Firstly, launching something that isn’t working well will not engratiate you to your users nor give them much faith in the new CMS. Secondly, fixing usability problems later on will require users to re-learn the system all over again. Thirdly, “later” rarely ever comes, especially if the business has just invested a lot of money in buying/building a CMS, they will naturally expect something that is finished and the best it can be.

This doesn’t rule out continual improvements to the system—including the user interface—over time but it means the CMS should be usable and useful from the get-go. The user experience need to be taken into account when planning the implementation of the CMS and shouldn’t be tacked on to the end, otherwise there will never be enough time or resources to include them before launch.

Conclusion

Is this important? As long as the tool works everything else is just icing, right? Well no. Lack of usability will make the system difficult for end-users to learn and use, resulting in lower up-take of the CMS, or the rise of unauthorised workarounds.

And these tips are just the start, the obvious things. They can help you improve the usability of the admin end of your website but perhaps it’d be better to choose better in the first place. Concentrate on the key things that need to be done and don’t get caught up in “featuritis” or go over the top with future-proofing (ie including requirements for things you might use one day). Make sure the CMS you’re considering does the key things well, possibly using scenarios to evaluate products. If you need to customise—particularly the user interface—then make sure this can be easily done and doesn’t interfere with upgrades in the future. There should be independence between the user interface and the system.

[Photo courtesy of Brymo]

Related posts:

1. Cultural probes and magic things
2. Intranet (re)design wrap-up
3. User-centred doesn’t equal success

Why is this? I’m not sure. I find it frustrating when people run around in tiny circles trying to conjur a solution to something whilst wearing blinkers to other sectors, industries or fields or expertise that have already found a solution. A great case in point is the borrowing of psychology, anthropology and other scientific methods by those practising user experience and web design. It’s not new, but I find this stimulating, and I actively look for good sources of knowledge to cross-pollinate from one field to another.

So I’ve decided to collect references to this cross-pollination.

One I found today is Lessons for User Experience Consultants from Barack Obama:

That said, there are a few lessons from Barack Obama’s campaign that apply to our world of user experience consulting … Lesson 1: Use Clear Calls-to-Action … Lesson 2: Put a Priority on Creative … Lesson 3: Make Personal Connections (Or At Least Fake It) … Lesson 4: Don’t Let The Man Throw You Off Your Game … Lesson 5: Set Up Shop in Chicago … Lesson 6: Be Young, Charming, and Good Looking

(Can’t argue with lesson 2, by the way, the Obama brand was very well executed.)

Feel free to suggest more, leave a comment below.

Related posts:

1. Intranets: the beast we love to hate
2. So you want to be a user researcher?

I was watching Jamie’s Ministry of Food last night and thought that his “pass it on” model would be great for propagating user experience skills. We teach our colleagues—who work in other disciplines—some basic UX skills, then they teach others, and so on and so forth. Start with the basics, then work up to more advanced topics.

Before we know it we’ll have a whole bunch of people who not only appreciate the importance of usability (and related concepts) and give it the attention it deserves, but whom can also get on with some of the work themselves. Thus the exponential “trickle down” or “snowball” effect could alleviate the reliance on consultants, contractors and specialist practitioners, as well as putting the necessary skills right at the heart of the problem throughout the process (because essentially everyone would be the “UX guy”). It’d be a lot less expensive than formal training courses too.

This approach could be supported by mentoring and providing the equivalent of the “Food Centres” that Jamie uses. I imagine this could be in the form of a central, online resource with more information for both ‘teachers’ and ‘guests’ to refer to.

What do you think? Is this any different to teaching cooking skills?

[Diagram courtesy Misterteacher]

Related posts:

1. So you want to be a user researcher?

So many people have extracted lessons from Gordon Ramsay’s style, from management to consulting (for instance there’s me, Ruth, Donna, Craig and even The Australian) that it’s becoming boring. He’s obviously good value, but I’m now looking elsewhere for analogies.

Sticking to the reality TV theme, though unintentional, bears much fruit and I can’t think of any better example than Trinny and Susannah. I think they are brilliant at what they do, without having to drop the F-bomb every few seconds (don’t get me wrong I don’t mind Gordon’s profanity but it does make him less accessible).

I first happened across Trinny and Susannah (T&S) in their UK show and series of books “What Not to Wear”, where they gave ordinary people fashion tips tailored to their body-shape, lifestyle and budget. For those of you not familiar with the duo, this isn’t your typical fashionistas spouting on about “What’s hot this season, darling”, it’s honest and useful advice for real people. And it goes much deeper than vanity, most often the cause of the problems they solve are the emotional hang-ups we all have inside. They make people feel good about themselves and accept who they are.

Since then they have continued to help people across several more TV series, as well as across the globe. Theirs is an excellent model for consultants, with core traits such as:

• Working as a pair, they balance each other out
• Breaking it down into simple rules we can understand
• By exposing themselves, literally and figuratively, they foster trust and empathy
• A true desire to help others
• Ruthlessly forward, there’s no room for shyness, excuses, self-denial or apathy
• A simple process: research, understand, extract, boil down, try, validate, rollout

The process I speak of in the last point, was well documented in the more recent series “Trinny and Susannah Undress…”, where the girls showed that their approach can scale too. Doing some very ethnographic-like formative research around a particular problem, they extract insight and develop their rules, followed by application of the results to thousands of people. A series of huge publicity stunts for the BBC, no doubt, but this is consulting on a level rarely seen (and with genuine results).

I think possibly the most interesting aspect of their approach is the development of rules. This is what makes their work so accessible; anyone can get simple and straight-talking advice that suits them. What colour combinations go together? What choice of clothing hides this, or accentuates that? What colours go well with my complexion?

I’ve even done this myself, making use of the rules for guys-without-six-pack-abs and it works. In fact T&S’s work with men is probably the best of all, because if there is anyone who needs simple rules to supplement bugger-all fashion sense it’s the male population.

Related posts:

1. Cross pollination of knowledge and methods between fields
2. Gordon Ramsay is a great consultant
3. Intranet Super Nanny

This “live-in” method gives you 24-hour access to experienced childcraft nurses and allows you to concentrate fully on the task of parenting without the distractions of cooking, cleaning or going to work. It’s the perfect opportunity to master the necessary skills, with expert support at hand, should you need it. It’s a very effective method.

They demonstrate techniques in a realistic environment, as opposed to a classroom or conference hall. They observe how you handle situations, and attempt to adjust your behaviour as necessary (after all what we’re talking about is a change in attitude, awareness and behaviour, not a fundamental change of the game).

The nurses’ intervention reduces from near 100% at the start, down to a bare minimum by the end of your stay. This serves two purposes, at the start they give you a break by taking the reigns for a short time, which is crucial in terms of ensuring the sanity of parents and the effectiveness of the learning. Additionally, reducing this intervention is crucial to getting parents to a point where they can go home and successfully continue using the practices they have learned, on their own.

Throughout your stay, of course, the nurses are always on hand should you need them. They give that all important advice, at the crucial moment it’s needed. This is really important, because by allowing any time to pass allows for post-rationalisation and self-denial. Getting help at that point when things get unstuck also increases the likelihood of remembering what to do.

This live-in approach really struck a chord with me, and I started to consider how it could be used in other fields of expertise. I think it would be an absolutely great model for consulting, and more specifically mentoring. At least in my field, which is information architecture, user centred design and information management.

Techniques and guidelines, no matter how simple and refined, can’t give you the wisdom to know how to apply them to all situations that might arise. Raising a child is complex because life is complex, but many work situations people find themselves in are very complex also—such as managing an intranet, redesigning a large website or any number of major IT projects. This is where mentoring has much to offer above and beyond training or the self-taught approach.

I’ve long thought that mentoring is best done in-situ (in my presentation on Mentoring Collaborative UCD I concluded that an in-house mentor works best) where the team being mentored has access to their mentor’s advice as and when it is needed. Additionally, it should be face to face. Having to call or email your mentor, or wait for them to come in for a meeting, really stifles the inherent intimacy that mentoring thrives on. My experience is that even a relatively small physical distance, such as a taxi ride away, reduces the effectiveness of mentoring.

A traditional consulting engagement doesn’t allow for this, but there are some relatively common tactics to improve the situation. Such as clumping together several visits into one whole day, but this lacks the impromptu nature and feels slightly forced and hypothetical. If you tackle problems when they occur, the better the results are.

Another alternative could be the use of a contractor, to supplement the team. While many contractors and freelancers would have the skills and experience in their particular field to be mentors, they typically aren’t hired to do so and of course don’t have any motivation to go beyond their remit. Contractors are usually hired to perform a specific piece of self-contained work, with little “leave behind” for the rest of the team. To approach the live-in model, they would have to actively coach the team in which they are embedded, but also gradually reduce their intervention.

A ‘day stay’, where the mentee comes and works in your office, is another approach. This gives the access to their mentor, and is close to the Tresillian model. However, most often in my work, the mentee is more than one person, so to be truly analagous to the live-in model, the whole team would need to come and live in the mentor’s facility. While you would gain the same benefits, primarily the elimination of distractions, it just wouldn’t be practical to do so (plus who wants to have a sleep over with their work colleagues?!).

This arrangement would also share the potential problems with the Tresillian model, which is the fact that once you leave their facility you may not be able to match your success once you get home. The very nature of taking the problem to a controlled (or semi-controlled) environment could jeopardise its success; practicing any technique is more difficult in your day-to-day environment.

But if we reverse the scenario, it may be viable. That is, the mentor becomes part of the team being mentored, for a length of time, and operates as part of that team. This is a longer interaction than normal consulting would allow, and something akin to secondment, but more flexible. It needs to be long enough to ‘get into the thick of it’ and practice techniques in a realistic environment with realistic situations. And this is definitely such a thing as too early. Like an advanced workshop or master class, you need to have a bit of distance under your belt. In the case of parenting you need to know your child and what works and what doesn’t, and as with most things, you need to give it a genuine go yourself, before seeking help.

This may be a common approach to consulting or mentoring in certain fields, but it’s not as widespread as it could be, in my experience. Especially considering how powerful it is as a form of up-skilling. I’ve not come across this in web design, IA or UCD fields, but I’d be interested to hear if anyone has used such an intensive, live-in approach to mentoring, as either the mentor or mentee.

Related posts:

1. IA mentoring podcast
2. Gordon Ramsay is a great consultant

Yesterday I attended the half-day WIPA Usability and Eyetracking Seminar, and found it fairly good use of a few hours of my time. Largely because it helped confirm some things in my own mind.

First up was Challenges for Usability in Agile Development presented by John Eklund of UX Research. There has been much talk about agile development methodologies in recent, and probably as much talk about how user experience practitioners can remain valuable in such an environment.

To paraphrase John, my summary of the discussion is as such:

• Agile is about “bringing design forward” (I like this definition)
• It’s about less documentation and specification up-front
• Acknowledge that requirements will not be fully correct, complete or fixed in stone; learn to live with it rather than boxing requirements gathering into one neat discrete step that must be finished before anything else can begin
• Agile is also iterative or incremental development
• Partial prototypes help elicit requirements and specifications from the client
• Clients rarely read spec documentation and often can’t articulate what they want until they see it (you know it’s true!)
• Creativity is less bounded by specification when the specification is yet set (this is not just in terms of visual creativity but also the overall design directions)
• For UX to fit into this methodology it needs to be embedded, flexible, fast and practiced by an experienced practitioner
• For best results in agile environments, UX expertise should be independent of designer (and client)
• Additionally, UX practitioners must play the “expert advocacy” role (providing ad-hoc advice on simple issues without the need for a costly ‘engagement’ or bulky reports)
• Generally faster turn-around is needed for activities like usability testing

I enjoyed John’s perspective on this topic, and a few of his points in particular are closely aligned with my own views on UX practice. I’ve used mentoring in the same way as John’s “expert advocacy” where UX or IA expertise is bought by the hour, allowing for much greater freedom to add value to the design team without having to get approval for a project each time they want to ask a question.

Next up was Eyetracking – Applications in Digital and Media by Peter Brawn of Eyetracker. I was impressed by Peter’s presentation of eyetracking as part of UX practice, as opposed to how I have seen it pitched in the past (that is as the answer to all your problems). This makes sense, since there is a lot that gaze paths and fixation data can not tell you about the usability of a website, and vice versa there are some things you can’t really get out of traditional usability testing and ethnographic research techniques.

For example, a certain section of a website is not receiving much traffic. Usability testing might tell you that users are interested in the content in that section, but perhaps not why they aren’t getting to it. Eyetracking can tell you that users simply don’t look at the obvious, big, fat link that goes to that section, but not why they don’t look at it. Combined you are getting a more complete picture.

That said, I still believe that, dollar for dollar, other methods are better value than eyetracking. For the cost of the hardware and software (or consultants to do it for you) quite a lot of low-tech testing and research could be done. Ideally, you’d do both, but going back to John’s topic, if you want to ensure UX keeps its foot in the door in agile environments—or any other—the approach needs to be lean, mean and cost effective.

I do understand that many clients want the snazzy visualisations you get from eyetracking, not to mention the snob value, but this is only going to be realistic for big corporate clients. Smaller clients should save the cash and use other methods.

Related posts:

1. Agile is like ABS
2. Putting the cart before the horse
3. Stop calling it usability testing

To others, these concerns might seem ridiculous, because for some agencies and freelancers the only relevant pre-bid concerns are 1) is there a slight possibility that I can do the work? and 2) can the client pay? For these folks, nothing else is relevant to pre-bid discussion. The likely result of this foolish approach is a succession of nightmare projects with only periodic success, and a stressed-out and unhappy life and/or staff as the norm.

I know exactly what he means. There have been quite a few times I have wondered why we—the agency I was working for—were even involved in some projects. But in recent years, I’m happy to say that there was more careful consideration given to the work that was taken on, particularly which tenders and RFCs to respond to. In fact, my ex-colleague Cairo Walker developed a set of criteria, or questions to be asked of clients, for this very purpose. (Perhaps this knod her way will entice her to post her thoughts on the subject!)

I like Andy’s approach, but I think many organisations will come face to face with the issue of branding. Not the pretty logo they use but who they are and what they want to achieve—their values. Without a clear sense of this, determining whether a potential client is in-line with your brand will be difficult. The logistics such as budget and schedule can be assessed

All in all, I would recommend we all do more of this vetting, whilst fully admitting that I’m not the best when it comes to this; I have a terribly bad habit of attempting to diligently do whatever anyone asks!

No related posts.

While it has been quite an experience, it is time to move on and experience something else. My immediate move will be to join the team at News Digital Media. I’m looking forward to it, especially to the change in pace and surroundings, and working with a great bunch of people. In many ways it will be a return to the sort of environment I had worked in for many years prior to coming to Step Two.

So, next after Step Two—the third step as it were—is News. I start next Monday and I can’t imagine it will be long before I’m rubbing shoulders with uncle Rupert himself. You don’t suppose he monitors the blogosphere do you? :)

No related posts.

Often it’s difficult to tell exactly who is using an intranet, and how they are using it. Obviously, some research is required to help answer these questions, but what technique can capture the tacit knowledge without shadowing users in an uncomfortable and expensive way?

A relatively recent research technique that can be very useful in this situation is known as a ‘cultural probe’. In essence, the technique involves getting users to give you information without you actually being there. Often this means giving them a diary to write things down in, but the technique can make use of all manner of objects.

I think there are many benefits to this technique for those designing, or redesigning, an intranet. Firstly, it’s often the case that intranet teams are working with very little budget, and thus including all user groups—say interstate or overseas—in research activities can be next to impossible. Sending out a probe which can collect data for you at low cost is a good solution.

It’s also a great way to reduce the ‘Hawthorne effect’, that is the effect you will have on those you are researching simply by being there. This effect is especially difficult for intranet teams to avoid, since they are often researching their own colleagues. It’s hard to blend into the background when you know everyone in the room! External consultants have it easy when it comes to quietly observing or doing contextual inquiries.

I really like the cultural probe technique, especially the sorts of whacky and creative things done by design researchers such as Bill Gaver. These might be a bit ‘out there’ for the corporate environment, but certainly get your attention.

(I’m interested in case studies that describe the use of probes, particularly ‘inside the firewall’. Have you probed your enterprise? What did you find?)

Related posts:

1. Cultural probes and magic things
2. OzCHI tutorial: cultural probes
3. A summary of user research methods