Emerging World of Free

Recently saw a video of a talk by Chris Andersen (of The Long Tail and Wired fame) on Emerging World of Free. He talks about how in today’s world the resources of Bandwidth, Storage and Processing power are approaching zero, that is, becoming free, and how it impacts businesses. He says that previously the limited shelf space in a traditional store was a limiting factor in the variety of goods available in that store. There was only space for the most popular brands, and a “One size fits all’ approach ruled. There was no space for satisfying the long tail, the custom made, the marginal tastes. With the emergence of the internet as a virtual market place, with infinite shelf space at zero cost(cost or the underlying technology approaching zero), you have the possibility to cater to the Long Tail, satisfy unlimited choices, tastes and provide infinite options to the consumer.

For me this was particularly insightful since it opens up a previously untouched, unlimited market. We always think that newer emerging markets are those people who have never used our product. While this is certainly true for developing countries, what about the ‘saturated’ markets of the developed world? The internet as a market place offers vast possibilities in these tech savvy nations to tackle the yet untapped Long Tail of the curve: the niche, customized market, where each consumer is spoilt for choice, AND is willing to pay more for it. And going by the numbers which Chris showed, the Long Tail contributes to anywhere between 25 to 50% of the total market depending on the product!!

I would think the virtual marketplace would fit in very cosily in the the gaps left by the traditional stores. For any business, both can share a symbiotic relationship and leverage each others strengths and eliminate their weaknesses. There is already a lot of activity happening in this space, and as Google said: we are moving from a dozen markets of millions to a million markets of dozens...

The video can be seen here.

Productization of Services

A slow revolution which has been brewing up for quite a while now is the Services Revolution. As more and more companies across the world are formally recognizing services as products, we as designers need to think what it means for us. Before I go into details, we need to clearly define what a Service is. Definitions vary, but broadly we can say that a Service is an amalgamation of Products and Processes, which jointly fulfill a user’s need. A Service comprises of both Tangible and Intangible components as opposed to a product, whose physicality is its defining feature. Also, a product is typically manufactured before it is used, whereas a Service comes into existence at the same time as it is being used.

In retrospect, probably the shift towards a Services mindset was inevitable as the need for integration between various product lines to provide end to end solutions to the customer became crucial. There is a distinct shift in the way a company looks at its offerings today, not as Products (which is a decidedly corporatish view), but rather as End to End Solutions, which is looking at it from a User’s point of view. In keeping with this, Enterprise software companies like SAP, are moving towards E-SOA (Enterprise Services Oriented Architecture) which is end user scenario oriented, not product oriented. We can no longer afford to look at Products as silos, and expect users to switch between half a dozen softwares, to complete a single task. There needs to be much stronger seamless integration between these products, so much so that they appear as one to the end user.

Now, what it means for us as designers is:

• The focus on user Experience in a Services approach is much more than before, since that is the whole idea of a service: to look at your offering from an end user’s point of view.
• We need to stretch our focus from traditional Product Design into areas which previously may have been covered by other teams like Service Definition, Business Model etc. Our approach needs to be much more holistic.
• Service Design is much more inclusive than Product Design, because more often than not, the users of a service are heavily involved in designing it as well.
  
• The Triad of Designers, End Users and Service Providers need to work closely together to define and manage the services.
  
• Customization and the flexibility to customize becomes much more crucial because One size doesn’t fit all. We may increasingly have various flavors or schemes of the same offering to suite different user groups.
• Service Design is a much more evolutionary process.It involves many iterations based on user feedback and satisfaction assessment.
  

However, Service Design is still an evolving field, and there are many Open Issues which need to be answered. For example, Who 'owns' the Service: the user, the designer or the service provider? Can we even look at ownership in the same way as we look at for Tangible products? How do we measure the User Friendliness of a service? Is there a standard process to design a Service, like the UCD Process to design products? Probably these questions have already been answered by someone somewhere on the repository of collective intelligence called the internet, but they are certainly open in my mind anyways...

An Elephant with a Rabbit’s heart

This might appear as a queer Title, but then a well designed post should have a catchy title to attract interest :)

