——

Steve Portigal was up first to walk us through his sold out workshop called, “Well, we did all this research … now what?”

My Twitter Feeds on SP:

“Who cares about terminology. Examine, infer and apply to business or design.” I’d say apply to both. Why should they be different.

“Stay out of solution land. Try different methods”

When stuck come up with really bad ideas to encourage creativity.

——-

Second was Kumi Akiyoshi with “Feeling: What Makes an Engaging Product?“.  The slides from the presentation are below:

Third was Ian Swinson with “Postcard Patterns”.

Postcards = simple straight forward messaging

——-

Fourth was Nadya Direkova with “What’s in a game? A look at game design best practices as prime influencers of interaction design.”  The slides from the presentation are below:

Twitter:

Is google a single player or multiplayer game? How many of us get to design apps in 3d?

This is review so far. It’s all about the same from my game design class at Parsons.

Simply controls. Friend invites to play with friends. (AdverGames)

Create a reward in health. Physical Therapy… Doing # of exercises = whatever

——

Kim Goodwin “each one teach one” – people are now saying I experienced good design. This is easier than that.

Twitter:

“Nothing special about the iPhone. Technology is simple. It’s design they are selling. And we’re paying a lot of money for good design.”

“Corporate Americas new found belief in design is fragile.”

A lot of good ideas end up collecting dust. “It’s someone else’s fault. We need to take responsibility.”

Sales people understand progressive commitment. Get people involved in the research and so on to understand reasoning. Pushes commitment.

Even those who are use to rational decisions can be susceptable to emotion. (Ie the Mini Cooper)

Bargaining a normal part of Change Management. “I’ll have the salad with the cake.”

Ixd = generation creation

——

In summary -

Personal gripe: Another thing about less is more on presentation slides… Less information focuses the audience on you and what you are saying. Avoids info overload

At the bar afterwards: “We’re designing behaviour”

————————–

Information architects still struggle to define the design principles that operate in their environment. Today I would like to give a set of design principles that was developed with an Information Architect a while ago. Design principles are not necessarily right or wrong but should be an accurate reflection of the fundamentals that guide decision making in an enterprise. The following should therefore not be seen as design principles fixed in concrete but rather as examples of business principles. Best practice is to define the design principle in terms of its Benefits and rationale as well as the implication to the enterprise and the counter argument expressing the potential negative impact of the design principle.

Design principle 1: Central management information

Description

All management information and business intelligence will be sourced from a single consolidated source of information

Benefits
• A central source of management information will provide the enterprise with a wide breath of reporting and analysis without being constraint by the organisations functional structuring.
• Users will become used to a single interface to management information allowing managers to become familiar with the infrastructure and extracting maximum benefit from all information available in the organisation.
• The central information will eliminate contradicting information sources and ensure accurate reporting of current affairs and identification of issues and opportunities.
• Increase the flexibility and manageability of providing information rapidly and effectively to support business decisions.
• Use best of breed analytic functionality to support management decision making
• Increased security in managing access to The enterprise’s management information

Implications
• Information must be sourced to the central information infrastructure from all the various operational applications as close to real time as possible
• No additional analytical modules are required for transactional applications.
• The interface to management information and training should be rolled out to all decision makers to effectively access information.

Counter argument
• The central management information might not be adequate in situations where real time analytics of transactional information is needed
• Information in the central information source might not be structured for a specific requirement and the development time might be too long to provide the information in time for a once off request.
• The assumption cannot be made that a single tool will satisfy all the information requirements. The information infrastructure will therefore consist of a variety of integrated tools.

Design Principle 2: Internationalisation

Description
Information must be structured for global deployment in various cultures and support multi-currency, multi-language and multi platforms

Benefits
• Flexibility to enter into other global markets
• Consistency of being able to deploy a proven business model and then adapt to local conditions

Implications
• Applications should be much more flexible to accommodate differences defined by different countries
• Current applications should be evaluated in terms of internationalisation requirements.

Counter argument
• Applications designated for use locally in South-Africa only does not have to comply to the internationalisation principle
• The enterprise might strategise to enter only into markets that have a certain set of international commonality which make the rigid application of this principle unnecessary
• It might be too expensive to change or replace legacy systems to adhere to the internationalisation requirement.

Design Principle 3: Single contact database

Description

A single contact database for all business contacts e.g. policyholders, intermediaries and service providers

