Does your business need an information architect?

Although the focus of my career has remained largely consistent, my job title has changed and evolved. This (I believe) is largely to reflect the needs of the host business. Often the business will place value on one particular nuance of my role.

For example a ‘usability engineer’ will be expected to write reports based on user feedback of a given prototype. This might be necessary because historically, the user interface is produced and executed by your developers yet they don’t have the time to evaluated their output. The term ‘engineer’ also reflects that the business has an engineering bias.

Similarly, a ‘creative director’ might work amongst a number of design focused roles such as interaction designers or visual designer. This perhaps reflects a businesses design focus. Its more likely to be a customer facing brand and the user interface could be developed via an off-shore team. Hence the need to document the intent of the business and user as accurately as possible.

More recently, I have had an increasing exposure to the job title ‘information architect’. I suspect some of you will have heard about this role. Some of you may feel that you are doing that role as part of your current job title and others maybe conducting elements of this role without realising.

The information architect role is nothing new. Indeed this practice has been around for hundreds, if not thousands of years. Perhaps the classic example project being Melvil Dewey’s ‘Dewey Decimal’ system which was conceived in 1873 in order to organise vast libraries of books. The system was widely adopted throughout the world and is used to the present day. I have no doubt that you will have encountered the Dewey system at some point in your studies.

Once you appreciate the Dewey system you will know that books are organised by theme and you will also know that themes are normally arranged in collections on specific shelves. This means that when you are looking for books on African Arts, you are likely to see other books which are also related to the same topic. This increases the chance of what we call serendipitous discovery. In other words, the chances of finding an answer from an unexpected source is greatly increased because of the way the books are organised.

The obvious value in having an information architect in your company is to provide a system like this which organises the information your staff or users utilise on a daily basis. This system should be intuitive and understandable so that anyone can quickly complete their goals – reducing time, effort and therefore increasing profits. The system should also extensible so that it adapts to the growth of the business. Therefore, an information architect will require a good understanding of the business goals in order to establish a flexible and long lasting solution.

In the O’Reilly book on ‘Information Architecture’, Peter Morville and Louise Rosenfold outline seven reasons why ‘why information architecture matters’ to organisations:

  1. The cost of finding information
  2. The cost of not finding information
  3. The value of education
  4. The cost of construction
  5. The cost of maintenance
  6. The cost of training
  7. The value of a brand

However, in recent years I feel that the term information architect has been overused and perhaps watered down. Why do I believe this?

Firstly, I often hear of organisations with more than one information architect. Indeed sometimes I hear of organisations with teams of information architects. Imagine if you will, a team of five information architects working on the Dewey system. How do you know that each of those architects will place African Art books in the same group. Indeed, how do would you know that every information architect will name that label ‘African Art’. One might label it ‘World Arts’, ‘South African Arts’ or ‘African Arts & Crafts’? In short, it is the definition of the system which is key and having more than one person working on a system although not entirely impossible, progress will be painfully slow. It is because of this I do not believe any company with more than one information architect is actually providing the true service or impact of an information architect.

My second reason, is around the question of which organisations require the skill of an information architect.

Think about organisations who deal with large numbers of disparate items. Amazon sells numerous types of products, each classified under very different themes or groups. If the items did not appear under the expected labels, the user would not find the product and the retailer would forego a sale.

Google’s search engine uses algorithms which classify and label search terms. If the themes were not recognised the search results would be entirely irrelevant to the user. They would not click the link and Google would not generate revenue.

Utility companies (such as Gas and Electric suppliers) with thousands upon thousands of customers will need databases to record their customers. The marketing department may wish to use this information to promotes a new tariff to customers who have been on a specific tariff for for more than two years (i.e. loyal customers).

Its the way this database is structured and accessed which will allow its internal staff to communicate with this audience in an efficient manor.

So there you have three examples of organisations who do require the skills of an information architect. They all manage large amount of disparate data with one or more key users (internal and/or external). They require an understandable system in order to make sense of it.

But here’s my concern. Many of the companies using information architects do not have demanding set of deep and disparate data. More so, many of the companies I see using information architects are actually using them as interaction designers.

Graphic design is NOT information architecture

Software development is NOT information architecture

Usability engineering is NOT information architecture

A quote from ‘Information Architecture’ by Peter Morville and Louise Rosenfold

Some organisations are using information architects to solve high level concepts via the user interface – in other words by producing wireframes for a website and stumbling across the labelling and taxonomies as they proceed. Designing page by page and then going back to edit each page as they learn more about the complexities of the system.

