Author: James Robertson

At the IA Summit in Vancouver, James became known as the "intranet guy", and if the shoe fits... James runs one of the leading intranet consultancies, and happens to be based in Sydney, Australia. He's published a number of reports, covering search, intranet strategy, staff directories and content management systems. James has also written over 150 articles on these topics, as well as presenting at conferences across the globe. He's also getting serious about his photography, with plenty of photos on Flickr (www.flickr.com/photos/shingen_au). Oh, and he has a blog, which he posts to in the mornings while his brain is still warming up...

Demolition Derby

by: James Robertson | August 16, 2007March 10, 2019

Before I even opened this book, I had three reasons to like it. First, Scott Berkun is “one of us”. As a former Microsoft project manager responsible for overseeing early versions of Internet Explorer, he has a strong background in usability, information architecture, and design. His first book, “The Art of Project Management“:http://tinyurl.com/37q6j9 (also “reviewed”:http://www.boxesandarrows.com/view/the_art_of_project_management on Boxes and Arrows), might have been more appropriately titled, The Art of Project Management for Design-Intensive Projects. You might also know Berkun as the creator of the “Interactionary design contests”:http://www.uiweb.com/dsports/interactionary2001.htm held at “ACM’s SIGCHI conferences”:http://sigchi.org/conferences/. He comes from our world and many of his examples are drawn from individuals and organizations familiar to the IA and UX communities. Second, on a more personal level, the book includes two of my photos: See the title pages for chapters 5 and 6. The inclusion of these photos resulted from a request on “Berkun’s blog”:http://www.scottberkun.com/blog/ calling for Flickr-based photos, with two being plucked from my current collection of 3000+ images. Very exciting! Finally, The Myths of Innovation is a short, light book and a handy airplane read. Enough said.

The importance of innovation

Innovation is a hot topic at the moment. Actually, innovation has been a big thing for last hundred years or more, but perhaps we needed the profusion of business magazines and books to bring this observation into sharp focus. With the tech sector on the ascendancy (again), driven in part by the Web 2.0 movement, examples of innovation are everywhere. We’ve moved beyond the notion of the knowledge economy to recognize that innovative ideas can be the foundation for disruptive business models. This factor makes Berkun’s book timely, as it sheds light on the underpinning truths that surround innovation. This is what the dust jacket promises:

In The Myths of Innovation, bestselling author Scott Berkun takes a careful look at innovation history, including the software and Internet ages, to reveal how ideas truly become successful innovations–truths that you can apply to today’s challenges.
Using dozens of examples from the history of technology, business, and the arts, you’ll learn how to convert the knowledge you have into ideas that can change the world.

So, does it deliver?

Debunking myths

To explain how innovation works, Berkun starts in the opposite direction and first exposes ten commonly-held beliefs about innovation:
1. The myth of epiphany
2. We understand the history of innovation
3. There is a method for innovation
4. People love new ideas
5. The lone inventor
6. Good ideas are hard to find
7. Your boss knows more about innovation than you
8. The best ideas win
9. Problems and solutions
10. Innovation is always good

In each chapter a myth is introduced and then progressively unraveled and debunked with great wit and charm. This approach helps to structure the book and it offers an easy way to explore innovation. Berkun has a fluid writing style and finds the right balance between informality and powerful word-smithing.

Berkun uses a range of examples from the Renaissance to eBay and Craigslist. Each case study is carefully researched and accompanied by footnotes pointing to further reading. In many instances, Berkun takes unexpected angles on historical cases, presenting new perspectives on stories that have been told and retold for more than a generation. For example, most people are familiar with the story of Post-it notes: The 3M miracle product that evolved from a glue that didn’t stick properly. Far fewer know about the product that preceded Post-it notes (masking tape), and the company’s corporate history. 3M actually stands for Minnesota Mining and Manufacturing and the company started out drilling for underground minerals to manufacture grinding wheels. It was only after a lab assistant needed a way to mark borders for two-tone car painting that masking tape was developed and the rest became history. Another example explores the challenges in getting the telegraph adopted and how the company built on that discovery, Western Union, eventually became the protector of the status quo when new innovations came along–namely the telephone.

