Information Technology, User Analysis, User Experience

With great effort, you have got access to the key stakeholders of the product organisation. You also identified the specific persons, their roles and responsibilities in the organisation. What are you going to ask them? You would obviously focus on the software product’s features and functionality, because well, that is what you need to know before designing and developing any software application. How about a few questions on the Technology? Well, yes of course, because after all, you are developing the software product using a specific Technology. Let us discuss if these are good enough to get you a head start in the product development or do you need to focus on any other areas during your stakeholder interactions.

Technology or ‘Trick’nology

While nobody can deny the significant role played by Technology in our lives today, one needs to be wary in focusing only on Technology and ignoring the rest. Technology is verily what IT and Software development organisations like us thrive on and I am in no way suggesting to drift away from it. However, I support the view that Technology should be seen as an ‘enabler’ and a means but not the end. All products that have been invented or innovated so far, did not succeed merely based on the technologies used to build them. The underlying technologies in each of these products, if I may call so, helped achieve some business objectives to their users-from the Potter’s Wheel to Radio, from Mainframes to Laptops, from ERPs to Web Applications and from Java to the Multi-Touch Interface. The moment one focuses only on technology ignoring other aspects, that product is bound to fail.

Like ‘Marketing Myopia’, product companies might get into what I call ‘Technology Trap’ leading to the failure of their products. This happened with Borland when they focused on Delphi as only a technology platform and could not pursue advancements and evolve their platform like other competitors. Same was the case with Konica and Kodak were focusing on making better film roll technology, while others such as Canon, Nikon, Olympus moved on to the Digital image technology.

It takes a lot of courage for product companies to come out of this trap. We had seen a real life instance of this ‘technology trap’ in one of the projects to reengineer a university administration suite. This suite was originally developed in LISP, about 15 years back and the product owners thought it was high time they made it modern. So, we were entrusted with the responsibility of reengineering it to Microsoft.Net platform. In one of the screens of the proposed modern platform, we noticed that the development team gave a solution which used Acrobat PDF to preview the schedules and reports. Obviously, we were puzzled why this was done, because PDF is not a suitable solution to be used for WYSIWYG (What You See Is What You Get) interface. When we probed the team, we understood that they did not think of alternatives and tried to imitate the solution applicable to the previous technology. Similarly in another project involving an automated information system, when user logs in he/she had to land in a blank page with very few options. The older technology solution did not use database and used flat files instead. Due to this, they could not maintain the user details.  However, even in the newer version of the product on modern technology platform, after user logs in, personalised welcome message and user-specific tasks could not be provided by the team. But, what stopped us from including personalisation in the modern technology solution?

Prevent ‘Featuritis’

On the other hand, a few people specifically those in the product management and business analysis areas tend to focus more on the features and functionality to the software product. They focus all their energies in adding new functionality and improving existing features. If this is backed by sound logic, business vision and user research, they are surely on the right track. However, this is done more as a pressure from the competitors and to keep up in the race. Focus on features is futile, because if you have created a product with 100 features, your next competitors will create another product with 200 features the very next day. Google, known for its innovation and user-focused products had been successful all along since Google Search, Gmail, and Android O.S. But even Google could not create the right ‘Buzz’ because I think they followed the lead of Facebook, and even Yahoo on this specific offering and could not pursue their core user-focused innovation. Just a day before Google announced the launch of Google Buzz, Yahoo had already implemented similar functionality, and Facebook did it two years back.

First, get on the BUS

So, you might ask what is to be done during the stakeholder interviews. While understanding the Technology and Functionality perspectives is necessary, it is not sufficient. We also need to understand the other perspectives, what I refer to as BUS, i.e., Business, User and System. I give below an indicative list of areas that could be part of each of these perspectives.

  • Business – Organisation’s vision, Business Strategy, Target markets, competitors
  • User – Customers, consumers, primary user groups, usage behaviours, and context of usage
  • System – Product roadmap, scope of features, Technology constraints

Why do we need to do BUS Analysis

As they say, for the success of any product, we need three aspects:

  • Business viability
  • Technical feasibility
  • Continual reliability

To this list, I add two other dimensions – ‘sound usability’ and ‘optimal quality’. To get sufficient responses to the above perspective, one needs to ask relevant questions to the respective stakeholders. This would help get a handle on the objectives, expectations and grounded logic, based on which we can provide solutions  that are practical, feasible and well within the budget, time and other resources of the product owners.