There are numerous problems with this approach. Firstly you only see the parts of the architecture which are visible to the use in any given state (The ‘iceberg’ issue). Secondly, you won’t be able to build themes or access all dependancies. Thirdly, it is an inefficient way of working.

To further the quote above, I strongly believe that interaction design is NOT information architecture. Information architecture has an entirely different focus to interaction design plus you won’t necessarily need a dedicated information architect in order to conduct the work. You may already have someone ideally placed in your organisation who can conduct this role with ease. What really matters is that they know the business and the given audience inside out.

So if ‘IA’s don’t really need to produce wireframes, how do information architects conduct their work? In order to establish understandable labels, themes and hierarchies a true information architect will use user research methodologies such as card sorting or website analytics to establish behavioural insight of the intended audience. They will ultimately produce heat maps and matrixes of data perhaps using spreadsheet applications such as excel or numbers. An information architect will rarely touch a wire-framing or prototyping tool, unless they are attempting to present  and promote high level concepts (i.e. via Venn diagrams etc).

For organisations who deal with disparate data, information architecture can be key to your growth and success and whether your business employs an information architect or not, its worth reviewing your methodologies or your job specs to establish: (A) could my business be more profitable with more structured data system and (B) what skills/insight do I have or need to create an appropriate solution.

Posted in Internet, User experience | Leave a comment

A designer without a portfolio?!

My old design portfolio

This was my first portfolio. It is a beautiful leather-bound A2 size folder with a number of glossy leaves inside. Each leaf has a mounted presentation of a project, painstakingly printed, cropped and mounted by my own fair hands. This example even has hand-crafted embossing!

It was not an easy item to produce, but of course at the time (1999) I was a student looking for my first tentative steps into the design world. My objective was to express my fascination with all things visual and hopefully impress potential employers with my fresh unobstructed (ok, perhaps naive) view of the world.

…and of course it worked. In fact, before my graduation, I had landed my first job as a web designer for the Daily Telegraph..however, from that point onwards my portfolio gradually became a stress point rather than a labour of love.

Why? You might ask.

Throughout my career, I have chosen to work in-house for large corporations. I love business as much as art. When I was a student I loved watching the BBCs ‘Working Lunch’ and these days I never miss the Bottom Line on Radio 4 or Newsnight on BBC2. My fascination with business (in my view) makes me a stronger strategic designer because I can quickly appreciate the business models or return on investment of a given project. Plus, I love sticking around to see if my designs actually improved the situation of a business…and if they don’t, learning about that scenario so that I can correct it and avoid the same mistakes in future projects.

I feel strongly that UxD/IxD is a business tool, yet there is an inherent danger with visual communication that we aesthetically please companies rather than change them for the better. Designers, more than anyone else in a business have the power to propose and influence the direction of a company by simply anticipating an interactive experience which responds to a stated mandate.

Of course, if you are a junior designer or with a visual branding bias, this becomes an important aspect of your work. But here’s the problem: projects fail. Not only that, projects fail often. It leaves anyone who worked on them feeling unconfident, under appreciated and under utilised. Anyone who has ever designed for a business in-house knows that interactive projects never follow a strict path from conception to reality. There are other forces at play, such as technical constraints, project budgets, in-house skills, competitors, marketing and yes, stakeholder support.

So as an in-house designer we can react to this in two different ways:

  1. Create a set of visual designs which inspire a ‘I want it’ answer from a high up stakeholder and risk producing a project which fails.
  2. Or, change the way we operate.

This change is what Don Norman coins as being a generalist’.

What use is a ‘beautiful’ user experience to a company that can’t deliver it? Real designs are about influencing change in real scenarios, with real constraints. Businesses need designers who are effective communicators able to work collaboratively with multiple disciplines. Not just purely creative types who objectively beautify a given user scenario.

My experience of ‘purely creative’ designers is that they rarely last any length of time in a given organisation. They become either frustrated by their desire for creativity or the business finds that they add little value as they are not in sync with the project team.

So, coming back to my portfolio. If I was to show my current work in a curated portfolio it would fail on my desire to show projects which are aesthetically pleasing and may only demonstrate the vulnerabilities of the current business. For example, on a recent project I proposed using ‘relative’ times for users (i.e. this happened 5 minutes ago) – which is obviously the correct thing to do in terms of user experience because you significantly reduce the ‘don’t make me think‘ mental overhead (thank you Steve Krug). BUT, during the project we established that we could only update this time attribute every hour due to limitations of how often we can retrieve this data. This is a really important assertion, because I can now revise the ‘relative’ time to a straight forward time stamp – which is a more realistic business solution and more likely to win support in the development team. I am continuing the ambition for business change rather than increasing the potential of another project failure.

