This blog post might not make justice to the depth and expertise that the discipline of Information Architecture deserves (although the definition of Information Architecture is still in flux) so I’m providing links at the end of this post to other websites that can take you much deeper into Information Architecture.
As deep as Information Architecture is however, it really is just a portion of a larger scope of activity called User Experience. Information Architecture is a means to an end. Information is not the user. The user is the user - a human. I’ve seen many websites or apps that sometimes seem to be primarily designed to please information itself - as if information or content was THE user. Take the typical approach of defining the ‘navigation menu’ for a content driven website. It is typical to see the navigation menu reflect the content structure available in the site, for example:
We’ve designed menus like these for years, but this is a completely anti-user view of the world. The website or app in this case is designed based on content types instead of designing it based on user needs. A user (in this case a ‘developer ‘) arrives to the website with a technical question about ‘how to set up data binding in a data grid control for a line of business application’. When the user gets to this site they know they have a need but the site is talking to them as if they knew where to search for their answer - should they go to Case Studies and hope to find how another development company solved a similar problem? Should they go to Tutorials and see if there’s an article that addresses this question? Should they go to Code Reference hoping some information is provided there? How about the Forums?
A different approach is to make the navigation menu based on a different metaphor that addresses users’ needs. If you start simplifying the sample menu I mentioned above you will perhaps find that the best result is just to substitute all those options for one single search box where users can write their need/question.
While I might sound too extreme here, well, that’s actually what Google did - instead of having nested menus with tons of topics or categories like AOL or Compuserve did back in the day - Google said, let’s just give the user one simple input textbox so users type what they are looking for and voila! one of the cleanest UIs that turned into one of the most profitable and efficient user interface metaphors in the last decade. Still today the Google search page is considered a digital icon - just like the Fallingwater house from the Architect Frank Lloyd Wright in architecture or the Starry Night from Van Gogh in painting.
If you ask me, the Google.com site is a great example of how the Metro Principles would manifest on the web. There’s a lot of conversation going on right now about applying the Metro Principles to phone and tablets but a lot of people are also asking, how would Metro manifest in a website - look at Google.com. Fierce reduction of elements. Content, not Chrome (no pun intended ). Google.com has slowly been getting more elements (look at the top) but it still is quite clean.
The Google example is pretty radical (though real) and shows how Information Architecture doesn’t mean only information structure. The term Information Architecture tends to make it feel like users are not part of it (since the word ‘user’ is not included in ‘information architecture’) but users are actually the center of it. Some of today’s best and most recognized Information Architects like the folks at iA get this and while they love to give shape to information, all their projects have user as the center - Try the IA Writer app for iPad.
On October 15th, 2008 Glenn Murphy, a Software Engineer in Google wrote a blog post titled Content, Not Chrome. It’s interesting to see how the browser ended up being named ‘Chrome’ though
In conclusion, IA is not only about “structuring content” but about crafting the axis, the foundation, the structure of your entire digital experience. Saying IA is critical for a digital experience is an understatement. Literally think of IA like the soul or spirit - the essence of the experience. And just like every spirit (that I know of… :)) it needs of a body to manifest through. This body is the app. So there you go: IA is the spirit. The app is the body. They are so interconnected, so tightly integrated that you can’t think of them separately. They form THE experience.
IA is all about bringing order to chaos, to align the misaligned, to sequence the random, to parse the mix, to understand the complex.
What is Information Architecture?
The Information Architecture Institute defines Information Architecture as “the art and science of organizing and labeling websites, intranets, online communities and software to support usability“. The Guardian recently made this post about the definition of Information Architecture. Also, here is a really good video produced by Buuteeq on What is Information Architecture? to show their non-techie customers the value of Information Architecture. It’s a good video to understand IA in simple words.
The way I describe the activity of Information Architecture is bringing order to chaos, to align the misaligned, to sequence the random, to parse the mix, to understand the complex.
The goal of the Information Architecture (IA) stage is to define three things:
- User Tasks
- Relations between Information & Tasks
That’s what the user has in a digital experience: 1) information and 2) the potential of doing something with this information - whether it’s consuming information to help take decisions and/or for generating new information.
Most of us will start creating a Windows Phone app for either A) a client B) an idea of our own (startup idea). In both cases when the project begins we will be exposed to shapeless and scary ‘blobs’ of information like names, dates, prices, images, temperature ranges, zip codes, phone numbers, avatar images, scores, in-app purchases, stocks, locations… in the Information Architecture stage you take that shapeless blob and deliver structured information. Doing it in single try is impossible. It needs many passes. If I think I’ve nailed it on the first pass I’m wrong - Only Zeus himself could do it in a single pass But in all seriousness, force the IA to go through many passes whether you do it or you have others take a stab at it and provide feedback.
Tools to Define Information Architecture
We have three very useful tools that help us define our IA:
1. IA Document
2. Application Flow chart(s)
3. Low Fidelity Prototypes
Something very important to consider here is that at this point we are not designing the user interface or the app itself. We are still working at the ‘essence’ or ‘spirit’ level - so no need for us to over invest time in visual design, user interface or animation details. Right now we simply want to straighten out our blob of information, bring order to chaos.
The IA document I usually create is quite simple although you could add as much detail as possible. The truth is in many cases this document grows to become the actual specs of the app. But in our case we will keep this document nice and short. Here is an example that shows how we have brought our now more orderly blob of information into a document that shows the main and primary hubs as well as the spokes. This is a sample IA Document for a simple ’stock price’ app.
App Flow Charts
Remember the good old flow charts for software engineering (or any other process)? That’s what App Flow charts are, it’s just that the visual nomenclature we use is focused on user flow, experience and interaction design. I take the IA Document, with its early stab at the main, primary, and secondary hubs and also the spokes and transform it into a App Flow chart. Initially I add little visual information to each screen. Just enough to see the different modules connecting to other modules.
Then little by little I start adding more details to those screens for example I start adding some UI controls - only the critical ones that allow me to start telling user stories. Later I start turning some of these screens into abstract Pivots, Panoramas or Pages.
And so, little by little App Flow charts become more detailed going from simple task flows to screens that show an idea of content views and even navigation. I wouldn’t call high end fidelity App Flow charts wireframes but many people would. Low fidelity wireframes certainly.
Low Fidelity Prototypes
Once the IA Document and the App Flow chart are more solid, it is always a good idea to start working on paper prototypes - our third tool in defining the IA for our app. These can be helpful due to their low cost ($ and time-wise). A paper prototype is a paper version of your app - how fun is that! You can put together one of these bad boys by simply sketching out the different screens of your app, or for a more refined paper prototype you can use wireframes of your app. Just like with an IA Document or an App Flow chart, Paper Prototypes also evolve little by little and go from low fidelity to higher fidelity. Notice I say “higher” and not “high” fidelity because I personally don’t think it’s worth producing a super refined, polished, high fidelity paper prototype. The idea of a paper prototype is *precisely* to keep it rough, quick and dirty. The good thing about a paper prototype is that it is something that you can actually place in front of an actual test user. The IA Document and the App Flow chart are too abstract for mortals to go through You and I sure… but for our dear user testers, a paper prototype is something they can actually use.
Please refer to the Paper Prototype section of the #3 Ideation and Concept post of this series for more information on how to create Paper Prototypes.
Now, it might seem, when I tell you that after the IA Document, comes the App Flow chart and afterwards comes the Paper Prototype, that I’m implying there are days or weeks or months in between these different stages/steps, but no In fact we are probably talking about minutes or hours between IA Document to App Flow to Paper Prototype. That’s the whole point of this process - to make it quick and dirty.
At the end you will have a solid IA document with structured information, a solid set of App Flow chart(s) and even some low fidelity Prototypes.
Architecting Information (for a Windows Phone App)
As I mentioned before, I won’t make justice to the practice of Information Architecture in this post but the method I use to define the IA for a Windows Phone app is the following:
1. We capture the needs of the project. We work with our client and write down the different needs, requests, data types, questions, wishes, and even ponies and unicorns in post it notes.
Write user tasks or needs in post it notes of the same color. Write information/data or content on post it notes on another color.
2. We host a creative analysis session with at least one person from engineering and one person from our creative team and we go through the post it notes, we explore, we best guess, we inquire, we question and we debate to define and understand what the client really needs (which might be different from what they think they need).
3. We add our own flavor. Based on this analysis we add our own post it notes with needs, questions and also ponies and unicorns.
4. Create logical groups of related items. Group things in a way that makes sense. Pair things up, group them, relate them and highlight cross over connections.
5. Define hierarchies and give order by capturing the general structure of the blob we are dealing with in an IA document.
6. Create an App Flow chart. Once the IA Document is at least a bit readable - transform it into an App Flow Chart. Notice our natural approach here will be to create a tree like structure but this is precisely where you can break the mold - you could approach your app structure in different ways, radial, layered, multidimensional, hub & spoke or others… however, talking about Windows Phone apps in particular, where the app structure is based on the Hub & Spoke model, it is best to from the beginning of this exercise define a Hub & Spoke structure to your information. A Hub & Spoke model would define a 1) Main Hub 2) Sub-Hubs or Spokes of top level 3) Spokes of secondary levels. Eventually these different hubs or spokes will end up manifesting as Panoramas, Pivots or Pages in Windows Phone but in this stage we are not yet looking into this. Notice I mentioned “eventually” J No need to get too concerned about Panoramas, Pivots or Pages during the first few passes.
Microsoft will not reject your app if you decide not to adopt or follow the Hub & Spoke navigation model - so feel free to explore other models if they make sense to your app. That said, the Hub & Spoke navigation model is arguably the best one and the one that will become the most familiar with users so it is better to use it.
7. We identify relations (or dependencies) between different branches in the structure and we capture them in the IA document or the App Flow Chart.
8. Put the IA Document and/or App Flow chart to the test by telling user stories against them. Look for showstoppers - gaps or excess tasks and/or content/information and/or relations between tasks and content that are blocking you from being able to tell a user story. Based on these run-throughs, refine your Document and/or Chart and test it again with the same and/or more user stories. Do this a few times until your structure reacts firmly to all the user stories you are trying to address with your app.
9. Create a Paper Prototype. After a few passes, it is good to transport the IA Document and/or App Flow Chart to a Paper Prototype. And from there you have 3 things to iterate on, IA Document, App Flow Chart and Paper Prototype. Test the Paper Prototype with user stories and refine it until it can stand the test of all the user stories you want to address in your app. The Paper Prototype is useful because it takes your IA to the next level and it starts feeling more real (even if just in paper). You might be able to capture other pieces of data with a Paper Prototype vs just using an App Flow Chart. Also note that a Paper Prototype is something you can actually put in the hands of a test user whereas the IA Document and the App Flow Chart might be too abstract for a non-techie user or simply someone outside of your team…
The process of defining the Information Architecture for your app is not a one shot or one pass type of activity. It requires of many passes and many tests to your IA Document, App Flow Chart and Paper Prototype. Also, a reminder that at this point we are not fully designing our UI so you do not need (and I would probably not recommend) to invest a lot of time making the screens look beautiful - that comes later. Right now we are just trying to bring order to chaos.
At the end you will have a solid IA Document and App Flow chart(s). Not sure I’d say Paper Prototypes are something that you end up with - I personally see those more for iteration and to refine your specs. Things you will throw away at the end. Everything that you learned with the Paper Prototype(s) will be reflected in the IA Document and the App Flow chart(s) anyway plus the Paper Prototypes can easily get really messy J
So with IA Document and App Flow chart(s) you are ready to go to the next step which is to really start nailing down your Pivots, Panoramas and Pages with more detail.
More Resources on Information Architecture
The Guardian - What is Information Architecture?
Information Architecture 101- Techniques and Best Practices
Next Post | #7 Layout and Composition in Windows Phone. In the next post we will review a couple different techniques to compose and layout Windows Phone UIs. The first one is using the Windows Phone design grid and the second one is using lists.