Benefits
• A central source of information to manage relationships effectively
• Have a more comprehensive view of interrelationships between business contacts.
• More effective marketing campaign design and management

Implication
• High levels of data integration with transactional systems updating contact information.
• Transactional systems updating information must be assigned with levels of trust.
• Central contact information should not .complicate functional requirements to only view specific relationships.

Counter argument
• Some functional units might not want to share contact information for the fear that it might be used wrongly or out of context by other parts of the organisation.

Design Principle 4: Single point of authentication

Description
Access for to information should be constraint through a single point of authentication infrastructure

Benefits
• Improved security of information

Implication
• Central management of user access to information.

Counter argument
• The current infrastructure might not be mature enough to implement the principle.

Design Principle 6: Data quality measurement

Description
Data quality will be measured both in quantitative and qualitative terms eg. Audit procedures and Data quality questionnaires

Benefits
• Improved data quality
• Accurate usage of data
• Improved management information
• Increased operational efficiency

Implication
• Bi-annually measure data through with a data quality survey
• Audit data ownership procedures annually
• Build in data quality measures into applications
• Connect data quality results with performance incentives

Counter argument
• Regular audits and subjective measurement techniques e.g. surveys might be time consuming.

Design Principle 7: Formalised data exchange/enrichment

Description
All data exchange/enrichment activities are managed and approved by the appointed data strategist and the exchange of information must be subjected to a standardised methodology for information exchange/enrichment.

Benefits
• Control costs associated with data exchange and enrichment
• Protect operational data
• Improve data quality and value
• Data sharing to allow for better detection of fraud

Implication
• Development of a formal policy and methodology for data exchange and enrichment
• Data strategist must be responsible for approving data exchange/enrichment efforts and minimise cost.
• Identification and management of organisations that can enrich and/or validate the enterprise data.

Counter argument
• The formalised methodology should not become a constraint to enrich and improve data quality.
• The enterprise might not always be in a position to demand compliance from external parties to comply with data sharing standards.
• Current lack of industry standards might make it difficult to implement the principle.

Design Principle 8: Central repository of data naming standards

Description
Data names and field content must be standardised through a central reference repository and must be accessible to the business e.g. Street rather than str. is used to reference a street.

Benefits
• Consistency of information across all business processes
• Usability of information increases across the organisation.

Implication
• Alignment of all applications to support the standardised naming standards

Counter argument
• Difficulty to implement naming standardisation in some applications

Design Principle 9: Align information requirements with data model

Description
All information requirements must be aligned with the corporate data model before requesting changes to the information architecture:

Benefits
• Integrity of transactional data model stays in tact
• Prevent duplication of information

Implication
• The corporate data model must be maintained to be up to date at all times
• In any application development life cycle it is a condition to align the application with the corporate data model

Counter argument
Data owners might not understand the data model to update it with changes.

Design Principle 10: Information governance on all data elements

Description
All information elements must be subjected to information architecture governance

Benefits
• Sustain data quality
• Improve operational efficiency.

Implication
• Design the business process application of the data element
•Assign Applications sourcing the information
• Align with corporate data model, rules, validations, naming standard
• Define data management policies e.g. security, back-up, archiving/retrieval
• Assign data ownership

Counter argument
• Lack training to adhere to information governance
• Information governance is not adequately communicated

Design Principle 11: Data privacy and legality

Description
Client privacy must be respected and legal requirements must be complied with, in any event of data exchange or commerce

Benefit
• Maintain good relationships with clients and protect premium income
• Avoid legal costs due to mismanagement of information resulting in lawsuits.

Implication
• The enterprise must be up to date with laws relating to information
• Communicating The enterprise’s data policy to clients
• Legal department needs to be up to date with laws governing information usage, commerce and distribution

Counter argument
• Uncertainty of what constitutes data privacy might make it difficult to implement this principle.

Bottom line: Design principles for enterprise architecture must provide a decision framework based on a clear rationale defined in terms of the benefits, implications and counter argument relating to the design principle

Claudia points out the advantages and disadvantages of Flexible Content Models in this presentation.

in·for·ma·tion ar·chi·tec·ture n.

1. The combination of organization, labeling, and navigation schemes within an information system.
2. The structural design of an information space to facilitate task completion and intuitive access to content.
3. The art and science of structuring and classifying web sites and intranets to help people find and manage information.
4. An emerging discipline and community of practice focused on bringing principles of design and architecture to the digital landscape.