But this title really summarizes the Business and Growth strategy of any successful organization today. I think classically it has been believed that the Business and Growth strategy of an organization would largely depend upon its size, domain and duration of its presence in the market… But increasingly, it is becoming evident that this differentiation is fast disappearing. Successful organizations all over the world behave more and more like start-ups, irrespective of their size, or time in the market. That appears to be the only way to achieve the speed of growth necessary to survive in the market. The agility of an organization in changing itself according to the changing markets is imperative for survival today. Shifting focus quickly and efficiently from one area to another, organization restructuring, scope for innovation are as crucial for behemoths like Google, Microsoft, SAP today, as they are for little known start-ups. Probably that’s why companies like Google try very hard to maintain a culture of a start-up with the simple rule ‘There are no rules’. I remember reading that the employee of tomorrow would be like a Construction worker in his agility: a group of employees would come together as a team to complete a project, disintegrate, and then reorganize in some different team to complete a different project. There would be no fixed teams, working on the same product for ages, and to apply your core skills in different areas with ease would become crucial. Businesses even today are increaingly focussing on their core competecies, and virtually all other Administrative, Maintenance and Support activities are outsourced.

Today, it is as crucial to build a healthy eco-system around your company, as the growth of the company iself. We will have to be increasingly collaborative and flexible in times to come,and the adage 'If you cant beat them, join them' would become the mantra. Probably thats why more and more forward-looking companies are actively nurturing and contributing to the Open Source movement, with a view to nurture their eco-systems. The only monopoly that can survive in today's world is the one formed by the people, for the people, the one resting on the collective shoulders of thousands of unknown, yet powerful shoulders. Hmm….we live in interesting times.

Designer Religion?

Have been recently reading a book called ‘The God Delusion’ by Richard Dawkins.

Must say it is one of the most insanely rational and gripping books I have read in a long time… As the title suggests, the basic premise of the book is that the existence of God is highly improbable, and Religion is a just a convenient by-product of our psychological needs. Also, religion has evolved over the centuries (with healthy amounts of designing by some powerful people across different eras) to become what it is today.. Of course, the backbone of this entire theory is that there is no scientific proof of God’s existence, and most scriptures have been distorted over the centuries by the Chinese Whispers phenomenon, into what they are today…

The author mainly looks at Christianity, Judaism (& Islam) as the main monotheistic religions of our times, and how they foster in group kinship and out-group hostility. The ideology that My God is the only God, or my faith is the true faith gives these religions a coating of violent intolerance towards anyone not belonging to their creed. Makes me wonder as a Hindu, whether a polytheistic religion like Hinduism makes one more tolerant? With its selection of thousands of Deities to choose from, you can decide whom to worship. It offers you much more flexibility to choose, and fosters tolerance for coexistence of many other deities in the name of faith…. probably it is a gentler religion…

But even if we do consider the radical idea that Religion is ‘designed’, the fact that the Design has evolved over centuries has given it its robustness and power…something similar to the way the Indian Lota was designed, and its resulting ubiquitous popularity in India. In any case, it has a huge fan-following, because it carries all the hallmarks of a good design:

• It satisfies the needs and desires of the ‘User’
• It arouses powerful emotions within the ‘User’
• It is intuitive, user-friendly and an effective tool to use in day to day living
  

No wonder it has such huge Brand Equity, and irrespective of whether Dawkins is right or not (there is a strong probability he might be), it isn’t going to go out of vogue anytime soon!

Beautifully Designed Spaces…

I have been working for about 1.5 years in SAP, and one thing that never ceases to give me pleasure is my Workspace in office.

The main Development Block at SAP has 3 wings, and each wing has an Open Courtyard at the center. Now this courtyard, I suspect has been designed according to Feng Shui Principles(the literal translation of Feng Shui is ‘wind-water’) . it is very green, and has an artificial waterfall in the center. Flowing water increases the positive energy in a space known as ‘chi’. Huge caldrons filled with water are kept at strategic locations, and there are always flowers or rose petals floating in them.

The sound of flowing water from the waterfall gives a very soothing feel; and the open courtyard keeps you connected to the outside world in a way that such artificially designed enclosed spaces seldom do.

This is in sharp contrast to the other office spaces I have worked in; where the raindrops falling on your face always surprise you as you step out, because you were not aware it was raining outside as you worked under artificial lighting within.

Another way in which this open courtyard makes a difference is the lighting…the changing lighting from noon to evening, or as the sky gets covered with clouds, makes one aware of the changing weather and the passage of time in a very subtle and natural way.

I remember a friend of mine at NID made a set of Desktop widgets representing nature, and tried to connect them to the outside weather, so that one can be aware of the weather outside in the enclosed office space. I think technology is not the answer to every problem around us, sometimes it may just complicate a problem even more.

Probably what we need are better designed spaces…spaces which make the transition from the outdoors to the indoors more seamless, less drastic. That is why I am a great fan of Skylights. Skylights are one way which can lessen the disconnect between the outside and the inside world, and do not even require extra space, as for example, a courtyard might.

