Boxes and Arrows: Comments by Masood Nasser

Masood Nasser — Fri, 26 Jan 2007 14:52:54 GMT

Nice article James. Gives a broad overview of the problems/scenarios in Enterprise IA.

“Enterprise IA projects are only successful when delivered solutions are actually used by staff.”

IA’s should be the first to cut any activity/ function/content that would add to the information pollution. A fancy application built in-house would be no good if there is a publicly available tool and your enterprise users prefer the same to what you have so painstakingly crafted.

“Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate”.

Analytics tools are a great way to understand how users how their system. I have seen examples where logs show us navigational paths from task based activity to the static content browsing. Such kind of research helps in crafting a solid IA that reduces time spent by employees on finding information rather than doing tasks.

Masood Nasser — Fri, 26 Jan 2007 14:52:55 GMT

Hello Meg,

Nice article. Shows a substantial amount of thought and research has gone into this article.

I have certain reservations though on the first guiding principle “Communicate openly and clearly about security and privacy”

Communicating that sort of information would be too overwhelming for a majority of your users, but then again lack of communication would also be hiding this information from the user, who has a right to know these. I think here that “How” the interface is “presented” also will make a very big impact on the user. Your thoughts on the same?

Masood Nasser — Fri, 26 Jan 2007 14:52:56 GMT

Another important factor IMHO in Enterprise IA is to manage internal organizational politics. The amount of internal manouvering that goes on does seem to have an impact on IA strategy. Business units & Groups competing and justifying spends can make an impact and threaten to derail your goals.

Masood Nasser — Fri, 26 Jan 2007 14:52:59 GMT

Yes Christina, it is immensely valuable in SEO. Specially when designed with a lot of keyword density.

Rohan

Site Maps when designed properly, give more options to the user to get a clear picture of what the site has to offer. In today’s world of growing impatience, site maps are invaluable for sites with tons of content.

In a site with 1000+ pages, it is a no-brainer that u cannot list all pages. Therefore creating a site map would actually help in giving a starting place for users to find what they need.

Masood Nasser — Fri, 26 Jan 2007 14:53:00 GMT

Also, this article talks about what is really necessary at a basic minimum to make a CMS work, withouth falling in the the trap of the “fantastic & endless features & possibilities” of CMS’s. Do we really need everything?

Cheers
Masood
http://masoodnasser.blogspot.com

Masood Nasser — Fri, 26 Jan 2007 14:53:00 GMT

Interesting, Alok. Methinks that the length could vary on the subject of the podcast, like a serious topic, where a knoweldge seeker is seeking information on specific issues, or casual Pod-cast surfing, like our very own Jammy’s “Funny” podcasts, where we would prefer shorter podacasts.

Masood Nasser — Wed, 21 Mar 2007 13:51:47 GMT

My intention was about Information systems, not necessarily websites
Think about Enterprise Information architecture, where your audience is accessing your intranet from dozens of locations around the globe.

There a centralized repositories with thousands of documents, presentations, legal, etc. What site maps can do here is to give the user an idea of what to find where. Intranet search behavior can be very different from Web site search behavior. There is a lot of research that we have done on this subject.

Cheers
http://masoodnasser.blogspot.com

Masood Nasser — Fri, 26 Jan 2007 14:53:02 GMT

Yes, IMHO too, the human element is a very critical factor, if not the most, in the success or failure of a CMS

Masood Nasser — Fri, 26 Jan 2007 14:53:02 GMT

James,
Another issue I have seen in communicating widely within organizations about the vision and goals is that people really do not care much for this stuff. People are so involved in their routine work that another initiative or communication is seen a “yet another blah blah blah from mgmt”. In this process even extremely important initiatives suffer.
The question here is how do we communicate effectively. Do we foster involvement at a lager scale? BTW, am enjoying your article a lot and can relate to a lot of issues that you have mentioned here:-)
And a lot of these issues you have mentioned are fodder for new stories. Can we expect some more on the same?

Masood Nasser — Fri, 26 Jan 2007 14:53:03 GMT

Christina, very well put. I would make it mandatory to my collageaus to read this article before quoting so and so “rules” or “guidelines”. “Reminder” is a nice word. Loved the Quote “exuberantly ignore them’

Now lets see if I can come up with my own “reminder” sets on yet another boring flight tomorrow:-)

Masood Nasser — Fri, 26 Jan 2007 14:53:05 GMT

Another thing that I find interesting is that I have a lot of my architect friends who relate to what we do in information architecture. Maybe architects have a natural affinity for information architecture as they are the ones designing those navigation aides and way finding sytems, albeit on a much larger scale.

Masood Nasser — Fri, 26 Jan 2007 14:53:05 GMT

Ross, it would be interesting if you could include research based path usage patterns and how they can be used as architectural elements on the web…

cheers

Masood Nasser — Fri, 26 Jan 2007 14:53:08 GMT

Just read this article now..

I compeltely agree with Adam Greenfield

“If reengineering business is what you dig, by all means, rebrand yourself a strategic consultant and take those insights and rock them at the appropriate level”

Too many IA’s have aspirational notions of affecting business, and are often barking up the wrong tree. A Re-branding as strategy consultants would be the first step of sorts…

Bob,

Thinking like this always increases value and enhances perception of what we do..

Cheers
Masood

Masood Nasser — Fri, 26 Jan 2007 14:53:08 GMT

You are right Zef, software design and development can be a “dry” and “introverted” approach, and your technique does have the potential to not only make the process engaging, but also make get the technical team more communication savvy, rather than rely on the marketing folks or senior management only for all your presentations/pitches

Masood Nasser — Fri, 26 Jan 2007 14:53:09 GMT

We could also look at scenarios where a UX professional is the project manager as opposed to the traditional Technical developer/Architect managing the project.

While in the first scenario, I assume it would be smooth sailing. In the second scenario, it would be a lot extra effort including selling UX to the team itself. I am not suggesting that developers do not understand UX work, but explaining the finer nuances or the need for certain UX activities is a different ball game altogether, which can greatly affect the agile development process.