I have created a new resources page that will contain interface design resources and tutorials as well as SharePoint-specific resources.
http://www.siolon.com/resources
I have signed on for my first podcast! I am with a small gang that covers current tech news, reviews, and I do the “Free File” segment which covers a freeware product.
An absolutely fanastic woman named Gwen Robinson has agreed to marry me! I’m so lucky!
Here is the ring!
Information Architecture is a difficult field. Not only do we continually have to sell the importance of our field, but we also serve a role that most IT people do not. We walk the thin line between business analysts and designers; we also have the difficult job of translating functional business requirements into something our developers can understand and our customers can buy off on.
Because we often don’t fit well into a nice category we are responsible for a much larger part of designing information systems. Nothing makes this more evident than the process of creating wireframes, and I’m going to address the debate on interactive vs. static wireframes in the context of our role in the development process from the perspective of designers, customers, and managers. The time has come to more clearly define who we are, the role we play in the development process, and be sure that we satisfy all interested parties in the process.
The following quote from Rosenfeld and Morville in their IA magnum opus will be expounded upon:
Wireframes represent a degree of look and feel, and straddle the realms of visual design and interaction design. Wireframes (and page design in general) represent a frontier area where many web design-related disciplines come together and frequently clash. The fact that wireframes are produced by an information architect (i.e., a non-designer) and that they make statements about visual design (despite being quite ugly) often makes graphic designers and other visually oriented people very uncomfortable. For this reason, we suggest that wireframes come with a prominent disclaimer that they are not replacements for “real visual design.” The fonts, colors (or lack thereof), use of whitespace, and other visual characteristics of your wireframes are there only to illustrate how the site’s information architecture will impact and interact with a particular page. Make it clear that you expect to collaborate with a graphic designer to improve the aesthetic nature of the overall site, or with an interaction designer to improve the functionality of the page’s widgets. (pgs. 308–9)
The answer is yes and no. We certainly have a role in the overall user experience process, but we are not responsible for how a user actually interacts with an information system. Let’s face it our annotations don’t replace the role of a qualified interaction designer. I will be focusing on the fact that our value-added proposition is that we can effectively lubricate the evolution from a stiff business requirements document into something reminiscent of a usable system that is then passed onto the programmers, designers, and usability gurus.
Please understand that I understand that the field of IA, UX, and all other aspects of architecting interfaces often happens with just a single person. I don’t want to minimize that as I myself served all these hats. I’m simply pointing the role of a wireframe in the overall interface design life cycle.
There are an abundance of tools that purport to aid architects in creating interactive wireframes, but then what does that display to our team members? Does a designer want to be handed a garbled, poorly-coded, auto-generated layout with cookie-cutter interactions? I know when I was a designer I wanted at least some liberty in what the interaction and user experience ended up looking like. It’s true that in most design shops that the designer serves an IA role, but when we have dedicated information architects shouldn’t we stick to doing what we do best? Don’t we deliver more value in designing taxonomies, labels, navigation, and conceptual layouts?
The customer will always prefer something interactive—that isn’t a question. Looking at a bland Visio document doesn’t exactly inspire someone, but what is the purpose of the wireframe? Are we not trying to get the customer to focus on the layout, labels, etc and not how the interaction will take place? When we design interactive wireframes doesn’t it also pigeon-hole the designers to design around the interactions from the IA’s wireframe?
Here is what usually happens when you give anything interactive to a customer when you’re trying to do IA and not interaction design/user experience. They will spend more time clicking around complaining about the pop-up windows and the way it looks and not what we actually want them to be looking at? The value in static, seemingly dry wireframes is that they have no choice but to focus on what we bring to the table in terms of IA and not user experience.
Designers are artists in their trade. They make money, because they know typography, colors, interactions, and all the other unique challenges to being a designer. I can’t tell you how many times I’ve asked for wireframes when what I was given was a poor mockup. Let us answer once-for-all that a mockup and wireframe are not the same thing. The designer does not want to be given a mockup—that is the very thing they are experts in. The problem only escalates when an information architect tries to tread too much on what the designers are supposed to do.
When an information architect goes out and converses with the customer, interacts with the functional business requirements, and creates and receives buy off on a wireframe that it is almost invaluable to a designer and the other programmers. A programmer can then focus on database schemas, object orientation, while the designer can worry about the aesthetics of the interface. You will become a programmer/designer’s best friend if you can abstract the job of creating labels while not dictating how the interaction and how it will actually look.
Project Manager’s are often the hardest to sell on the value of IA. They look at IA as something the designer does, and that only contributes to the difficulty of selling the importance of our field. They are likely to look at the designer and say: give me a mockup to send to the customer, and when money becomes an issue in the project they’ll cut IA’s always before designers. I have never heard of a designer being cut in place of an IA. It has never happened.
We need to carve out what we do best. Designing information systems amongst different skill sets is not reminiscent of some measure of unrelated diversification—everything we do as IA’s is related to everything else. We just need to be sure that what we do we do as well as we possibly can while enabling our fellow designers and programmers while appeasing our customer.
The thesis of this essay was to define what our role is in the wider scope of the development process, and address just one small part of our value added proposition in the development of wireframes. We have so much to offer, but we must be careful on where we tread because we fill such a political position in the development process.
Governance is a fantastic idea. In fact, it is absolutely critical to the continued success of an application. There are times that governance, to me, seems to be a great idea on paper, but in practice it’s very difficult to implement. I was talking to someone the other day on the topic of governance, and I used the example of Wikipedia as a successful governance plan and execution. I thought it would be worthwhile to dig deeper into the topic as a great example to look to.
Of all places Wikipedia has a great outline of governance goals as applied to the IT arena.
The primary goals for information technology governance are to (1) assure that the investments in IT generate business value, and (2) mitigate the risks that are associated with IT. This can be done by implementing an organizational structure with well-defined roles for the responsibility of information, business processes, applications, infrastructure, etc.
The more and more I do true implementations of IT whether it be SharePoint, WordPress, or any similar technology is the role of governance. Items from controlled vocabularies to usage policies are essential the sustainability of an IT initiative especially in terms of ensuring that IT investments generate true business value. A lack of governance is always a primary reason why IT projects fail.
Wikipedia has an extensive governance model outlined in their Manual of Style. Everything from abbreviations, punctuation, etc is included in this one of many operating documents for Wikipedia. It is clear not only reading this document that it has been carefully thought out, but the power of their guidelines comes from adherence to the document.
In a policy and guidelines document it is noted on who is responsible for enforcing these policies.
You are a Wikipedia editor. Since Wikipedia has no editor-in-chief or top-down article approval mechanism, active participants make copyedits and corrections to the format and content problems they see. So the participants are both writers and editors.
Books such as Wikinomics probe how such a mass scale collaborative project doesn’t turn itself upside down, and it’s truly a site to behold. It becomes apparent that Wikipedia editors tend to enjoy adhering to the governance model, because they understand it is crucial to the long-term sustainability of the project. The editor therefore become stakeholders in there edits, and they understand that if they want their work to not be lost is an adherence to the governance documents.
That is of course not the whole story behind Wikipedia. The Wikimedia foundation does have a small army of administrator that constanty patrol the recent changes list, and ensure that the governance model is actually being utilized. So actually ensuring that certain individuals are empowered to a special degree of administrative rights also becomes a crucial factor in its success.
Let’s face it, none of will ever be doing something as wide-scale as Wikipedia (although never say never), and so the question becomes how can we apply the best practice from Wikipedia governance to our individual IT endeavors? Thinking through this I came to this short list.
I’d be interested to know how these overriding principles are being used in other successful governance implementations. I’d venture to bet that successful initiatives mimic much of the list above. Whether SharePoint or Wikipedia the same governance principles apply and are necessary.