You have a minute to share your ideas with senior management in an elevator. You are prepared to discuss the technology, the user experience (UX), or the business case, but you only have time for one, which one do you choose? Don’t think, decide now, what is your answer?
I have asked this question to many people in different positions, both executive and non-executive positions, at large as well as small companies. The immediate answer in less UX mature companies is of course the business case. But more and more I now find that people answer the user experience, with the argument that you can never grasp the business case without an understanding of the user experience.
When senior executives set key performance indicators (KPIs) based on delivering a great user experience—it is as beautiful as the most pristine sunrise! And yes, it has happened, but in many large corporations you need to use some motivating tactics to bring UX into the forefront and make UX a design priority; however, there are some dangerous obstacles along the way.
In this essay I will share some of my experiences based on my work with advising large corporations in the ways to progress a company along the UX-maturity spectrum. Throughout this essay, I share some of the key ingredients necessary to move your clients up the UX-maturity ladder faster.
Real User Observations
Many UX professionals have stated the importance of senior stakeholders observing actual users. As a senior executive myself, I can’t overstate the importance of seeing users interact with a product in real-time. If this is not possible, user observations should be made accessible to senior executives through recording video, making managers participate as observers, and providing data that shows the strengths and weaknesses of a product from a user’s perspective —both your own product as well as observing users using your competitor’s products. And if you do not have this expertise in house, you must find a budget to sponsor external support to gather user observations on your products. Select products where you can make an impact and tie the UX data to a business value. After a while, you will get comfortable in not allowing any project implementations to kickoff unless you have real user observations on a mockup or low-cost prototype. This is a necessary step in moving up the UX-maturity ladder.
My Story: The management team of a TV service that provides access to programming for multiple devices based their project design decisions almost exclusively on technical roadmaps (technical roadmaps link long-term and short-term product goals to the technology used to reach the goals). User experience was treated as a user interface and was normally addressed towards the end of a project. When faced with an opportunity to do real user observations on an early prototype, the team said they did not have the time because “the service will go commercial in a few months, maybe next project.”
This kind of argument is of course very normal in non-UX oriented organizations; however, as a UX professional, I knew it was vital to push the team to gather user observations on their service. Fortunately, another division of the company partly funded the UX observations for the team, which removed one of the main obstacles. It was not until the management team observed sessions of participants failing to understand how to use their service that the team began to understand and appreciate the value of UX observations. And then design changes started to happen fast, along with the shift in attitude.
Watch out: Just remember to make sure you don’t make the product owners look bad. Focus on looking for ways to improve the user experience without blaming anyone or anything.
Engage Your Client
No matter how good your UX product design, it can be destroyed instantly by a request for quotation (RFQ) written by your client if your client is not UX oriented. If your client is not UX focused and your proposals are handled by non-UX trained technical teams, you have a long, uphill situation that will most likely end in failure if you do not engage your client. For example instead of being asked to deliver a particular experience, you can be asked to deliver a specific feature, clearly not the same thing.
It is critical to spend the time with your clients to understand their UX-maturity level and capabilities. If you cannot get a particular client on board, try finding another client that can provide a testimonial about the virtues of observing people using their product or service to sway that current client’s attitude toward the importance of users’ experience. Another point of caution, if you spend too much time and effort on “non-UX” focused clients, your products and organization may ultimately suffer compared to your competition who may spend their energy less on educating a client and more on completing the work for clients who appreciate the user experience.
My Story: A large telecom operator was about to launch a new technical platform that cut their operating costs and provided possibilities for new types of applications. One example of such a new application was a push-to-talk service; basically, push the button on your mobile and talk simultaneously to all the people in your predefined group. Another service was to share documents, files, and videos while you were talking over the phone.
Two weeks before commercial launch on all media (TV, billboards, magazines), I got a call one night from one person within the suppliers’ organization with the comment: “I have an uneasy feeling about the launch.” I told him to try the services and then call back. He called back 24 hours later and gave the following description: “Well, the speech quality is quite OK on the push-to-talk service. To get it to work, I downloaded and installed an application to the mobile phone, and then I was able to talk to other people who have the same application installed. If I then want to share files while I talk to someone, I not only had to shut down the push-to-talk application, I had to de-install it. Then I had to download and install the share files application to be able to share files with other people who also have that application installed. If I then want to use push-to-talk again, I have to de-install the share files app and then install the push-to-talk app. . . .” Obviously this would have been brand destruction for the telecom operator if the services had launched. The CMO of the operator was grateful that it was discovered; it was his responsibility to cater for the front-end experience towards consumers. The supplier, however, had sold all the software and did all of the system integration.
Why did neither party discover this earlier? In a review afterwards it was, of course, discovered that nowhere in either company’s processes was there any mention of evaluating the user experience. I subsequently helped the supplier to update ways of working to incorporate upfront decisions based on evaluations of the user experience into their service design early in the process, which was maintained throughout development and life-cycle management. And the updated ways of working were then also utilized by the operator.
Watch out: If you intend to make an impact with your client’s products and services, you need to engage with their roadmaps—making sure that the relevant people of your organization are onboard and aware of this dialogue. Strategy teams, key account teams, and portfolio management teams are not always aligned, and you don’t want UX to be yet one more political factor.
Product Management and UX Management
We have Product Managers and Product “Mismanagers.” A product manager realizes what he or she is good at and embraces the expertise of a UX manager. Product mismanagers tend to not see the value of knowing how a user will interact with their product or service. They may only look at products strictly through the narrow lens of available technology or business objectives and miss the point that people need to efficiently and effectively use (and like) the service or product. On the other hand, a UX manager understands the needs of users; they can serve as a bridge between the product, or product managers, and the users.
My Story: Engineers at a large communications company proposed a new, adaptive streaming solution for mobile video. The engineers proposed to add more video encoders compared to the traditional solution of just one encoder. Early user observations indicated that the solution would be a success because the number of frames per second and the quality of each frame was adapted to the available mobile bandwidth (bits/second), and the sound was never interrupted. However, the product manager decided that this functionality was completely unnecessary because there were now 3G mobile networks live “and the bandwidth will always be good.”
One of the engineers arranged for a live demo for the unit manager (who was the previously mentioned product manager’s manager). They drove around downtown with two mobiles, one normal and one with adaptive streaming. The results were impressive. The unit manager told the product manager to go ahead with the new solution.
The product was developed, sales were good, and this could have been the happy end to a good UX story. However, when consumers started to use the product, it did not work as well as the sales demonstrations. Several markets complained that there was little improvement with the new solution. When troubleshooting started, engineers discovered that the system integration engineers who installed the equipment did not understand why an additional 3 to 5 video encoders would be necessary; it worked perfectly fine in the acceptance testing with just one. So the engineers issued an internal correction to the installation guidelines stating that this correction saved both time and cost for the installation. Clearly it destroyed the whole benefit.
The routines and training of system integration engineers were later updated in multiple ways. This story shows that product managers must not only understand the value of a good user experience but also appreciate the risk of degrading the user experience at the expense of cost savings.
Watch out: It can be easy to be lured into making decisions on limited data if you have a product manager who does not fully understand the trade-offs between the user experience and development and/or implementation costs. Also, you need to make sure product managers feel comfortable communicating to the organization both what they don’t know and any potential risks to the user experience.
Reward Failures (Anti-Fear Factor)
If you get an idea presented to you in such a convincing way that you decide to fund a pre-study and you are convinced that this is a good idea, be aware. Keep an open, objective perspective. Don’t get too close to the product. When the results from user observations clearly show the idea will not work—how do you feel? Are you secretly thinking or even mentioning that the product manager should prepare a curriculum vitae? After all, a considerable amount of money might have been spent, and the idea must be good if only done right. Or, do you reward and thank the person for finding out early that this particular idea will not work, but the insights from user observations might lead you somewhere else?
It is vital to reward the courage to communicate a “failure” early rather than to spend millions to find out the same thing at product launch. Most of us can give multiple examples of failures at launch that could easily have been discovered in the very early exploration and concept phases of an idea.
My Story: During an innovation contest, one of the contestants proposed a new type of mobile social media service. The idea got the attention of upper management, and funding was provided for developing a first prototype. During the development process the company’s central UX team performed expert evaluations that indicated the value of the service was difficult to understand. Despite the evaluations, the prototype development continued, and a product manager was assigned. The issues raised by the central UX team were not adequately addressed before a live demo version of the service was available.
Also at this time, the overall manager and VP of the organization showed the application and spoke very favorably about it in an all employee meeting with over 1,000 people attending. This would have been fine if it wasn’t for the fact that the manager had a reputation of becoming angry if you brought him any bad news. And neither the product manager nor his managers wanted to raise the issue of the perceived value. From now on no one questioned the value of the service, and it was developed, sold, and rolled out in over 30 markets around the world. It was, however, far from a success, with hardly any active users.
Three iterations were attempted before the product manager asked a UX manager to take the lead and propose improvements. It was discovered that the real value of the service was hidden and that the initialization process actually made the benefits very difficult to discover for consumers. It could, however, be fixed.
Half way through the corrections process upper management decided that the company’s portfolio needed to be reduced, and the social media service was discontinued and pulled from the market. A few local markets decided on their own to continue funding for the proposed improvements and launched an updated version. Success, and even viral growth of active users, was the result.
If it had not been for the fear factor and perceived temperament of the overall manager (in reality he was receptive and not at all as angry as he was perceived), the corrections might have reached the market over a year earlier, and the service could even have worked from the start. After this learning experience, the organization now rewards people for early detection of user experience issues and perceived value problems.
Watch out: Do not confuse statements from the organization that the product will not work because of technical, legal, political reasons, with actual UX data. Focus on the user experience, keeping in mind other factors that may contribute or hinder overall product success. Sometimes the devil is in the details, and it only takes a small correction to make the idea a success.
UX Roadmaps
We, UX professionals, are very comfortable with technical roadmaps. If you are an engineer there are very few problems you cannot solve with a technical roadmap. When we start looking into user experience roadmaps good things happen with the products and with all levels in the organization, as well. How will your service look one year from now, two years, five years? It is of course extremely difficult if not impossible to predict five years ahead with today’s digital speed of technological evolution, but you can come to some very interesting insights about your own position in the future and how to possibly influence or adapt the environment in your favor. To make it easier to predict longer periods in the future, it can be helpful to mentally live two to three years ahead in the future for a few weeks, with the experience of your service and then try another two- to three-year leap. For example, create a mockup of how the service might look in two years, and pretend to start using it in your daily life. After some time, you might discover insights that you can use to create even further product or service improvements. I have always found this technique to be very rewarding.
I have experienced the cohesion and understanding of user experience goals and standards when executive management teams use UX roadmaps, which is a nice bonus effect. The roadmap helps stakeholders realize and appreciate the real value of current and future product portfolios from a user’s perspective. Board members, in many cases and if given the opportunity, can be excellent sources of cross-industry insights that can add to the UX roadmap.
My Story: Two different and non-competing telecom operators I was helping out in two separate countries were analyzing and evaluating the value of 4G licensees and what their bid limit should be in the upcoming national auctions. One of the operator’s management team spent several sessions together trying to come up with a value based on the technical roadmaps available, which focused mainly on speed, quality, and network coverage. It was difficult to come to an agreement on a value mainly because the value of possible additional sales was difficult to estimate. A decision was made to go into the auctions and see what the competition was doing. The team and the company owners decided to secure a 4G license no matter what the costs would be.
The other operator approached it from an experience angle. The chief technical officer had an overall technical roadmap, and the different business units (BU) had responsibility for the relevant parts of that technical roadmap, but in addition, each BU had UX roadmaps. To estimate the value of the 4G license, each head of a BU got the task from the chief executive officer to update the UX roadmaps based on the assumption that 4G would be available. Each BU described which new experiences (services) could be launched and how the existing experiences would be improved. These updated UX roadmaps were converted to an approximate business value.
In a two-hour session, the management team met and results were presented and summarized. Because of the updated UX roadmaps, it was very evident to everyone on the team what the real value was for each BU and how their services on the market would be improved. A maximum limit was set for the auctions, and the meeting was concluded.
Both operators got their license. However, the second operator had more valuable insights into the real value of the 4G license because their roadmaps cast some plausible predictions that put their company in a better position to rapidly turn the improved technology into a real business value in multiple domains.
Watch out: It is easy to look to technology as a strong input to UX roadmaps, particularly your own technology. However, it is best to start with overall UX best practices and then look at ways to incorporate the most relevant technology into the roadmap. This step reduces the risk of “silo thinking.” Or, to put it another way, incorporating multiple business perspectives, both UX and technical, makes for a more effective and realistic roadmap.
Some Reflections on UX Change Management
When someone asks what is the single most important thing to do to move an organization up the UX ladder, I always highlight the tremendous value of real-time user observations. There are of course many other important activities and attitudes that are required to move an organization to a user-experience mindset that drives true customer satisfaction. However, I believe the examples mentioned in this article are absolutely key for fast-track changes to a company’s attitude towards the user experience perspective.
When company executives (preferably multiple executives) and management seek to understand the people who use and enjoy their products and services through UX management practices, the overall reflection is that it really creates positive energy in all parts of the organization. This commitment to the user experience can be stimulating for everyone involved. Understanding the real user value in the products and services delivered is to understand the goals of a company, because without the customer, or user, the products and services are nothing.
In Conclusion
Business and technology moves at warp speed. The digital world is scary to some. Working in a user experience mode of operation replaces fear and anxiety with fun. And once you have started, you cannot wait until the next batch of user data comes in from the different life stages of your product
and your competitor’s products. Oh, I almost forgot, on the business case side, I have yet to discover a project or organization that did not save at least 30% on time to market or 30% on cost of development when converting to a UX mode of operation. Maybe this is what I would mention in the elevator… or maybe not. But it is a nice bonus!
