This link has been bookmarked by 28 people . It was first bookmarked on 05 Jan 2007, by Bill Wolff.
-
25 Feb 12
-
There is a discipline, known as information architecture;
-
there is a role, known as the information architect.
-
Our response has been to close ranks and attempt to formulate a sales pitch and business rationale for our work. But we aren't really sure what we're selling. Are we selling the idea of information architecture, or the idea of the information architect?
-
'big IA' -- a definition encompassing a broad range of responsibilities, including business strategy, information design, user research, interaction design, requirements gathering...
-
The result of this is 'little IA' -- narrowly focused on content organization and the structure of information spaces. But when this definition (intended for the discipline) is applied to the role, it creates for some the fear of being 'boxed in', trapped in a role so narrowly defined that many of the elements essential to the success of any given architecture are outside the control or influence of the architect.
-
but it is almost certainly working to the detriment of the discipline as a whole.
-
As a result, we end up going round in circles, with one person's definition of the discipline clashing with another's definition of the role, and vice versa.
-
Any definition broad enough to encompass the role is too broad to foster useful discussion of the discipline;
-
any definition narrow enough for the discipline is too narrow for the role.
-
The only solution is to decouple the definition of the discipline from the definition of the role entirely.
-
the information architect is concerned most fundamentally with creating information structures.
-
But the discipline of information architecture views this responsibility in a very different light. In the world of information architecture, all structural challenges are currently viewed as variants of the same problem -- the problem of information retrieval.
-
The current fashion in thinking about information architecture is that the only good architecture is one that has been built upon a foundation of pre-design user research, and validated with a subsequent round of user testing. But the conflation of architecture with research -- and the conclusion that one cannot exist without the other -- is a deceptive oversimplification.
-
During the research process, well-intentioned attempts to articulate the problem can turn into suggestions for solutions -- especially when the person conducting the research is also responsible for creating the solution.
-
Even worse than a research study that implicitly suggests a solution is a study explicitly designed to provide one.
-
Research is perfect for creating architectures in which everything is predictable and familiar.
-
But in many cases, the architecture must accommodate an audience unfamiliar with the subject matter.
-
And sometimes, such as when the goal of the architecture is to educate or persuade its audience, the element of surprise can be one of the architect's most effective tools. But an architecture derived directly from research ensures that no such surprises will ever happen.
-
In the case of IA, the "miracle" is the creation of the architecture itself.
-
We spend all our time talking about everything except the most important piece of what we do. Ironically, our emphasis on research methods, intended to enhance our credibility, only detracts from it. The impression we create is that anyone armed with the "Seven Steps to Successful IA!" can do our jobs. No wonder it feels as if the role is in jeopardy.
-
But this, in turn, requires us to acknowledge that the discipline and the role are separate, and that the discipline can be practiced by those in a wide variety of roles.
-
Information architecture is a discipline that can be practiced by people in a wide variety of roles.
-
Architectures can be designed to achieve a wide variety of goals, not just information retrieval.
-
The single most important factor in the success of an architecture is the skill of its creator.
-
-
01 Jul 09
maxilprofJesse James Garrett: ia/recon http://ff.im/-4F5mM [from http://twitter.com/maxilprof/statuses/2418918457]
tweecious Informationarchitecture AmazonElasticComputeCloud Amazon.com KnowledgeManagement Business IAInstitute Webdesign Communication
-
28 Jun 09
-
24 May 09
-
When most people think of the job of being an editor, I think they imagine someone hunched over a desk, red pen in hand, marking up an endless stream of text, cleaning up split infinitives and dangling participles and the like. But the editorial role and the editorial discipline are two very different things. While there are definitely some people who specialize in this sort of work, there's usually much more to being an editor.
In the broadest sense, an editor's job is to help writers make their writing more effective. This involves grammar and punctuation and word choice, sure, but a huge part of any editor's job has to do with creating effective structures. An editor might be responsible for structures at many scales, from the encyclopedia down to the textbook down to the article down to the paragraph down to the sentence.
Like the editor, the information architect is concerned most fundamentally with creating information structures. But the discipline of information architecture views this responsibility in a very different light. In the world of information architecture, all structural challenges are currently viewed as variants of the same problem -- the problem of information retrieval.
-
If you asked an editor at a magazine or a newspaper if the structure of her product had been tested with readers before its publication, she would laugh at you. To her, developing effective structures is a matter of exercising her professional judgment -- judgment honed through years of trial and error and hard-won experience with her craft.
To her, the proof of her effectiveness in her discipline is her ability to exercise that judgment. To her, that judgment is the very reason for the existence of her role. To her, the idea of abandoning that professional judgment and recasting her role as a conduit through which research findings become structures would be simply absurd.
And you know what? She's right.
-
Research benefits architecture most when it seeks to define the problem we must solve. Research benefits architecture least -- and can actually produce bad results -- when it seeks to define the solution itself.
-
It's not always easy to tell whether a research study defines the problem or defines a solution. During the research process, well-intentioned attempts to articulate the problem can turn into suggestions for solutions -- especially when the person conducting the research is also responsible for creating the solution.
-
When we hold the test up as the ultimate determinant of success or failure, we encourage specialization in beating the test. The unwritten law of usability is that the most efficient approach is the best. But again, outside the limited area in which user tasks can be readily identified and goals readily recognized, efficiency is not necessarily a universal good. Testing cannot account for all the possible goals of an architecture or its users.
If our discipline continues to develop along its current course, we will have developed an entire body of knowledge about information architecture that amounts to little more than a set of tips and tricks for beating the test. Meanwhile, the real creative problems inherent in our work will remain as poorly understood as they are today.
-
The progress of the discipline depends on the development and iteration of a body of knowledge. This body of knowledge, in turn, can only come about through deliberate consideration of a wide range of architectural problems and potential solutions. What we need most of all are good test cases, and the insights that come from tackling them first-hand.
-
I have often been asked the secret of my success as an information architect. Here, I will reveal for the first time that secret.
I have hunches.
Of course, it's not enough merely to have hunches. They have to be good hunches. My hunches have to be better than the hunches my clients have -- that's why they hire me.
-
Currently, we are building a body of knowledge whose basic requirements -- a dedicated specialist, extensive time and money devoted to research -- automatically exclude the vast majority of real-world cases.
-
The message we should be sending is this one:
Information architecture is a discipline that can be practiced by people in a wide variety of roles. Architectures can be designed to achieve a wide variety of goals, not just information retrieval. The single most important factor in the success of an architecture is the skill of its creator. This skill is applied through a combination of experienced professional judgment, thoughtful consideration of research findings, and disciplined creativity. This skill can be developed and applied by specialists and non-specialists alike.
Only by being honest with ourselves about what makes us valuable can we convince others of that value. Only by being generous with our knowledge can we reap all of its benefits. And only by creating a culture in which these principles are fully embraced can we foster the growth of our field, and ensure our continued success.
-
-
11 May 09
-
17 Apr 09
Alex HorstmannThere is a discipline, known as information architecture; and there is a role, known as the information architect. They have developed more or less hand in hand, and up to now any discussion of one has involved discussion of the other. But now that may ha
-
08 Apr 09
-
06 Jan 09
-
30 Sep 08
-
03 Jan 08
-
29 May 07
-
25 May 07
darius kumanaIA - lack of credibility. The humiliation of the information architect is ongoing. First we have to explain what we do. Then we have to explain why it's important. Then, once they understand that part, our clients decide that they can do it too.
-
16 May 07
-
-
Research benefits architecture most when it seeks to define the problem we must solve. Research benefits architecture least -- and can actually produce bad results -- when it seeks to define the solution itself.
-
During the research process, well-intentioned attempts to articulate the problem can turn into suggestions for solutions -- especially when the person conducting the research is also responsible for creating the solution.
-
he process of analyzing research data to produce findings can introduce biases and assumptions that dictate a given solution
-
And because these studies are conducted in the absence of peer review, flawed methods and biased findings never come to light.
-
Furthermore, we might never discover these new architectural approaches if we rely too heavily on user testing as the primary means of validating our work
-
-
04 May 07
-
30 Apr 07
-
01 Dec 06
Andre MalheiroThere is a discipline, known as information architecture; and there is a role, known as the information architect. They have developed hand in hand, and up to now any discussion of one has involved discussion of the other. But now that may have to change.
information architecture professional article user experience design
-
28 Oct 05
-
13 Dec 04
-
05 Apr 04
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.