Through these examples, Berkun demonstrates that while inventions seem inevitable after the fact, the path to adoption is almost never certain. Great ideas fail, while commercial imperatives drive the success of other innovations.

Providing answers

Readers looking for an innovation checklist or a how-to book will be dissatisfied. One of the myths that Berkun debunks is that there can be a step-by-step guide to innovation. Instead, innovation is a complicated and unpredictable process with many paths–more jigsaw puzzle than a straight line. By its nature, innovation explores uncharted territory. It is also the product of a lot hard work, unexpected insights, the collaboration of many individuals, and sheer, random chance.

When I reached the end of the book, I was disappointed to discover there was not a summary chapter wrapping up its message; something akin to, “So therefore, based on these myths, this is how you need to do innovation in practice.” While a concluding chapter would have neatly closed the narrative arc at the end of the book, Berkun was right not have included one. Instead, the onus is on the reader to review the book again and allow the many gems scattered throughout the text sink in more.

In particular, Berkun outlines a number of key principles and barriers to innovation. They are presented in unassuming lists that belie their value. For example, he outlines eight challenges all innovations must confront and overcome, including sponsorship and funding, capacity for reproduction, and reaching the potential customer. In addition to these challenges, Berkun discusses elements that can influence the speed of adoption, challenges associated with managing innovation, and factors that have influenced historical innovations. Berkun also offers a comprehensive set of checkpoints that can be used to assess approaches to innovation.

What we can learn

There are many heroes idolized within our industry, whether it’s Flickr, eBay, Craigslist, 37 Signals, IDEO, Yahoo, Google, or any of the hundreds of Web 2.0 businesses. All of these organizations are regarded as paragons of innovation, featured prominently at conferences and in case studies. Berkun points out that while much can be learned from these organizations, the myths that surround them can also blindly lead us down the wrong path. If we recreate the funky, fun-filled spaces of the Googleplex, do we automatically become innovative? If we develop functionalities that mimic Flickr, will we be able to take on the world?

When starting down the path of innovation, we must do more than just blindly copy the formulas so neatly captured and communicated from these leading companies. Yes, we would like some measure of their success, but we would do better to learn from the myths outlined in this book. When we are establishing our design teams, building our startups, or consolidating our consulting firms, we need to consider the ideas presented in The Myths of Innovation. The lessons I took away from the book include the following:

Good management has a huge impact on the success of in-house innovation.

Innovation is paired with collaboration.

The best outcomes derive from a mix of self-awareness and the ability to recognize and explore opportunities when they arise.

Oh, and the need for perseverance, no matter how hard the road ahead.

The universal principles and insights captured by Berkun certainly apply to design and user testing. On page 66, Berkun makes the following observation:

“[Innovators] grow so focused on creating that they forget that those innovations are good only if people can use them. While there’s a lot to be said for raising bars and pushing envelops, breakthroughs happen for societies when innovations diffuse, not when they remain forever ahead of their time.”

Information architects, therefore, have an important role to play in innovation, particularly when making use of ethnographic research techniques. At the end of the day, we don’t win awards for demonstrating how smart or creative we are if no one chooses to make use of our wonderful new innovations. The more we understand our users or customers, the better we’ll be able to create innovations that make their lives easier. Innovation doesn’t happen in isolation, nor is it the result of being struck by a falling apple (or even a falling Apple?). Innovation occurs in the real world, drawn from an understanding of needs, and delivered through a design process that makes the idea into something that will change the world. This is where IAs can contribute.

Conclusion

I started The Myths of Innovation in a positive frame of mind, generated by my interest in the topic (and the excitement of seeing my photos in print). I ended the book similarly enthusiastic. While it isn’t a long read (I started in Cambridge and finished before I touched down in Los Angeles), good books don’t need a lot of words to make their point. Scott Berkun clearly presents his arguments, demolishing many of the misconception about innovation. For those of us running businesses or developing new products, it’s a must-read.