My favorite time of the day is late evenings, when most of the people in the office have left, and all I can hear is the sound of flowing water; uninterrupted by the sounds of keyboards, printers and people as it is during the day….aaah…what bliss!

“Alarm Bells” in User Research

I have gone to many big SAP customers in India for User Research and there are a few things i have learnt to be wary of when going to big Organizations for User Research:

• Set the expectations right beforehand itself. You haven’t gone to talk about new features in the upcoming releases, you aren’t from Marketing, you aren’t there to provide Technical support. Too much time gets wasted till they actually understand the purpose of your visit.
  

• Guard against spending too much time in the Boardrooms. As I have come to realize, nothing worthwhile is ever achieved in Boardrooms. :) Go to where the user actually sits. His workplace can speak volumes.

• Be on your alert when the user starts using phrases like ‘usually…’, ‘in our company..’, ‘in general…’, ‘normally…’. Ask him specifically as to how HE does the task or better still, ask him to show it to you. There might be differences in the way he says he works and how he actually works.

• Be careful as to who is watching the user perform the task…his Manager, IT Staff… it changes the way he will interact with the system

Similarly, do not interview the User in front of his superior. It will tone down his responses regarding the difficulties he faces with your software or the workaround he uses to get his job done.

• Write down beforehand high-level ‘Bullet Points’ regarding questions you would really like answered. Otherwise, if you only ask him to run you through a task on a system, you might only end up doing Usability Bug-fixing.

User Research: Being smart, being practical

In Design School we were taught how to go about User Research in a thorough and meticulous fashion. In real life in the industry, there is seldom time for that. One usually comes up with good-enough short cuts which work.

I have done extensive User Research with SAP customers in India and have realized some marked differences in the way we used to do it in back in the Design School. The reason of this difference seems to be two-fold:

1. Shortage of time to do something elaborate
2. The difference in the domain and the user group itself (Enterprise product versus Consumer products I was used to working on before)

Some smart moves during User Research (in the Enterprise domain) are:

1. Identify appropriate customers and interviewees

Creating ‘Test Participant Profile’ not ‘Personas’

A TPP is a shorter, more focused version of a Persona, covering only:

• Role Names and Functions
• Business Tasks
• Skills
• Software Expertise

Simply because creating a whole persona is very time-consuming and factors like a user’s name, social profile etc. has little or no bearing on his work profile in a Business Software usage context. Further, it can be safely assumed that the users belong to a narrow group with a certain educational background, proficiency and skill level.

This is in contrast to gathering User data for Consumer software (like mail, ticket booking software etc) where a broader range of information consisting of a user’s social profile, interests etc. is required, simply because the user group is so large and varied and a user’s overall profile does affect his usage of such software

2. Having diversity in your ‘Interviewee group’

Suppose we interview users in 2 companies:

Company A: 10 to 50 employees
User roles not so defined; 1 user managing multiple roles
Not very refined processes, crude workarounds to problems

Company B: 500 to 2000 employees
Very streamlined user roles; 1 user managing only 1 role
Very refined processes, sophisticated workarounds (in house developed tools)

Therefore, not surprisingly, the data collected from the 2 sets of users is very varied and the user requirements widely different.

In such a case, during synthesis of this research, the data from these 2 companies should not be combined, as it will distort the data, which will not hold true for any scenario.

In this case, providing Customization at the user’s end is the optimum solution

Nitty gritties of Dashboard Design..

A Key Performance Indicator (KPI) on a Dashboard is typically a metric which monitors a certain aspect of you System Landscape. In its basic state, a KPI shows 3 kinds of information:

The metric it is monitoring

1. The value of the metric at that given time
2. The status of the metric (in comparison to the thresholds set)

Apart from this, there are other kinds of information required to make a KPI more effective:

• The Threshold values
• The age of the KPI value (i.e, how old is the data)

Primarily there are two kinds of KPIs on a Dashboard:

1. KPIs which show Availability information
2. KPIs which show Performance information

Availability KPIs

Availability KPIs typically show whether a system/service/software component is up, down or in warning state.

Since they don’t have any value attached to them, they are the simplest KPIs to represent.

They are most commonly represented with Red and Green Traffic lights; although my opinion is to just show Red lights when appropriate; since that is what the Admin is interested in anyways…and also it avoids unnecessary clutter on the UI

Performance KPIs

