John Newton - How Web 2.0 will change the face of business

In the article "How Web 2.0 will change the face of business", John Newton does a really good job at describing what Web 2.0 is essentially about and what impact the driving forces behind Web 2.0 have to businesses and software vendors (such as Alfresco themselves):

Web 2.0 is explained more by example than by defining the technologies that make it up. A collection of brands provide the metaphors for what exactly is different in the way we use new web technologies, such as Google for search, YouTube for video, Flickr for photos, MySpace and Facebook for social networking and Wikipedia for wikis...//...These brands as metaphors become the nouns and verbs of describing Web 2.0 as a new way of socializing, communicating and sharing with each other in huge, consumer-scale markets.

Web 2.0 is not really so much a revolution in technology, but in how people use technology and how people interact with each other as a result of that technology.

As a result of the introduction of the internet, rapid infrastructure build-out and
the new generation of Web 2.0 sites, we have seen one of the most dramatic
democratizations of technology since at least the PC, if not the telephone. Through universal access, users discovered that computers could be used for far more than information; that they could be used as a medium of expression, sharing and revelation.

Software vendors are now jumping on the bandwagon with social software and collaborative features smelling a bit opportunity. Many are repackaged capabilities from another era of enterprise software. Some are looking at their portfolios and asking whether this is what they were doing all along. This misses the point. Web 2.0 has so far outstripped enterprise software as we know it in usability, accessibility and empowerment, that it causes mass rolling of eyeballs at its mere sight of not just the new generation, but most others as well. Those who are familiar with the ease of use and empowerment of Web 2.0 sites like YouTube, Wikipedia and Facebook are aware of what is possible and have much higher expectations. It will take a few years, but eventually they will figure out that Web 2.0 is not just a few new collaboration features and highly interactive web technologies, but empowerment of their users and the ability to draw in a critical mass of users from outside the trusted circle.

I could not agree more. I persistently argue that easy access and easy of use is a key part of Web 2.0 (as it is a key to empowering users). In the post "MOSS 2007 is missing the point with web 2.0" I take Microsoft as an example of a software vendor that seem to think that Web 2.0 is just a bunch of features, but I also conclude that it is a misconception that most of the old software giants have:

Web 2.0 is more than a bunch of new technologies – it represents a new paradigm in how people think and behave in how they use information technology. Much that was said about the web in the dotcom days (“the Internet revolution”) are actually happening today. Technology-wise, not much is new since the dotcom years. What is new is that the masses have adopted modern information technology and the Internet and practically made it to their own. Today, people are often faster at adopting new technologies than companies. They bring consumer technologies to work, they want to choose their own productivity tools (and do so) and see IT as a business thing rather than an IT department thing. To most people, IT is no longer an obscure thing.

In the hands of the old enterprise software giants, web 2.0 easily becomes a complex thing. Their ambition to extend and modernize their feature-packed software suits with web 2.0 applications and technologies might cause them to miss the whole point of web 2.0; the ease of use.

I have previously described some of my experiences from using SharePoint for collaboration, but I won't go into another argument whether or not SharePoint / MOSS 2007 is a good platform for collaboration or not - because it both is and it isn't. But it is not Web 2.0.

Experiences from using SharePoint for collaboration (file sharing)

From the comments to my post "SharePoint 2007 - Dream or Nightmare", I could tell that I need to give a little more detail about my experiences from using SharePoint as a collaboration platform. I will try to do that in this post, but I must first say that it is hard for me to tell if the issues that I am experiencing are the specific to the installation I am using or not. Although I have in-depth experience from developing and implementing ECMS, intranets, portals and web-based collaboration tools, I am just one end-user among others when it comes to SharePoint. I have no deeper insight into either the architecture or what features come out of the box of SharePoint and what needs to be added or customized by custom development as I do not work with SharePoint from an implementation perspective.