In summary, in-house design has to embrace the realities within a given business which means you have to make a number of considered concessions to the user experience in order to ensure the project does not fail.

Explaining this story in a visual design portfolio is (in my view) unrepresentative of the work and considerations I have put in to the project. As an experienced interaction designer, I never want to be judged on the final design alone, I want to be judged on the considerations I have made and the impact of the change on the business.

One final point to consider. Companies looking for an IxD or UxD are deluded if they believe candidates will create a bespoke portfolio specifically aimed at their business. Recruiters control the flow of potential candidates and that means that candidates will have next to no time to pull together a relevant portfolio. Indeed, I don’t believe that most in-house designers going for interviews are actually interested in getting a new job. At best, most will be tentatively understanding what else is out there in order to establish ‘best fit’. In short: it’s a two-way street so get the ‘who are you’ conversations out-of-the-way and then set them a realistic project task. You’ll soon find out if they are serious.

Posted in Business, Design, Leadership, User experience | Leave a comment

Embracing failure

Creating a culture where failure is a necessary and essential part of  product development can greatly enhance the collaboration and motivation of your team. This blog post on Neil Gaiman’s blog sums up this spirit up better than I ever could ever hope to.

Enjoy…

I hope that in this year to come, you make mistakes.
Because if you are making mistakes, then you are making new things, trying new things, learning, living, pushing yourself, changing yourself, changing your world. You’re doing things you’ve never done before, and more importantly, you’re Doing Something.
So that’s my wish for you, and all of us, and my wish for myself. Make New Mistakes. Make glorious, amazing mistakes. Make mistakes nobody’s ever made before. Don’t freeze, don’t stop, don’t worry that it isn’t good enough, or it isn’t perfect, whatever it is: art, or love, or work or family or life.
Whatever it is you’re scared of doing, Do it.
Make your mistakes, next year and forever.

 

Posted in Business, Design, Leadership, User experience | Leave a comment

Experience Success Criteria

Experience Success Criteria – My guest post for Firehoop

Posted in Internet | Tagged , , , , , | 2 Comments

Learning Ruby on Rails: Starting out

Over the years I have developed a deep interest in web development languages. I am in no way an expert, but I do have an complimentary appreciation of most front end technologies. I feel this is essential skill when working with engineers on a daily basis.

However, one of the big mysteries to me is the stuff that happens before the front end technologies such as HTML, CSS and JavaScript; namely the middleware and database layers. Whilst I have a basic appreciation of object oriented languages such as C++ plus scripting languages such as PHP, I confess I don’t know enough to give me a leg up to establishing those quick wins in a project team.

I am going  to change this by learning Ruby on Rails.

But why rails? The engineering team at Symantec.cloud use the MS dotnet framework, so this might seem a slight tangent. Rails is advertised as quicker way to deploy web apps, with rails scaffolding providing the magic and power to make stuff happen with relatively little effort.

So this means, its a language which I am more likely to develop an interest in over a long term – since I can create apps easily on my own, plus its a little more cross platform and relevant whatever machine I may be using next.

My objective is to develop a bespoke wedding RSVP application. Before the end of January 2012. At the moment, I’m not sure if that is a ridiculous objective – but it gives me a challenge and something to work towards.

To aid my progress I have purchased two items:

Huw Collingbourne’s exellent Learn Ruby Programming (in ten easy steps) screencasts (with a fabulous welsh accent) at Udemy and Michael Hartl’s Ruby on Rails Tutorial, which I have purchased via my Kindle.

For the moment, these two resources have given me more than enough challenges, but I have no doubt that I will need more in the future.

One thing I have found is that the setting up the initial setup has been a major headache: Heroku is (by default) incompatible with Windows, you can’t upgrade Ruby on MacOS unless you have Apples XCode installed, the RVM command is only available on Unix based machines. The list of challenges to a stable and working development environment seems endless…but I’m working through them one by one, with Google as my friend.

The bigger question for me is this. How will my knowledge of Ruby on Rails assist or improve my appreciation of user experience. Will it make me a better designer? Or will it simply distract me from the core principles of user/people-centred-design? The jury is out.

In the meantime, if you have any additional resources which may assist me, please leave them in the comments below. I think I may need them!

 

Posted in Ruby on Rails, User experience | Leave a comment