A Performance KPI can show either a percentage value, or an exact value. Sometimes (but not always) it is a good idea to represent the percentage values using Progress Indicators. The idea is to draw attention only to the most crucial KPIs, so use special controls like progress indicators or pie charts only for certain key KPIs and not all of them to avoid visual noise and distraction.

But the problem with progress indicators existing today is that they are difficult to read and do not capture Threshold information at all. I have redesigned the Progress Indicators and adapted the Pie chart so that it can be used conveniently in a Dashboard context.

Dashboard Design: Too much in too little?

I have been working in the Administration and Monitoring domain for a while, and have been dealing with the problem of representing the enormous data which needs to be displayed on a Dashboard in an effective manner.

The purpose of a Dashboard is three fold:

1. Give a complete overview of overall health of your landscape

2. Highlight the critical information such as exceptions and error

3. Provide the possibility of a further drilldown to investigate and identify the root cause of the errors

Based on my experience, I have come up with certain Rule of Thumbs while designing a Dashboard. From a UI perspective, the problem needs to be tackled at multiple levels:

1.What information needs to be shown?

2. How it needs to be shown?

3. What would be the interactions?

Lets see each of the problems one by one:

1. What needs to be shown?

The most efficient way to determine this really is to do a lot of User Research to find out what information in general and KPIs (Key Performance Indicators) in particular do the Administrators want to see. From my experience, this usually varies to a great extent with only about 60-65% of commonality in the responses as to what the users would like to see on a Dashboard.. The easiest way out of this problem is to give a default set of KPIs but simultaneously provide the flexibility of Customization at the users’ end.

Next, out of this entire information that needs to be shown, segregate the information on the basis of criticality so that you know what needs to be highlighted.

In cases where the amount of information that needs to be shown on a Dashboard exceeds the available screen real estate, employ the technique of Progressive Disclosure. Show only what needs attention, what went wrong or what is most crucial upfront. Everything which is fine can be hidden until it goes wrong :)

2. How it needs to be shown?

This can be further broken down into 2 layers:

1. How does each KPI needs to be displayed
2. How does the overall information needs to be layout on the limited screen real estate

i). KPIs themselves can be classified into:

a) Availability KPIs

b) Performance KPIs

These need to be represented differently. I have explored a few possibilities for effective KPI representation, which I will discuss in another post.

ii).Further, there needs to be separate areas for different kinds of information. Utilizing the rule of eye movement across the screen, the most crucial information (i.e. errors and alerts) needs to be shown at the top of the screen

Also, different kinds of information can be grouped and represented in different iViews.

3. What kind of interactions?

The whole idea of a Dashboard is to give a complete overview of the landscape in one go, without the user having to do any clicks. So at the first level, there should be the need of as minimum interaction as possible.

At the same time, there should exist possibility to drill down to a second level to the relevant reports, monitors or systems for further investigation in case of errors or problems in the ladscape.

“Intuitiveness” in the context of Enterprise Software

As a designer, the ultimate aim of my job is to make the Product I am involved with easy or intuitive to use. How do you judge the ease of use or intuitiveness of your software? For common consumer product like Mail or Ticket Booking software, we are often given the age old wisdom of “If my mother can use it conveniently, it is intuitive”

But how do you define “Easy” or “Intuitive” in Enterprise Software or Administration and Monitoring Tools? It is senseless to assume that a user can use complex software without any training or help whatsoever.

The ‘Ease’ or ‘Intuitiveness’ needs to be measurable. Anything which cannot be measured, cannot be compared. And so, a difference between the ‘Intuitiveness’ of 2 softwares, cannot be defined. (This is precisely what is the aim of Benchmark Usability Testing)

Also, the perception of ‘Simplicity’ itself varies from context to context.

The average user of Enterprise Software expects a certain learning curve or training for the software, and this expectation is factored in while defining simplicity for such a software.

Whereas, even a very small Learning Curve might prove fatal for a Consumer software like Mail, typically because a user’s motivation for learning such a software is much lesser than software necessary to do their jobs in their workplace.

Below are a few parameters which can be measured to judge the ‘intuitiveness’ in the context of any complex software:

• Measure the steepness of the Learning curve in terms of the no. of man hours of training required
• No. of trained FTEs required to do the job, for a particular volume of work (no. of Systems monitored, no. of Alerts resolved, no. of Purchase Orders processed?)
• Measuring Task Completion rates, Task completion times
• How conveniently it allows the user to do the task vs how a user would have accomplished the task in the absence of the software; How much does it reduce the dependency of the user on ‘Workarounds’: (No. of manhours saved?)