Information Design Process

As I sit and contemplate the writing of this post and the introducing of the procedural process as indicated by our text Information Design and its accompanying workbook, that it might have been a good idea to build a rudimentary website or even a game with any of the gametools now available online, or even a widget with any of the available widget makers.

I say this because this course is becoming more and more about actual practical use in the real world, like one might expect from on the job training, rather than the picture in my head of classic classroom socratic blackboard theoretical understanding and the bridging of the classroom experience with hands on experience.

Politics, Diplomacy, Consensus

Comment:

The text advances pretty much as I would have in my web design years. I often asked a customer who is the boss? Meaning who is the one ultimately signing off on the finished project, giving their approval to take the project live to the internet cloud or whatever public domain the project is to occur in. And the text reflects this with the section of politics, diplomacy and consensus. I like the further definition the text gives though, particular in the understanding of the process, as all my clients have had to have the process explained to them and usually they walk away shaking their heads in a display of not understanding. People unfortunately have been given the caveat understanding that if you put up a website, you will become rich. I hate that stereotype. A website or any other interactive informational source is only a tool and as such it is only as good as the person that knows how to use it.

Process:

You need to find out who and why your client is developing an information interface. This requires diplomacy as you might be surprised at the context they may be coming from, but it also requires diplomacy because this is the beginning of the hold-their-hands process and you need to be aware that at the onset you are out to take care of your client, please them and will continue to do so through the process.

Knowing the Audience

If you do not know your audience it kind of begs the question of why are you formulating an information interface to begin with? But audience appeal is going to make the interface desirable to use, and the user will feel comfortable coming back to it for its value in the form of information it dispenses. So you have to know what they are talking about. If it is for a grouping of engineers and you don't know about engineering strength of materials and kilipascals of tension, and you start talking about what it takes to snap cabling and describe it as pulling a string of bubble gun from your mouth until it snaps, I feel confident they are going to leave your interface and have a field day with commentary about it at the water cooler.

Context of where the user is coming from will be of most value in discerning what context to build into the interface. Engineers will expect engineering jargon and nomenclature, medical doctors will expect medical based understandings, writers will expect proper word usage, syntax and semantics, and so on across the fields of industry, science and art.

Physical requirements intrigue me. I have given a lot of thought as to how to address sense-deficient peoples. This part of information design has only been scratched with a wide open future. But in the end the practice of the interface meeting the user is going to be generalized around what the senses can take in conveniently.
You need to know in what physical method the content is going to be accessed.

Procedurally the text indicates a numeric step by step process. I have seen such as timelines for construction sites, renovations of buildings but this is the first time seeing it in an Information Design context. It does make sense especially if more than one person is on board with the construct of the interface. It brings with it a uniformity of concept process which everyone can see in their own imagination, and thus avoid mis-steps along the process.

Plain language use is kind of a no-brainer for me. I am stating regularly these days that people need to hear Twain's comment of don't use a fifty cent word where a nickel word will do. The overall project concept has to be readily conceivable in the client's mind as well. If you are flying over their head you are doing them a dis-service by dismissing their intellect in the buying process and raising the possibility of a bad end product that won't be approved and will generate bad emotions to deal with along the way. Speak to your client in terms they can understand, and be politically correct while doing so.

Content analysis is probably the single hardest effort as one is anticipating and making the data translation on behalf of both client and end user at this point and figuring out how to best make the two meet each other in friendly terms. It is the synthesis of the data into truly usable information. Along with this is how to library the content into convenient methods of retrieval. As much as possible my belief is that the marriage of both an image and a few words of text are the best possible solution. Call it the cartoon solution. Deeper meaning can be a tangent link off the main information, so for example one might have technical specs as a deeper link, images from various views as a deeper link, user reviews as a deeper link, but the main image is the splash image that the user wants to see, and what the interface should nurture for the user to see. Instant gratification and the human stimulus response are both enacted, which makes that moment of discovery poignant for the user and thus delivers a dopamine blow that entices them to no end.

