Information Technology Reference
In-Depth Information
derstand what they find. In the late 90s, this concentration made sense. Everyone was shoveling
content onto their sites, and somebody needed to organize it.
Our formal definition of information architecture as “the structural design of shared information
environments” was more expansive, but nobody remembers definitions. What caught people's
attention were the wireframes, the most visible yet superficial element of our work. So, in the
minds of many, our practice was wedded to websites and wireframes.
But, as we shifted from nineties to noughties, information architecture continued to evolve. In
addition to wireframes, we used all sorts of tools and methods to learn about users, test ideas,
and make the complex clear. And, we went beyond usability, working hard to improve findabil-
ity, accessibility, credibility, and other qualities of the user experience.
Figure 1-3. The User Experience Honeycomb.
Along the way, the context in which we practice changed. Web search and SEO turned sites up-
side down, by shifting attention from home pages to the design of findable, social objects that
serve as both destination and gateway. In short, we began to plan for multiple front doors.
We embraced Web 2.0 selectively, learning to design rules, frameworks, and architectures of
participation. And we started making maps for mobile and cross-channel services and experien-
ces to help our clients and colleagues to see and understand what's possible and desirable.
We realized that, in the modern era of cross-channel experiences and product-service systems, it
makes less and less sense to design taxonomies, sitemaps, and wireframes without also mapping
the customer journey, modeling the system dynamics, and analyzing the impacts upon business
processes, incentives, and the org chart.
Search WWH ::




Custom Search