However, one of my main points in my critique against SharePoint is that SharePoint – as Microsoft claims SharePoint to be a collaboration platform - should provide better capabilities for a smooth collaboration experience out of the box. As end-user I am not interested in investing time and effort to know the architecture of SharePoint in order to use it. I also suppose that most businesses are not happy about having to invest a lot of time and money in customization and custom development to get the basic capabilities for collaboration when they purchase a product that claims to be a collaboration platform (such as SharePoint).

I would like to utilize the collective intelligence of the readers of this blog to help me identify the root causes of my problems and suggest solutions to them, as I know there are many of you who are skilled and experiences in relevant areas (such as SharePoint 2007) and since I might just having problems with symptoms of something else than actual flaws in SharePoint. To get you started I will try to describe my usage context:

As IT management consultant, I often team up with colleagues for team deliveries. As we might work from different locations and have other assignments in parallel, we have to do much of the work on distance. So we need some collaboration tools besides phone and e-mail to support us. Our basic need - which I believe can be addressed by SharePoint - is to be able to share and collaborate on files, primarily MS Office documents, together. We simply need to be able to store the files somewhere we all can access, find and update them in a controlled manner. More specifically, this is what I personally expect from a collaboration tool that supports file sharing:

• Easy access to the files so that we can access the files from any computer or device equipped with a web browser
• A user interface is simple to use so that occasional users can find their way around and perform their tasks without the need for education
• The possibility to organize and tag the files so that users can find them easily by browsing and / or searching
• The possibility to share the documents with anyone we want to share them with, includes notifying them how and where to access the files

Now back to SharePoint. I have trouble doing the following in SharePoint:

• Accessing my files in an easy way - I can access SharePoint from a web browser via a secure gateway, but it is a process that navigation wise takes a lot of time. I would like my SharePoint sites to appear as virtual drives on my computer even though I am not logged on to the domain with the computer.
• Finding my way around – I have had to invest a great deal of time in getting to know the SharePoint environment to be able to find my way around in SharePoint. Options that are likely to be used frequently are hidden with a lot of other options in cascading menus.
• I have found no possibility to tag files with my own tags and to organize the files in folders is anything but a smooth experience. To move a file from the web interface, I first need to know the URL of the destination folder! In addition, instead of copying a document which is already located somewhere else in SharePoint (or even outside of SharePoint), I would like to link to the document from a folder but I have found no easy way to do this.
• It is not possible to share documents with users outside our domain. I would like to be able to send an e-mail with a link to the document and that the receiver of the document can download. Or, I should be able to select a document from within SharePoint and send it as an attachment via e-mail.

I have already invested time and effort in trying to understand the SharePoint environment. My key concern however is to get the people I need to collaborate with to use the SharePoint for collaboration. The main obstacle is, besides the usability of MOSS 2007, that it is hard to access files and resources in SharePoint when we are outside of our domain or using computers provided to us by our clients.

Please enlighten me on how to make the collaboration experience smoother.

Collaboration and SOA - more than just buzzwords

I tried to answer a question yesterday that I got sent to me via e-mail from an employee at the client company and who is located in Portugal . To be able to answer the question, I had to request information from two persons in my team, one of them being located in Switzerland and one being located in another city in Sweden. In a few minutes I had answered the question and received an e-mail from the employee in Portugal in which he thanked me for the answer. Thanks to the information in my answer, he could continue with his tasks at hand. As I mentioned something about this conversation to my client sitting almost next to me, he said "Isn't it fantastic? That we can sit here and communicate with people all over the world within a few seconds?"

I had to admit that it is quite fantastic. His question got me to reflect on how surreal my current assignment must have seemed just 20 years ago; I am planning and coordinating activities which involve hundreds of people (editors) all over the world, people who are located in countries such as Japan, Sweden, USA, Russia, China, Portugal, and France. I have direct contact with well over fifty of these people, primarily via e-mail or phone. We meet once a year on a conference and then never travel to meet face-to-face.