About the Book
“The Myths of Innovation”:http://www.amazon.com/Myths-Innovation-Scott-Berkun/dp/0596527055/boxesandarrows-20
Scott Berkun
2007, O’Reilly
ISBN-10: 0596527055

Authors note: If you want to view more of my book-worthy photos, you can find them on “Flickr”:http://www.flickr.com/photos/shingen_au, or on the site from “my first photography exhibition”:http://www.artbytwo.com.au/index.html.

Enterprise IA Methodologies:

by: James Robertson | April 17, 2007

Information architects working within enterprises are confronted by unique challenges relating to organisational culture, business processes, and internal politics. Compared to public website or interface design projects, key aspects differ in the application of IA discipline relating to uncertainties around the exact nature of the business problems being solved.

In a typical web or design project, the information architect is given a task, such as:

Improve the design of the website for consumers
Develop a user interface for a new business application
Make it easier for staff to find information on the intranet

In all these cases, the problem is known, and the challenge is to work out the best way to design the solution. User-centered design methodologies then provide a rich toolbox for delivering an effective solution.

However, within the enterprise space, the problem to be solved is often not well understood. For example, information architects may be approached with ill-defined “problems” such as:

Improve the effectiveness of the intranet
Help call center staff to access required information
Increase the uptake of the document management system
Support sales staff with better online resources

The first task for the information architect in this context is to better understand the problem. Only then can an overall approach be defined, and the normal user-centered design process initiated.

In practice, this means that enterprise IAs often start two steps earlier, focusing first on analyzing needs, and then defining a strategy and scope to meet those needs.

Traditional IA methodologies

Diagram 1: Illustrates a typical IA approach

While there are many valid ways to redesign a website or intranet, most projects start with user research to identify user tasks and goals. Then, the IA uses these results to develop a draft IA, which is tested in an iterative manner. Wireframes detail the user interface, and usability testing or similar techniques are used to refine it.

The overall goal of this approach is to clearly understand what the user is trying to achieve when using the site or system, allowing the IA to develop a solution that is both effective and satisfying.

This much is well understood, and much better documented elsewhere.

Enterprise IA approaches

Within the enterprise, the core user-centered design methodology remains just as valid. However, to be effective, the process must start two steps earlier.

Diagram 2: Illustrates an Enterprise IA approach

Step 1: Needs analysis
The first step now becomes needs analysis, which uses the same user research techniques as in typical user-centered design (interviews, contextual inquiry, observation), but to different ends. This time, we don’t ask questions about the system, but instead focus on obtaining a more complete and holistic picture of what staff do and the environment in which they work.

This might include questions such as:

What activities make up your job?
What information do you need to do these activities?
Where do you currently get this information?
How do you find out what’s happening in the organisation?
What is the most frustrating task you had to complete in the last month?

Rather than support the design process, this research helps the IA understand the nature of the problem. Open-ended and ethnographic, this research will undoubtedly highlight the unexpected and the unknown, both of which radically shape the approach going forward.

(For more on needs analysis in the context of intranets, see my earlier article on this topic, “Succeeding at IA in the Enterprise”)

2: Strategy and scope
The needs analysis then informs the creation of an overall strategy, scope and direction. From this clear framework for the IA work, a comprehensive overall roadmap of the activities required can emerge. The strategy also identifies the most critical issues to be solved, along with the activities with the potential to deliver the greatest business benefits. In this way, the IA work can be targeted for the greatest impact.

In many cases, needs analysis helps the team discover underlying issues which need to be addressed before any IA or design activity can succeed. (Cultural and business process issues are common examples.)

Together, the strategy and scope define the “problem” and provide a concrete context for the user-centered design process. Along with the illumination of the practical aspects of the work to come, the strategy also builds the business case for change and creates a sense of urgency.