—————————- More Definitions ————————————

Information

We use the term information to distinguish information architecture from data and knowledge management. Data is facts and figures. Relational databases are highly structured and produce specific answers to specific questions. Knowledge is the stuff in people’s heads. Knowledge managers develop tools, processes, and incentives to encourage people to share that stuff. Information exists in the messy middle. With information systems, there’s often no single “right” answer to a given question. We’re concerned with information of all shapes and sizes: web sites, documents, software applications, images, and more. We’re also concerned with metadata: terms used to describe and represent content objects such as documents, people, processes, and organizations.

Structuring, Organizing, and Labeling

It’s what information architects do best. Structuring involves determining the appropriate levels of granularity[2] for the information “atoms” in your site, and deciding how to relate them to one another. Organizing involves grouping those components into meaningful and distinctive categories. Labeling means figuring out what to call those categories and the series of navigation links that lead to them.

[2] Granularity refers to the relative size or coarseness of information chunks. Varying levels of granularity might include: journal issue, article, paragraph, sentence.

Finding and Managing

Findability is a critical success factor for overall usability. If users can’t find what they need through some combination of browsing, searching, and asking, then the site fails. But user-centered design isn’t enough. The organizations and people who manage information are important too. An information architecture must balance the needs of users with the goals of the business. Efficient content management and clear policies and procedures are essential.

Art and Science

Disciplines such as usability engineering and ethnography are helping to bring the rigor of the scientific method to the analysis of users’ needs and information seeking behaviors. We’re increasingly able to study patterns of usage and subsequently make improvements to our web sites. But the practice of information architecture will never be reduced to numbers; there’s too much ambiguity and complexity. Information architects must rely on experience, intuition, and creativity. We must be willing to take risks and trust our intuition. This is the “art” of information architecture.

—————————- My Commentary ————————————

In summary, we, Information Architects, are the ones behind the scenes who lay out the content and information to be found in any web site. We are the ones who make it easier for all of you the users to find what you are looking for. Our work is seen in the layout (where the navigation, images, etc, is located on a page) of a web site or system.

What’s interesting about this is that library sciences is coming back in full force because of the amount of information at our fingertips and our need to categorize and organize it all into usable chunks. Librarians were doing this long before there was a web to be concerned about.

Usability is an important, though not the only, determinant for the success of a web site or an intranet. Information architecture is an important, though not the only, determinant for the usability of a design. There are other issues, but you ignore information architecture at your peril.

Critics may say that users don’t care about information architecture. They don’t want to learn how a web site is structured; they just want to get in, get their task done, and get out. Users focus on tasks, not on structure. But it’s because users don’t care about the structure of a web site that it is so important to get the information architecture right in the design. If users did bother to study our web sites, they could surely learn how an obscure or illogical structure works and utilize that knowledge to improve their task performance. Humans are flexible creatures and can adapt to hostile environments if they choose to do so.

But since we know that users won’t spend time learning our information architecture, we have to spend resources to design the best information architecture we can. Allow users to focus on their tasks, and let information architects be the ones to spend time worrying about the structure of the web site or intranet. This is a good division of labor, and the pay-off from good information architecture is immense. The more that answers are located in the places you look for them, the easier the design will feel to users, and the more successful the project. There will be more sales (for e-commerce sites), better reputation for good service (for marketing sites), and less loss of productivity (for intranets).

I am a great believer in having professional information architects design the structure of professional information projects such as corporate web sites and intranets. But I also think there will be an increasing role for personal information architecture in the future. It will soon be time to teach a simplified version of the discipline to high school students, and possibly even to bring it into elementary schools as well.

The modern world is one of information overload; we are constantly bombarded by an inflow of messages, and we ought to read much more information than we have time for. Keeping yourself from drowning in this morass of information will require personal information architecture skills for problems like structuring email folders and computer files as well as the ability to manage advanced search features.

In the long run, personal information architecture may turn out to be even more important than corporate information architecture. For now, though, read this second edition of Information Architecture for the World Wide Web and get your web site and intranet in shape to support your customers and employees. Good information architecture makes users less alienated and suppressed by technology. It simultaneously increases human satisfaction and your company’s profits. Very few jobs allow you to do both at the same time, so enjoy.”

Spoken by Jakob Nielsen
Quoted in “Information Architecture for the World Wide Web, 2nd Edition”