The project team that I am managing and which is responsible for rolling out new IT solutions to the markets (which we must help all the editors need to learn, prepare and launch) consists of a handful of people. We are partly co-located, but some of the team members work from other locations. We mostly communicate via phone or e-mail and when there is a need for us to meet in a more structured way, we use a web conferencing tool (WebEx from Cisco). We basically never need to travel to get things done. Often, it is just not a viable option. In addition, the corporate policy says that travelling should be avoided for environmental and cost reasons whenever possible.

Although we have much more to do to become more efficient in communicating and collaborating with each other, it is interesting that our biggest headache is not about communicating or collaborating within the project team, with the editors or with all stakeholders in different organizations. No, our biggest headache is the one we get from the constant battle we have to fight with the IT legacy. The problem with the IT legacy is, as usual, that it was not originally designed for the current requirements and that is almost possible to change. The short version is that it is a very complex and lengthy process to get things out to the market (or even at all). Add to that that the inflexible IT legacy adds a lot of extra friction between the ordering organization and the organization supplying it with IT solutions.

I personally both understand and stress the importance of separating the concepts of SOA and web services, one being an architectural style and the other being a technology that can be used for implementing a SOA. Still, I must admit to that web services are excellent for demonstrating key SOA concepts as well as for demonstrating the potential benefits than an organization can get out of SOA. SOA and web services go hand in hand. Even though I now work on the business side and not on the IT side, with people coming from a marketing and business administration background instead of an IT background (I have a combination of both), there is now a common understanding between the ordering organization (“the business”) and the supplying organization ("the IT department") that SOA is the way to go. SOA is no longer just some mysterious or over-hyped buzzword. Why? Because we have all seen a SOA in action.

For a small but essential part of the current solution, core software functionalities and content are now provided to consuming applications via web services. On top of the web services layer, different user experience applications can be designed and developed. Fast. And it can be done by external parties. The latter is virtually impossible today for other parts of the IT platform, even though the task is mostly about presenting existing things in a new way. They will have to navigate in a very complex IT environment and sometimes make changes all the way back to the legacy systems – which of course cannot be changed within the time-frame of the project, so you end up having to scope out functionality and content which would be valuable to end-users. To sum up, new solutions can be delivered much faster since core functionalities and content can be easily reused and thereby shortening development time AND since external capacity can be used to deliver them.

I am absolutely convinced that the keys to empowering enterprises today is to better support communication and collaboration between people and to increase the agility of their IT systems. Improving communication and collaboration is to me a low-hanging fruit since the tools and technologies are out there, although it is a big challenge since it has more to do with people and changing their existing attitudes and behaviors than it has to do with technology. Increasing the agility of the IT systems will in most cases be a costly and potentially very lengthy process, but it is an inevitable investment enterprises need to make if they are to compete on a global and rapidly changing market place.

The lingua franca in application development

A wire-frame is no deliverable of the design phase of a application development project; it is a collaboration tool. Used as such, it can integrate the so often separated worlds of visual design, content design, interaction design and technical design. If a wire-frame is not used as a collaboration tool, the value of wire-frames can in fact be questioned.



I have used wire-frames (including annotations) successfully in many projects. Accompanied by other artifacts such as a site map, interaction (activity) diagrams, design rationale documentation and use case descriptions, they are very powerful tools for rapidly communicating, negotiating and agreeing upon requirements and the overall design during an application development project. The secret with wire-frames is to create them with the intended audience in mind.

I have also seen wire-frames being misused several times. The typical misuse is that an external design agency, which is typically responsible for the visual design and interaction design, uses wire-frames internally in their in-house design process. In that process, they do not involve external stakeholders such as content authors and the application development team that is to design and build the application. Instead, they deliver the wire-frames together with a site map, style guide and other artifacts as a part of their final delivery, naively expecting the receiving application development team and content authors to use them blueprints for building the applications and developing the content. The problem is only that it is not possible to implement them at a feasible cost and that they do not fulfill the content requirements. So the design agency is forced to return to the drawing table, annoyed by all the "criticism" (feedback) that "questioned" (provided input to) their design solutions. At this point they should realize that they need to open up a dialog with external stakeholders, but they probably won’t.

