User-centric approach to digital transformation

Most organizations have embarked on digital transformation to capture customer value – both internal employees and external customers. These digital transformation projects address some business objective such as improving user experience, improving collaboration, simplifying processes using digital technologies etc.

In a traditional product-centric approach, we take the product/application as a given and then re-align processes to meet the product requirements. This could prove to be effective when the goal of the project is only automation and simplification. However, the digital transformation project has additional objectives – namely improving user experience and collaboration. To this end, it requires a different mindset – It requires project leaders to think from an end-user perspective and not just from product perspective.

Developing a user-centric approach will be extremely critical if buyers are not consumers of a product/service. There can be a huge “expectation gap” between what a product/service offers and what an end-user wants. A user-centric approach is a three-step process: Understanding the customer journey, Developing a user-centric design, and Validating the design and business outcomes.

‘Understanding the customer journey’
In order to minimize the “expectation gaps”, it is imperative to understand the end-to-end customer journey. By understanding the customer journey, we can develop a user-centric application design. Developing a customer journey is not a difficult task – all we need to do is identify the key users and ascertain their activities in a day. It is also very important to identify the situational information during the customer’s journey. The situational information provides why an activity is performed at a certain Time, Place, and Context. Once we understand the customer journey, we can identify opportunities for value creation. Value creation can be in the form of simplified process, knowledge sharing, collaboration, improved user experience etc.

‘Developing the user-centric design’
When developing an application design, it is important to understand that there are two business objectives: Improving user experience (UX) and Value-creation. A good UX design is one that has a simple page layout and that requires minimal clicks to perform a task. (Tip: Think “iPhone” when designing UX). Secondly, the design should also be compliant with multiple platforms such as iPhones, tablets, and laptops. Once the governing principles for the UX design and architecture is established, then develop process flows highlighting areas of value-creation. The governing principles and value-creating process flows form the basis for a user-centric application model.

‘Validating design and business outcomes'
This step is usually ignored by most project teams primarily due to project timelines. But, ignoring this step will be a very costly mistake if the assumptions do not hold. Moreover, there is no way that project team can gain full insight into complete customer journey or develop an awesome UX design in the first iteration – unless it happens by miracle. To avoid costly mistakes, it will be worthwhile to develop some UML or prototypes. It is important to validate the UX design with users of the product – we see many a times that business leaders sign-off of on UX design based on their assumptions. This only leads to re-work and frustration. The UX design needs to be validated with actual end-users of the system. Likewise, business outcomes need to be validated by business leads and ensure that it confirms to their business strategy. This not a very difficult exercise but I have seen many organizations ignoring this activity.

By following this simple three-step process, we can mitigate many risks in a digital transformation project. It provides clarity to both business leads and developers of the system.

Comments

Post a Comment

Popular posts from this blog

No Non-Sense Transformation

‘Context’ Many years ago, when we first started setting up shared services in a major technology firm, we embarked on a journey that had many unknowns. Whether it was scope of work, projects, technology, or processes – nothing was clearly outlined. We had few excel sheets to guide us through the process of setting up shared service organization. It was no more than a simple ‘lifting’ of processes from each entity into a regional centre. The initial days were tough – It was about power, control, and other hidden aspects in organization. The lower end resources who managed the day-to-day operations struggled to meet the expectations from the internal clients. We had ‘all fingers pointing at one direction: shared services’, and always for the wrong reasons. ‘No defined parameters’ Now, when I look back to the unwieldy phase – it appears that there were number of interventions that could have been employed to mitigate the organizational resistance. In my experienc...
Read more

Patrick Pichette and Art of Corporate Finance in IT Industry

I was reading through Patrick Pichette's interview with Mckinsey Quarterly last week, and it was perhaps one of the few interview reports that made me sit back, read, read, and read through again. Its quite an old interview, but worth looking given its relevance in today's fast changing IT landscape. The report certainly made me to think about many aspects of corporate finance and strategy. Patrick's  ideas are certainly commendable and thought provoking - From managing Short Term metrics to Start-Up culture. Here are some excerpts and my thoughts... 'Managing Short Term/Tactical metrics' Managing short term metrics is part of corporate life once an organization goes public. There is a general expectation from investing community to meet/beat analyst estimates and that puts a lot of pressure on C-Level executives. Nevertheless, it is required of C-Level executives to meet short-term goals as well as long-term vision. In the report, Patrick suggests that short...
Read more

The RASSP in IT Architecture

The QUALITY Attributes are those that defines how the system should perform over a business cycle/Time Period. Fundamental to good IT design is forecasting the business peaks and troughs and how the system should behave over the business cycle. When there are peak loads, systems should automatically be able to scale and perform with consistent service level agreements. However, there are several cases in the past where such quality attributes were ignored leading to loss of revenue. Quality Attributes can be either run-time or non run-time attributes. Clearly, from a business standpoint, the run-time consideration is of prime importance as no one would want to lose business because of a system downtime or a performance lag. The blog post focuses on the run-time considerations an architect should adhere when making architecture decisions. The following attributes are considered the most important run-time attributes when designing new systems. Reliability (R), Availability (A), Sca...
Read more