What are the challenges involved in interviewing stakeholders?

Stakeholder interviewing is a scientific technique that involves expertise, experience, maturity and a bit of domain knowledge in the area of the product. It includes asking the correct questions to the correct persons (based on their role and background) to get the correct responses. Even more important than the interviews is the analysis of the data collected from the interviews. It typically takes about twice the time for analysing the interview data and creating a report. The key challenge is to define this very clearly in the plan and let the project stakeholders know about this activity, deliverables and the value created thereby.

After the stakeholder interviews and analysis, we are now poised to define the user profiles and related usage information. Let us discuss this in the next post with some examples from my real life product engineering cases. Until then, ciao!

Business Case, Information Technology, User Analysis, User Experience

We now understand that the first step in making a successful software product is to know your users. But even before that, we need to get the clearance from the stakeholders to gain access to users. They play an important role in managing the product development, budgets, customer expectations and user experience. In short, stakeholders are the gateway to users and are responsible for the software product’s life. To gain better understanding about stakeholders, we need to imbibe ‘product thinking’ and shun ‘project thinking’. While this is hard to practise, I think that this ‘product and not project’ perspective makes a great deal of difference in the context of software product or application development. By stating this, I am not undermining the importance of projects, nor do I underplay the contribution of project managers. However, for all of us who are working as Analysts, Designers, Developers and Testers, this product perspective helps get more clarity about the stakeholders, product, customers and users. We will discuss this in greater detail perhaps in a separate post later.

Who are stakeholders?

In every organisation, large or small, privately-held or listed, belonging to any industry or domain, there are certain critical areas that have specific roles. They focus on functional areas such as business, operations, customer, finance, product, technology, user etc. The following list could provide an indicative set of perspectives and the related profiles:

  • Business and Operations – Managing Director, CEO, Chairman, Owner, Partner, COO
  • Customer – Business Development Director, Sales Director, Professional Services
  • Finance – CFO, Head, Finance and Accounts, Accounts Director
  • User – Sales Manager, Consultant, Customer Service Representatives
  • Technology – CTO, Technical Architects, Developers

These are the commonly defined roles, but the titles and designations may vary from organisation to organisation, depending on the industry, nature of business and size. You might have why do we need to know about each of them and how does that help us improve the product’s users experience.

Why do we need to know the stakeholders?

Unless we know the business objectives, product vision and customer expectations, how can we ever provide ‘expert value-add’ to the product? I seriously doubt the real value of the so-called ‘value’ coming out of superficial knowledge gained from secondary providers, out-dated documents and far-from-reality portrayals from third-party sources. Besides, knowledge of the stakeholders helps us get the big picture and start with a grounded knowledge about the business and with a context.
Let me give you an example. In the late 1990s, in a car manufacturing unit of Toyota, the management had a strange problem. They found a steadily increasing defect rate in the assembly unit section, where nuts and screws are fitted to the panels. Research studies then showed that the job was monotonous and considered too menial by the workers. Then they realised that the worker out there did not know how important his job was. They had arranged for guided tours across the factory for all the workers. All the workers then realised that the nuts and screws they are fitting actually go into the most important parts of the car and that they are contributing equally well like all others in the making of a car. No wonder then that the defects went crashing and the quality improved radically. This is applicable for all of us playing different roles in the making of a software product.

Users are not stakeholders!

Though generally speaking users of your software product are in fact the most important stakeholders, we do separate them in the context of user experience as a separate segment. Because product’s success hinges on users and the software development is supposedly centered around users, I prefer to treat users specially and with utmost care and hospitality that they truly deserve. Just so that we can clearly qualify and specify users from other stakeholders, I suggest not to include users in the list of stakeholders.

What are the benefits of knowing stakeholders?

Like they say, ‘Quality starts at the top’, so does User Experience. Knowing the stakeholders and talking to them helps us build relationship, get their buy-in into the usability implementation and most importantly gain management support and commitment for championing the cause of user experience in product development.

For instance, in a recent project involving a portal development, the stakeholder buy-in helped a lot in gaining access to users and ultimately in gaining their confidence in our other offerings. The customer organisation has a current product to deliver their content to the end users. In the last few years, they realised that they had to develop a new product to deliver their content in easier, quicker and better ways. However, the stakeholders could not arrive at a conclusive approach for the new product development. This was due to the differing views and opinions amogst the stakeholders. Then, with the help of our sales person, I could meet the key stakeholders a.k.a., project sponsors and convince them of the true value of usability and how it can help them get started on the new product development. With good number of meetings and discussions with the stakeholders, we could get the go-ahead to conduct stakeholder interviews, and the end-deliverable was a report consolidating all the views from stakeholders of different perspectives.