Properly used, wire-frames provide a language which all parties in a development project can understand and talk and a vehicle for messages at the same time. IT people, user experience designers and content authors get a means to talk with and understand each other. If wireframes are used as collaboration tools in a dialog with designers from the other design disciplines, wire-frames will serve as the lingua franca in application development.

A simple illustration of the power of simplicity

This one is no April fools joke. Eric M. Burke illustrates how simplicity is a key to success in a very simple (understandable) way:

Is the IT industry finally getting the message?

Apple, Google, Nintendo...what do most of their products have in common? Well, I would say that they are attractive and intuitive to use. Why? Because they have been designed with the consumer / user in mind. They have been designed to be as simple as possible to use, but not simpler. If they would be too simple they would be considered as naive (= not interesting).

Now it seems like the IT industry is finally starting to get the message of simplicity. In an article at DestinationCRM.com, Lauren McKay reports from the AIIM 08 conference and the keynote by AIIM President John Mancini that "The Future of ECM Is Simplicity":

"The iPod. Nintendo's Wii. Google. TiVo. What do these products share in common? Besides their obvious success, all are linked by a single buzzword -- simplicity...//... The implementation of simplicity is key, Mancini told the audience during his industry address at the annual AIIM summit. Yet there's nothing simple about simplicity when it comes to implementing enterprise content management (ECM), he said"

I get all warm inside when I read this. With simpler content management technologies, enterprises might begin to focus their efforts on actually managing content instead of trying to implement and manage content management systems.

Here are a few of my own posts on the subject of simplicity.

• Just think S.I.M.P.L.E.
• The Curse of Portal Software
• Enterprise Wikis and Permission Management
• Expensive Things Must Look Advanced
• What Users Say They Want Isn’t Always What They Need
• Why Folksonomies Work

I'll end this post with my favourite quotes about simplicity:

"Simplicity means the achievement of maximum effect with minimum means."
(Dr Koichi Kawana, designer of Japanese gardens)

"Simplicity is a virtue."
(Ingvar Kamprad, founder of IKEA)

"Everything should be made as simple as possible, but not simpler"
(Albert Einstein, a smart guy I know)

Just think S.I.M.P.L.E.

In design disciplines such as industrial design, simplicity is often considered to be a virtue. But for some reason, simplicity does not seem to be a virtue in software design. Why is it so? I personally believe that a lot of the software is not designed by designers with the right mindset. And even if they do, they are run over by sales people and engineers.

Here is my definition of S.I.M.P.L.E. which helps me get into the right mindset and understanding what is most important when designing user experiences:

Suited for its purpose
Intuitively understandable
Made to work
People-centric
Less is more
Empirically validated

Here are a few of my previous posts related to the subject of simplicity:

• Expensive Things Must Look Advanced
• What Users Say They Want Isn’t Always What They Need
  

This week in links - week 6, 2008

Matthew Hodgson writes about the need for more granularity in user roles in order to make the right decisions on what kinds of functional requirements that will meet user needs:

"Do you allow people to comment, review, rate and ask questions on your website’s articles? If you do, you’ll be enjoying the fact that your own users are helping others know what information is valuable on your website. It’s also valuable feedback because it helps you improve the quality of your information. Over the last month, I’ve been working on a strategy for a client to help them introduce this sort of user-to-user and business-to-user interaction. My client though, has until recently, thought of their users in the same way they do their print magazine. This has meant that their market segmentation is broken down into 3 (non-mutually exclusive) roles:

1. those that use the website,
2. those who read the magazine, and
3. those who buy stuff.

Unfortunately, this is not enough granularity to make informed decisions on the functional requirements that are necessary to meet user’s needs. By using the taxonomy of social computing, the market segmentation, and user needs, become much clearer."

Kyle Gabhart argues that EA, SOA, BPM and so forth are all different labels on initiatives trying to address the same kinds of problems in enterprises, such as:

• "Business and IT need tighter alignment
• Visibility between business and IT should be increased
• Governance is needed at various levels of the organization to reduce risk
  and protect ROI
