Information Architecture Book Review

A lot of people think they know exactly Information Architecture is, but the truth is that a lot of people don’t know and they are not even aware that they don’t know (aka second level incompetence).

To make sure I wasn’t a member of the later group, I recently read Information Architecture: Blueprints for the Web (2nd Edition) by Christina Wodtke and Austin Govella.

Wodkte and Govella do a good job in outlining their definition of the basic principles of IA:
- Design for Wayfinding
- Set expectations and provide feedback
- Design ergonomically
- Be consistent / consider standards
- Provide error support (Prevent, Protect, and Inform)
- Rely on Recognition rather than on recall
- Provide for people of varying skill levels
- Provide contextual help and documentation

While the illustrations that drive home the subject matter can be a little clipart-ish at times, the concepts are presented in a non-technical and non-jargon based way. Each topic is explained clearly using an outline / numbered bullet format to ensure that each section can be clearly understood independently and collectively. Items such as ‘Who are the users?’ may seem trivial at first, but imagine how many interpretations of ‘The users are...’ exists within an organization and the problems that arise when the user begins to morph throughout the product lifecycle to satisfy everyone's argument. Wodtke and Govella decompose several non-obvious items such as persona creation and navigational types (structural, associative, and utility) into chunks that are comprehensible (Hrair Limit). I was genuinely surprised to find a section for Social Architecture which exposed me to topics such as Kurt Lewin’s formula for understanding human behavior and the elements of social architecture: identity + elements, relationships + elements, and activity + elements.

The book can be read from cover to cover, if time permits. However, most of the world will probably use this book as a reference guide for completing IA related tasks as they arise. I would strongly recommend that all aspiring and current IAs give the book a once over to spawn new thoughts about the discipline or to renew the interest in keeping things usable and findable.

Designing for the Digital Age Book Review

Designing for the Digital Age: How to Create Human-Centered Products and Services serves as an excellent guide and reference for new and experienced human centered design practitioners. Kim Goodwin (VP of Design @ Cooper.com) does a great job translating her goal-oriented design processes into clear and understandable terms. Human/user centered design books can easily be littered with heavy jargon or unintelligible references that make it difficult or impossible to understand or practice. Goodwin makes a conscious effort to explain and visualize many of the concepts introduced in each chapter and keeps the research lingo within reason. For example, in Chapter 12: Defining Requirements, Goodwin dispels what requirements aren't (i.e. features or specifications) and promptly outlines what is needed to generate effective requirements (i.e. data needs, functional needs, product / service qualities, constraints). In addition, Goodwin's writing style guarantees a cognitive learning experience with most readers by providing multiple exercises and scenarios that engage and evoke a desire for comprehension. The photography, diagrams, and charting are plentiful and supplement the subject matter effectively also.

I believe that this book is easily a pylon supporting the ever-swelling weight of UCD with its hoard of overlapping design disciplines. I recommend it to anyone interested in design or the design process...

Table of Contents:

Getting Started
     Chapter 1: Goal-Directed Product and Service Design
     Chapter 2: Assembling the Team
     Chapter 3: Project Planning
Research
     Chapter 4: Research Fundamentals
     Chapter 5: Understanding the Business
     Chapter 6: Planning User Research
Chapter 7: Understanding Potential Users and Customers
     Chapter 8: Example Interview
     Chapter 9: Other Sources of Information and Inspiration
Modeling
     Chapter 10: Making Sense of Your Data: Modeling
     Chapter 11: Personas
Requirements
     Chapter 12: Defining Requirements
     Chapter 13: Putting It All Together: The User and Domain Analysis
Framework
     Chapter 14: Framework Definition: Visualizing Solutions
     Chapter 15: Principles and Patterns for Framework Design
     Chapter 16: Designing the Form Factor and Interaction Framework
     Chapter 17: Principles and Patterns in Design Language
     Chapter 18: Developing the Design Language
     Chapter 19: Communicating the Framework and Design Language
Detailed Design
     Chapter 20: Detailed Design: Making Your Ideas Real
     Chapter 21: Detailed Design Principles and Patterns
     Chapter 22: Detailed Design Process and Practices
     Chapter 23: Evaluating Your Design
     Chapter 24: Communicating Detailed Design
Ensuring Success
     Chapter 25: Supporting Implementation and Launch
     Chapter 26: Improving Design Capabilities in Individuals and Organizations

Stop Lying...

Now more than ever, more people go online and look for jobs.Many companies are so desperate to get more work and skills out of the people they do hire, the job of requirements are turning into flat out lies, which in turn make job listings 'unusable'. We all know that hiring managers sometimes get overzealous when they post an opening or contract role. Sometimes hiring companies honestly don't know what an interaction designer does outside of what other job listings have stated, at which point someone 'cuts and pastes' other companies skills into their own opening descriptions. In extreme cases, the job title is so misleading from the responsibilities of the job, it seems like an federal enforcement agency should step in. Example:

Title:Information Architect
Responsibilities: Wireframes, prototypes, Linux server administration and installation, Java and WebSphere
Really? I guess you could say that many companies want to fill a server admin role and an IA role....but with the same person!?

Point 1: We (working class) need an honest assessment of the skills needed today AND tomorrow so we can compare expectations. And by expectations, I mean salary / equipment needs / managerial support. Lying is not good design...

Bad Example: Not too long ago, a person I know was hired to do visual and web design work for a small company. The job requirements were very simple: Adobe CS3, HTML, CSS, and Ajax, which are all typical of a front-end presentation level role. Within two days, the job somehow morphed into a full-fledged certified .NET C# Developer position (SQL included). The company's attempt at sponsored training: Borders. Bad Design? Yes, if you consider the job said 'GUI Designer'.

Good Example: Alan Cooper is a prominent author and founder of his own consulting company. On his Careers section, not only does he 'define' each job category, job exercises are present to help prospects determine where they fall in the companies hierarchy, if at all. Here is a link to an example for the interaction design exercise. Good Design? Yes. Why? I now know that I would not be a good communication designer for Cooper, but I would be a great interaction designer.

Point 2: Hiring Managers and Recruiters must stop pushing expectations apart from one another, just in favor of pacifying all parties until after the contract is signed. For the sake of all disciplines, its not good design to be a Talent Pimp...

Real: Truth and honesty can make many things usable, including software and designs

Imagined: Lying, deception, talent pimping