What are the challenges involved in identifying stakeholders?

I think the biggest challenge is to believe and convince ourselves of the importance of the stakeholder knowledge and their buy-in into the product user experience process. Another bigger challenge is to identify from amongst all the stakeholders, who to select for our interactions. My suggestion to overcome this issue is to refer to the Organisation structure or hierarchy of the company and understand the power centers, decision-makers, influencers and so on. During one of the projects, I also faced another problem, of the number of stakeholders to be identified for the studies. As a rule of thumb, practically it is better to consider between three to seven persons spanning the key perspectives such as business, product, customer and technology.

Coming up next!

After the stakeholders are identified, we should start planning and conducting the stakeholder interaction process. Just wait till the next post to know more about this. Until then, ciao!

Business Case, Information Technology, User Analysis, User Experience

Whenever a new project is awarded to us, lot of people come to me and ask questions about the technology platform and name of the client organisation, in that order.  Often times, some of them also want to know the domain or functional scope. This thirst for their knowledge of technology, client or customer and functionality continues even during the project initiation and knowledge acquisition stage. Their undeterred focus on the above perspectives extends throughout the execution of the project and lasts till the end of the project too. Surprisingly, not even once do I get any questions on ‘who the users’ are for the underlying product or application. Even more surprising is the fact that the project sponsor or client team may not ask this question to themselves, leave alone answering it.

Why do we need to know the users of our products?

Let me explain with a few real-life business cases. Most often, product companies launch new products or variants of their existing products without thinking much about their users or their real needs.  This could happen in two scenarios – 1) they are looking too much internally or 2) they are under pressure from competitors. This lack of user awareness leads to the product failure at the hands of its users, for whom it was developed. A case in point is the search engine market in the late 1990s. Alta Vista created a powerful search engine but could not position it in the market as an effective search solution. MSN and Yahoo too did the same mistake of looking inward and not catering to the user needs. Then Google stepped in and understood that users really need a ‘simple’ search interface and ‘simple’ search results. Google’s simple search was a huge success because its interface was clear, simple and was extremely easy to use for expert users and new users alike. Also, the search results were shown in a simple and clutter-free way that worked for most users. Google continued to make user-based innovation as their core offering and there is no looking back since then. Similarly, Sony Walkman was born out of understanding the users’ real needs and their context of listening to music on the go. So, understanding their users help businesses define their product or service offering in a more practical manner that makes the product a huge success. For the product development teams too, this knowledge goes a long way in defining the scope of the product, designing and developing it, so that it suits the needs and thought process of users.

What are the benefits of understanding users and their needs?

Knowledge about users, their needs and the usage environment helps us in setting better business goals for our product in a more realistic manner. Also, in most of the product development scenarios, the user needs, usage and context information help defining the scope and functional requirements of a product. For instance, our initial studies of the Financial and Accounting directors of small and medium enterprises in the UK helped us better define the scope and functional requirements of a Financial Planning software application. Also, the studies we conducted on the students, professors, researchers and librarians in the US, UK and China helped one of our customers define the vision, roadmap and scope for the online content delivery platform. For the development teams in both the projects, this understanding about users created a significant base for making significant design decisions such as branding, layout, structure, navigation and interaction. No wonder, the outputs in the development processes are software applications that offered remarkable experience to the users and in effect, delight to our customers.

What are the challenges involved in gathering user information?

Having understood the importance of gathering user knowledge, let us examine the hurdles in this process. Firstly, there is a clear lack of awareness amongst the stakeholders, about the significance of knowledge of users. To me, this is the biggest challenge one should address early in the project. This can be addressed in two ways – 1) Get a Usability expert talk to the stakeholders both internal (management and development teams) and external (client and their teams) and convince them of the value of Usability implementation and 2) Assess the next steps in the roadmap for implementing usability in the specific project. This is not an easy job though and I can vouch for the number of calls, meetings and discussions that I had with the stakeholders to make them aware of the Usability value-add and its benefits.

Coming up

After this is done, we should start addressing the other ‘small and niggling’ issues such as procuring access to the users and starting some user studies. We shall discuss this in the next post. Until then, have fun!