A real-life case study drawn from a number of different intranet projects in call center environments illustrates the effects of the enterprise approach.

Case Study: Call Centers

In many organisations, call centers now serve as the primary point of contact with customers or the public. Whether in the insurance industry or within a government agency, call centers handle a huge volume of queries and transactions.

Within the call center, staff work in a high-pressure environment. They are expected to literally answer questions correctly within 30 seconds. Failure to deliver the right information leads to customer complaints or legal liability (organisations are directly responsible for every piece of information given out by a call center). Slow response times can create long queues, more complaints, and customer attrition.

To meet these expectations, call center staff require an effective and well-designed set of information resources. The typical call center intranet contains a large number of documents and news items for staff.

As an information architect, we are often brought into this environment to ‘redesign the call center intranet, to make it into an effective resource for staff. Based on experiences in other environments, it is natural to make a number of assumptions about where efforts should be focused:

The most common questions or transactions handled by staff should be identified
Effort should then be focused on providing resources to answer these key tasks
Paper resources should be migrated onto the call center intranet where possible
A user-centered redesign should be conducted of the call center intranet, to ensure it is effective

Spend a day or two in the call center, and the gap between these assumptions and reality will quickly become apparent. Let’s look at a call center in the insurance and investment industry.

In this particular case, the most obvious non-technical artifact in the call center was the book of photocopied notes that most staff had sitting beside them, scribbled on and annotated with sticky notes. Then there were the sheets pinned to the cubicle walls, similarly inscribed.

Additionally, product brochures adorned everyone’s desk to cover the 30-40 products sold at any given point. A deeper look uncovered the huge amount of email filed away in folders within Outlook.

There were good reasons why the call center worked in this manner:

Customers rang up asking, “On page 54 it says this, but what does it mean?” The call center staff needed to quickly access the same page to walk them through the details.
Key information (such as system codes) needed to be instantly available. Pieces of paper pinned to the wall would always be quicker than looking up an electronic system.
All important communications were broadcast via email, and maybe (only maybe) added to the intranet. Since the details probably were not needed at that point, it was necessary to file away the emails for later use.

In this situation, we drew some unexpected conclusions from these (and other) observations, even having been primed by previous call center projects.

In the end, our efforts focused on:

Managing uncommon rather than common details: The information related to the most frequent queries or transactions resided in the heads of staff. The complex issue that only came up every 6-12 months posed the real challenge.
Capturing old rather than new information: The brochures for the current products worked perfectly well. The real problem came from investment products that could go back decades and were still covered by the original terms of the contract. Finding a 20 year-old printed policy was not easy!
Eliminating email as the distribution mechanism: As long as email remained the primary way to deliver critical information, the intranet could never succeed. There were also clear productivity benefits in eliminating the duplicated information management conducted by every individual staff member.

The net result was that the call intranet still needed redesigning, but the needs analysis gave a very clear idea of where to focus efforts and identified the unique environmental aspects of call centers to be taken into account when conducting any work.

Solving the Wrong Problem

This case study highlights the importance of conducting the needs analysis process before embarking on any design or development activities. Failure to do so exposes the organisation to the risk of solving the wrong problem—putting significant effort into developing a solution that fails to work in practice.

Always assess the issue at hand to work out whether it is the cause or merely the symptom. For example, the intranet may be very poorly structured, with considerable usability problems. This naturally calls for a user-centered design project delivering a new IA and page layouts.

However, the underlying causes of the problem may be the disorganised publishing model, the lack of resources, or key cultural problems. If only the symptom (the design of the site) is tackled, the site will immediately start to slide back into disrepair the day it is re-launched.

A small piece of initial needs analysis work and strategy and scope planning allows identification of these underlying problems. Address them, if possible, before (or during) the project, improving the chances that the site continues to prosper post go-live.

Summary

Within the enterprise environment, our methodologies must start two steps earlier than the typical user-centered design process.

Make use of holistic needs analysis techniques to build a clear picture of the real needs and issues of staff, along with an understanding of the environment in which they work.