The Creative Brief

How to achieve all of the above understanding at the onset? It takes an interview process wherein all the above parameters are discussed. One aspect I don't see our text addressing are preliminary compositions leading up to a final implementation design to start the build with. This might be inferred as part of making up the creative brief, but if so this aspect is understated. I have designed six versions of graphic interfaces only to have the client say no to all of them and then walk away from the project because I couldn't hit on what was wanted.

This is probably the single most difficult task between the client and the designer as you are asking the client to see in their mind what you hold for them as a future finished product. And if they are short on imagination, you are going to, as the text says, have to hold their hand a lot. And you still might not get the project even then.

If you get it rght, the client will display that they are okay with what you have come up with. Either a yes will be stated or they will become gleeful for seeing what they want, something will trigger a response from them that tells you that you are tracking in the right direction and you are good to go.

The creative brief is the instrutction set or outline of parameters you are going to live up to as the creator and produce as best as you can.

Personas and Scenarios

I feel like this is a further explanation of who is your audience. However having said that, it does make sense to troubleshoot the interface for user friendliness and any obstacles the user might come up against in the odd situation.

I see it as part of the section on testing the interface as well. In some ways I feel like this should be fairly well resolved from the onset as part of audience definition. Perhaps what this is about is a graceful follow through arcing from the know your audeince aspect to user freindliness to testing for user friendliness. I do see where all three are tied to each other on behalf of the end user.

As part of knowing your audience, you will want to come up with a grouping of user types and their personalities that will be using the interface, this will give you insight in various ways like ergonomics, gender concerns, politics, sustainability, any of a number of reasons that may incur a design adjustment to accomodate as the interface is being created.

Structural Overview

Comment:
Site maps are something I always use for myself when I seem to be getting no where on an information search, but when I have suggested them to customers they draw a blank and never had me produce them.I was producing for smaller clients though and as such they can be forgiven.

The sitemap is an orientation tool. And a set of shortcuts to cut across the hierarchy structure, A top view so you can see where you were and where you want to be and readily achieve getting there. Sitemaps make an interface that when the rest of the site drops the ball, the sitemap saves the site itself by having a well done site map for a "lost user" to re-orient themselves with and get back on track. But if the sitemap fails then the whole interface is a jerk. At that point the user has tried A, and the user has tried B, and neither have worked, so its the exit button to the next site on the search engine return list.

I have built huge 700 plus page websites. If they can be database driven it is a lot easier. If they have to be static pages, well say a little prayer,  but have a good layout of the structure of the site and proceed with caution. Making such a site map is ...well... challenging.

Process:

Structure goes to departmentalization and compartmentalization. Breaking up the whole into manageable subsets so as to make the baking of the cake a step by step process a team can knock out a chunk at a time and see progress at the same time, and be able to report back to a client those steps as done stages of the process.

Wireframes

The wireframe is similar to a storyboarding of the website. In some ways I feel like this is a little redundant to site mapping. What is being added in are additional functionalities or streams of information that might occur that aren't comprehensively written into the site map.

Best practices, Radical Simplification, and User Centric Design.

For me best practices really is all about the layout of the available real estate the interface is going to give the user (user centric) to work with and manipulate the available data with. If you stick a function that is used regularly on a drop down menu where it is hidden, that is just plain nuts. Testing will survey and resolve how often a function is determined to be needed and so such function needs to have an appropriate spot in the real estate.

Which is all about user centricity. Surveying such functionalities in a checklist type of format where users can say they needed to use X function so many times to achieve they desired result will give an idea of whether to place the button or function in one place or deeper where it may be needed in relation to some other aspect of the interface function.

The pitfall at this point though is what does the client want. If the client wants a certain functionality that testing shows is less important than the client gives it in weight so you have to move that functionality up the ladder and put it someplace where it might not be appropriate, you are suddenly in an awkward position of having to cave in on best practices to exact making a buck.

But that never happens.