• Business processes and technology solutions should be more flexible and better able to adapt to changing demands
• Business processes and technology solutions should be designed intentionally and with sufficient rigor

The labels attached to these trends vary from enterprise to enterprise. Some drive toward one or more of these goals under the EA umbrella, others under the BPM label, and still others are talking about SOA. Some organizations use two or even all three labels. Regardless of the attached label, it is a strategic initiative at the business unit or enterprise level that aims to improve business predictability and squeeze more value out of technology investments."

Stewart Mader lists 7 strategies from the Society for Information Management's Advanced Practices Council for implementing a successful corporate wiki, the last one being the most important according to me:

"7. Understand wikis are best used in work cultures that encourage collaboration. Without an appropriate fit with the workplace culture, wiki technology will be of limited value in sharing knowledge, ideas and practices. (90-9-1 Theory)"

Put ease of use in focus - please!

I have been writing in previous posts about IT Departments that do not understand the importance of ease of use and listening to user needs. David Gurteen linked to a post by Lee Bryant and I found it so funny that I had share it.

"The same IT folks who rail about the "risks" of sharing and online social networking are also responsible for creating systems so unusable and inflexible that they lead users to dump entire databases onto CD and lose them. I think it is fair to argue that IT systems that do no nderstand people are a bigger risk than human-scale web computing that treats people as adults."

(on how UK Customs and Excise could lose two CDs containing 25 million highly confidential Child Benefit records and the bank details of 7.25 million individual recipients)

Here are a few of my own posts on (almost) the same the subject:

• Things that the IT Dept shouldn't be doing
• Rules are meant to be broken
• Is the IT dept not interested in business innovation with IT?
• Enterprise 2.0 and the shrinking IT department

Will Web 2.0 Drive Knowledge Management?

Knowledge Management has a history. I wrote my first report on this subject back in 1996. Knowledge Management was then defined as a systematic approach to manage corporate knowledge to achieve business value. It is a general definition that still has merits. Some research and practices back then focused on managing knowledge assets with information technology and others on the dynamics of organizational collaboration.

Common practices to create, manage and transfer knowledge have been:

• Communities: Collaborative groups that span across organizational boundaries.
• Best-practice: Reusing knowledge via work descriptions, offerings and similar.
• Knowledge maps: Map knowledge to specific work processes or situations.
• Knowledge profiles: Describing knowledge workers’ roles and resources.

The above practices have often been enabled by means of content and collaboration technologies such as messaging, e-mail, document management, portals, enterprise content management, search and the like.

Content can be seen as a seed of knowledge. But extracting the knowledge and acting upon it require first, that people need to interpret the content to understand the intended information and second, people need to ponder the information for knowledge to emerge. As argued in a former post:

“Content can be managed with the means of (information) technology, but we cannot manage information and knowledge with technology alone since information and knowledge are created and exist only in the heads of humans.” (Back to Basics - Defining Data, Content, Experience, Information And Knowledge)

For Knowledge Management to succeed in an Enterprise it is, for the above reason, essential that appropriate roles, cultures, incentives etc are in place. This will encourage a knowledge sharing environment (knowledge market) necessary for better innovation, smarter services, increased learning, higher productivity etc.

So, what can Web 2.0 technologies and practices add to Knowledge Management?

Web 2.0 is fostered in an agile, open and distributed atmosphere. Recent social trends embrace more open collaboration where content is created and shared in self-organizing networks and communities. This attitude may be what is missing in many failed Knowledge Management initiatives, where company workers have been reluctant to join forces and share what they know.

Web 2.0 technologies for user generated content (e.g. wikis and blogs) and metadata (e.g. social tagging and bookmarks) will simplify the production and consumption of content. Other technologies such as feeds, mashups, web services, ajax etc will have a role in developing a more flexible and richer web user experience more suitable to the needs and preferences of knowledge workers.

Social interaction (e.g. profiles and social networks) has possibly the largest potential in adding something innovative to Knowledge Management. Knowledge workers may market their knowledge and interests and passively or actively strengthen their relationships across company borders.