Then create a meaningful strategy and scope that identifies the symptoms and the causes. This information allows us to correctly target our work and ensure that we deliver solutions that actually work for staff.

(All of this is not to say that it’s easy to get the opportunity or the mandate to conduct this initial work, before being forced to jump straight into the design process. But it is possible—we’ve done it many times—and a discussion of how to tackle the broader positioning of enterprise IA will have to wait until another article.)

About the author
James Robertson is apparently the “intranet guy,” or so he was told at the IA Summit in Vancouver. He runs Step Two Designs (www.steptwo.com.au), a consultancy based in Sydney, Australia, and has written over 150 articles on intranets and content management, which can be found on his site. He also has a blog, the writing of which gives him something to do each morning while his brain warms up.

Succeeding at IA in the enterprise

by: James Robertson | June 12, 2006

As information architects, the core of our profession rests on the analysis of information, the identification of structure, the creation of taxonomies and site maps, and the development of wireframes and user interfaces. These skills are well-honed, and we play a significant role in the design and creation of many systems, from websites to web 2.0. The real challenge is making things happen and getting users to adopt the new solutions

Working within the enterprise, we are confronted with new challenges. There is a lack of clarity around needs and goals, organisational issues are paramount, and the real challenge is making things happen and getting users to adopt the new solutions.

This is the focus of what is often called “enterprise IA”, the application of information architecture in complex business environments. To be successful in these situations, we need skills and strategies that focus much more on people than on information.

This article explores some of the approaches needed to ensure that we are successful at implementing IA within organisations, with the goal being to encourage further discussion in the community about these issues.

Business strategy At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

More than any other skill set, enterprise information architects need to have a strong understanding of business strategy and planning. With so many possible issues to solve, the greatest success is achieved when activities are designed to support organisational strategy and to deliver tangible business benefits.

In practice, this includes:

Building a strong understanding of overall corporate strategy and directions.
Using this knowledge to select projects that will support organisational goals.
Designing projects to deliver tangible and visible benefits within the organisation.
Developing project plans that will deliver “quick wins” while building momentum for longer-term activities.
Conducting good project management, including working within project constraints and maximising the use of project resources.

At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

Top down and bottom up

Successful enterprise projects follow both a “top down” and “bottom up” approach that combines overall business strategy with an in-depth understanding of staff needs and issues.

This is illustrated in the following diagram:

Enterprise flow diagram

For an information architecture project, this means:

Working with senior management to obtain strategic input, including overall business goals and objectives.
Conducting in-depth research with key staff groups to identify major staff issues and needs.
Using the strategic view as a “lens” to select key activities that both support business goals and meets the needs of staff.
Developing a set of tactical (short-term) strategic (longer-term) activities to deliver improvements to information management within the organisation.

While this is not the only way that an enterprise IA project can be managed, it demonstrates different approaches that must be explored by information architects when addressing complex business problems.

Understanding staff

User research techniques such as interviews, focus groups, contextual inquiry, and workplace observation are well understood and widely practiced by most IAs. While these techniques are important in general IA projects, they are critical for enterprise IA activities.

For a typical website project, the starting point is to define goals, objectives, and broad functionality. Research is then done to determine the best way to design and deliver the solution, with user-centered methodologies driving interface design and site structure.

Within the enterprise, the order is reversed. The starting point, as outlined earlier, is to conduct research with staff. The purpose is to identify the needs and issues of staff, which then helps define the goals and scope of the project.

This research is much more open-ended than typical user-centered design. Staff aren’t asked questions about the intranet, portal or document management system. Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate. In practice, we’re looking for issues and needs that we don’t even know to ask about. (The “unknown unknowns”, to quote a now-infamous speech in the US political arena.)

This approach is much closer to ethnography than user-centered design, and we can learn much from this discipline when working within the enterprise. By building up this depth of knowledge, we can target the most important needs, confident that the solutions delivered will be useful (and used) in practice.

Organisational change