I think it is safe to conclude that Web 2.0 will drive Knowledge Management to another level.

Enterprise 2.0 vs. Web 2.0 (Chicken vs. Egg)

Some say the web is evolving into another version, often called Web 2.0. Others talk about the evolving Enterprise, and use a similar 2.0 appendix. New technologies enable new ways of working and fresh ways of working lead to technology innovations. Often it is difficult to pinpoint what is the chicken or the egg in this creative process.

How to define Enterprise 2.0 and Web 2.0? Depending on whom you ask you will most likely get different answers. Useful perspectives in understanding the Enterprise/Web 2.0 phenomenon are:

• Business: Leaders of the Enterprise 2.0 movement are aiming for business models that are agile, open, distributed, on demand etc. These concepts are supposed to contrast to traditional hierarchical and bureaucratic organizations managed using order and control mechanisms.
• Technology: IT people promote that services and content can be reused and re-purposed using techniques such as Feeds, File Sharing, Mashups, Web Services etc. Ajax (Asynchronous Javascript And XML) is the main driver behind a richer web user experience. User generated content and metadata are produced via Wikis, Blogs, Folksonomies and the like.
• Human: The consumer (end-user) seems to be the king when it comes to adopting new practices and technology. Current social trends embrace more open collaboration where content is created and shared in self-organizing networks and communities.

One key question for Enterprises is how to utilize these emerging business, technology and human fields. Many enterprises are probably eager to implement Web 2.0 technologies, but will the technologies bring the desired benefits without implementing the business and human fields? Enterprise 2.0 evangelists will probably have difficulties in realizing their business visions without the technology and human fields.

So, which came first, the (Enterprise ) Chicken or the (Web) Egg? Without being to philosophical I think we can conclude that the chicken and the egg are interlinked and mutually dependent on each other for survival and wealth.

Documenting the Design Rationale Behind a User Experience Design

Many of the user experience designers I have worked with in web projects have been very skilled and experienced. Even so, I have rarely encountered a designer who has explicitly documented the rationale behind the design - why a certain design decision was made, what alternatives that were considered and why they where discarded during the design process.

Documenting the design rationale can be as simple as providing some pros and cons together with each design sketch and then recording which design sketch was chosen and for what reasons. If any changes are made in-between two sketches, those should of course also be described and motivated.

One of the main benefits of documenting the design rationale is that it is easier to anchor the design with stakeholders. Besides that the designer probably will have to think through the design suggestions more (which will probably lead to a better design in the end), it also forces stakeholders to motivate both their decisions and any critique of the design suggestions. Simply put, it will be easier to discard all those personal opinions (“I want to have the button there”) that are a nuisance in most design processes. You simply point to the common practices, best practices, usability heuristics, guidelines etc that you have motivated the design suggestion with. It will move you faster to a final design and can radically shorten the design process.

I have twice in my career experienced how someone in the upper management has suddenly intervened in the design process and decided to change from one icon to another. I don’t know if it is common that managers possess special skills in icon design and usability or if these situations really can be avoided by documenting the design rationale, but at least decisions like these will be documented with why and by whom the decision was made. As motivation behind the design decision it will probably have to say “Because manager X wanted it”.

Expensive Things Must Look Advanced

I once (in the late 90ies) helped a Swedish insurance company to design the UI of a workflow application for managing insurance cases. The application was integrating and adding workflow functionality to a number of legacy systems that had text based UI:s. The users were required to toggle between them when performing a task and the workflow routing was completely manual.

After having demonstrated a prototype of the new UI for the steering committee by walking through an entire workflow scenario in only a few minutes, I got the evil eye from the project sponsor who irritated asked me “Is that all?!” “Eh…yes, that’s all” I said, wondering what I had said or done wrong.

I was surprised at his reaction since all of the users who I had involved in the design process had been very happy with the results. It clearly simplified their daily work, not the least it reduced the cognitive load of having to remember information when toggling between applications. It also significantly reduced the time to complete an entire workflow, which was exactly what I demonstrated for the steering committee and project sponsor. But the project sponsor expected to see some evidence of where his money had gone, which I obviously had failed to show him.

I can understand how he was thinking – if you pay a lot for something, then you generally expect it to be advanced (meaning complex), especially when it comes to technology. If it looks really simple, then you are likely to feel ripped off. Where did your money go? To social activities of expensive consultants?

This way of thinking is also the reason why many CIO/CTO:s get dazzled when software vendors are showcasing their advanced (complex) new products or showing PowerPoint presentations about them that are stuffed with 3D boxes, arrows and abbreviations. As a software vendor, you simply cannot sell the latest version of your product to anyone by telling them it has been greatly simplified and that you even removed some of the old features so that it gets more efficient to work with. No, efficiency in the IT industry has since long (since ever?) been synonymous with adding new and more advanced (complex) features. If a vendor would actually simplify a product, then they would instead have to point to all the new and advanced under-the-hood technologies that have been named with mysterious three-letter abbreviations.

I know this by now - simplicity does not sell. Of course, most users like simple and easy to use applications once they start using them. But before they start using it, someone probably has to pay a lot for it. And it needs to be advanced (complex) if that someone is going to buy it. It is as simple as that.

What Users Say They Want Isn’t Always What They Need

In 2004, me and my co-blogger Anders Bännstrand defined and designed the user experience of the first version of hitta.se, now the leading Internet service for finding people, business and locations on maps in Sweden. The service was developed from scratch with a new and unknown brand, set up to compete with the market leader eniro.se.

Many things made the service become a success, one of them being a simple and convenient user experience. And a big part of designing the user experience was involving users to test and evaluate it. But before involving any users, we set up a number of guiding principles to lead the design:

• It should be fast, consistent, forgiving and give clear feedback.
• It should present important information, including maps, as quickly as possible after a search was executed.
• It should have a human touch to the visual design.
• But above all, it should be simple, simple and simple.

Quite recently, the competitor service eniro.se was redesigned in order to be able to compete better with hitta.se. When launching the new version, Eniro proudly communicated how they had involved users when defining and designing the new user experience. Enhancement requests were gathered from users and user involvement played an important part during the design process. But, what strikes me is that the principle of simplicity seems to have got lost somewhere in the design process. Simplicity is very tightly related to the concept of consistency, which is about holding together and retaining the shape of the service throughout the entire user experience. This is something every designer should know. Nevertheless, eniro.se almost feels liquid, entering a new shape at each page reload.

Regardless of what users say they need from a utility service such as hitta.se or eniro.se, it is reasonable to assume that they first and foremost need a fast, simple and convenient user experience. If you start out with that approach and stick to it throughout the design process, user involvement will help you to develop a great user experience. You should listen to what the users have to say, but when listening you should filter everything they say through the "Simplicity filter". Because what users say they want isn’t always what they need. They often say they want a lot of features, but what they probably want the most is something that is simple and intuitive to use.

"Simplicity means the achievement of maximum effect with minimum means." — Koichi Kawana

Is User Experience Also a Quality?

You might wonder why the concept of user experience is not mentioned in my previous post. Peter Merholz presents some really interesting thoughts in his post "User Experience is a Quality, Not A Discipline" from 2005:

• "Usability is simply a quality. It's an important quality, but just one of many. And it definitely doesn't warrant being a "discipline."
  
• "User experience is not a discipline, or an approach, it's a thing, a quality, an emergent property between a person and a product or service.
  
• "This puts me in direct opposition with Jesse's diagram. Those aren't elements of user experience. Those are elements of web design."
  
• "User experience should not be just about interactive systems -- it's a quality that reflects the sum total of a person's experiences with any product, service, organization."

I basically agree with this reasoning, especially that usability is a quality and that Jesse James Garretts model "The Elements of User Experiences" is focused on web design. Which Jesse also declares in his book with the same name: "This book is about the user experience of one particular kind of product: Web sites". But I don't agree with Peter that the user experience is simply one quality among many others.