Enterprise IA projects are only successful when delivered solutions are actually used by staff. While this is more certain when solutions are based on an in-depth knowledge of staff needs, a comprehensive change management plan will still be required.

Organisational change becomes a key element of enterprise IA projects. Information architects working within complex business environments need to have a strong understanding of organisational culture and how to work effectively within it.

For example, the greatest enemy of our projects is not active resistance, but apathy. While information problems within the organisation are generally widely known, they are not seen as sufficiently urgent or important to be addressed as a matter of priority.

Enterprise IA projects must start by creating a sense of urgency within the organisation. A strong message and vision must be created for the projects, and communicated widely to build support at all levels of the organisation.

Technology

Enterprise information architects must be prepared to work across technology boundaries. This is about delivering a single user experience that provides a seamless work environment regardless of what technology is used behind the scenes.

This means that enterprise IA projects must at least have an understanding of:

intranets
content management systems
document and records management systems
collaboration tools
applications and databases

This is not to say that enterprise architects need to be technologists or developers. In most cases, enterprise projects will be supported by IT teams and departments that provide specialist skills in these areas.

Enterprise IAs must, however, understand enough of these technologies to create solutions, taxonomies, and designs that help to bring these systems closer together, towards the goal of a single user experience.

Working with others

There are many disciplines that are working to solve enterprise issues, including:

knowledge management
content management
information management
document and records management

There is no one group that “owns” the problem, or has all the skills, tools and resources to solve it. While each group has its own models and metaphors, each successfully addresses at least part of the overall problem.

This is where we need to build our skills in working with others, what Lou Rosenfeld calls our “horse trading” skills. This is not just about working in multi-disciplinary teams, it is about working with key individuals from other teams, business units or even divisions, all reporting through different chains of command.

(This is where establishing a “community of practice” focusing on enterprise issues can be very helpful. This approach is actually drawn from the knowledge management domain, further demonstrating the need for collaboration between disciplines.)

Successful enterprise IAs are those with people skills, perhaps ahead of their specialist skills in card sorting, taxonomies, wireframes, and paper prototypes.

A call to arms

The need to deliver better solutions within organisations is great. When driven solely by technology, enterprise projects almost invariably deliver unusable interfaces and poorly structured information that generates considerable resistance to change.

While information architects are not the only group working within the enterprise space, there is the opportunity to demonstrate leadership in delivering effective projects and solutions.

If this is to occur, then the information architecture community needs to build its knowledge in the areas of business strategy and organisational change. We also need the people skills to work well with many other groups within the enterprise, each of whom contributes some part of the overall solution.

This is not to say that all information architects need these skills. Designing interfaces and structuring information is a worthy challenge, and it remains as the core of information architecture.

Space must be found, however, to discuss and explore the unique challenges encountered within the enterprise. We must recognise that a strategic view is equally important as professional design expertise and enterprise information architects must be supported in their quest for best-practice approaches and techniques.

So much more can be written about enterprise information architecture, and this article merely scratches the surface. It is hoped, however, that it will contribute to the discussions in this space, and to help raise the visibility of issues already being wrestled with by information architects in many organisations.

Final words In an ideal world, information architects will be part of a broader team …. we must understand organisational issues, but are not responsible for resolving them.

All of this is not to say that information architects need to become specialists in business strategy and organisational change. We will certainly not be hired to develop business strategy for organisations (and nor should we be!).

In an ideal world, information architects will be part of a broader team within an organisation that includes change managers, professional communicators and other specialists. As part of this team, we must understand organisational issues, but are not responsible for resolving them.

In practice, however, information architects often work alone or in small teams. Even large corporations often leave IA projects with only modest support and resources, perhaps due to a lack of understanding of the full challenges involved in delivering enterprise solutions.

In these cases, information architects are then faced with two choices: become more proficient in the areas outlined in this article, or narrow the scope (and expectations) of the project.

In either case, enterprise information architects will always benefit by having at least a core knowledge of organisational issues and approaches.