A user experience of a product, service or organization is the sum of all its qualities as perceived by the individual user who experiences it. It also includes the value dimension. Furthermore, each user experience is affected by all previous experiences the user has had with the product, service or organization in question. In a sense, the user experience is the overall quality of a product, service or organization as perceived and experienced by an individual.

Hence, I have not made user experience to a quality among the others in my post "The User Experience Onion". A user experience is not an individual layer of the onion, it is the sum of all layers, the onion itself. And the user experience is created when the content product ("the onion") is consumed by an individual user.

If you are interested, I borrowed the onion metaphor from the animated movie Shrek.

SHREK: For your information, there's a lot more to ogres than people think.
DONKEY: Example?
SHREK: Example? Okay, um, ogres are like onions.
DONKEY: [Sniffs] They stink?
SHREK: Yes. No!
DONKEY: They make you cry?
SHREK: No!
DONKEY: You leave them out in the sun, they get all brown, start sprouting' little white hairs.
SHREK: No! Layers! Onions have layers! Ogres have layers! Onions have layers.You get it? We both have layers. [Sighs]
DONKEY: Oh, you both have layers. Oh. [Sniffs] You know, not everybody likes onions. Cake! Everybody loves cakes! Cakes have layers.
SHREK: I don't care... what everyone likes. Ogres are not like cakes.
DONKEY: You know what else everybody likes? Parfaits. Have you ever met a person, you say, "Let's get some parfait," they say, "Hell no, I don't like no parfait"? Parfaits are delicious.
SHREK: No! You dense, irritating, miniature beast of burden! Ogres are like onions! End of story. Bye-bye. See ya later.

The User Experience Onion

The value of a rich and high quality user experience cannot be overestimated. In the content economy, the user experience is a key differentiatior between content products and ultimately what will make it a success or a failure. But, what exactly is contained within the concept “user experience”? Which are the key questions to ask when developing a content product – anything from a simple newsletter or whitepaper to an entire web site or e-learning application – in order to create rich and high quality user experiences?

Jesse James Garrett defines user experience as “how the product behaves and is used in the real world”.

In other words, creating rich and high quality user experience is about getting to know and understand the users and identify the qualities that a content product must possess to create superior user experiences for them. After that, it becomes a matter of realization, requiring a certain amount of skills, resources and luck.

I like to look at user experience as an onion with many layers where each layer needs to be there and be of a certain thickness to create a positive user experience. And the thicker each layer, the greater the total user experience will be. Here are the main layers and the key questions to ask to determine the existence and thickness of each layer:

The Content Layer - Does the content product deliver the actual benefits or value that the user is looking for and expecting? Is the content purposeful, relevant, correct, up to date and complete?

The Functionality Layer - Does the content product provide the necessary capabilities so that the user can interact with the content as desired? What can the user do with it?

The Presentation Layer - Is the product presented visually so that it communicates the content and functionality in an efficient and appealing way, encouraging interaction?

The Usability Layer - Is it easy for the user to use the content product for the intended purpose? Is it easy to understand and use it?

The Accessibility Layer - Can users with disabilities, from visual problems to cognitive impairments, use the content product? Can a user that should have the right to access the content product access it? Can it be accessed where and when the user desires to? (the last two questions are not within the scope of the traditional definition of accessibility)

The Findability Layer - Can the user easily discover, locate and retrieve the content product?

The Brand Layer – Is the brand known to the user and how strong is it? What kind of expectations does the user associate with the brand? What emotions does it trigger? What previous user experiences are connected to the brand?

The Content Layer is of course the heart of the content product user experience. Each layer above the Content Layer is there to enable and enrich the usage of it.

The Brand Layer is to me in a way the most interesting layer. A thick Brand Layer, a stong brand, can in some cases – at least in the short run – compensate for very thin layers underneath it. And the other way around, a content product with superior content, functionality, presentation and so on can create superior user experiences and become successful basically overnight even though the brand is totally unknown.

I will explain the dynamics of this User Experience Onion model further with a real world example in a coming post. And possibly even provide an illustration of the onion.