Creating a strategy means UX tasks planning, identifying the risks in fulfillment of those tasks, describing the consequences of some unfortunate but expected events, proposing mitigation measures, acknowledging important stakeholders, and getting their approval for what will be the expected deliverables.

Now, let’s make it less scary with examples:

First example: I do not have access to users, or at least not to all types of users. I need to rely on what a SME, or a key-user, or somebody from upper management is telling me. And this is risky. Because of this, I insist that the project should deliver a beta version for 3 to 6 months, followed by a new design & development step. And this needs to be planned from the beginning.

Another example: starting UX tasks at the same time as the development phase, or with 2 weeks prestart. The UX research cannot be done on modules, so important design changes should be expected and should not be considered a flaw in UX activities.

The purpose of elaborating an UX strategy is to set realistic UX expectations, to get support and commitment, starting with early stages, from other stakeholders.

Also, an UX strategy does awareness of HCD methodology, which is not largely known. If the UX strategy is missing, the biggest problem is that, for any complaint, everyone will point to the UX team at least because they are the “alien” of the process.

* * *

Any product is a tool. A tool is meaningful if it is placed in a context. For me, it was better when I did UX research not only around the product but also around the processes. This helps me understand what is happening before and after the problem that needs to be solved.

With this approach, I’m also able to better understand how, when and why that application is used, which other applications are used in the same process, how the customers are reporting the success, and how this success is depending on the tools they are using, or on the working procedures they are following.

Finding how the customers report the success, leads me to the next point on my list: KPIs for enterprise UX.

* * *

a) Man Working Hours saved.
This is the best KPI for proving the value of enterprise UX. Even if it is not very accurate, it is easy to evaluate and people love to talk about it. The downside is that people also love to exaggerate about how much they allocate for an annoying task they need to carry on.
These working hours saved could refer to global activities, or to some specific tasks, or to the maintenance of something, etc.

b) Specific success KPIs “before” and “after”, like goods manufactured hourly, or customers reviewed daily, or contracts signed monthly.

c) Number of open tickets “before” and “after” for various types of issues, like support, quality, security, data accuracy, etc.

d) Cost of equivalent goods or services.
First, similar items and their prices need to be found and after that, the cost of UX services provided needs to be subtracted.

e) Perception assessment through questionnaires.
For this, is better to run a survey before any change, to have a reference value in reports. Besides, it is important to take into consideration that any perception is all the time “subjective” and, above all, it is hard to convert it in dollars as opposed to the KPIs from above.
The lowest value I got with this type of KPI was when I got overall similar scores, good but not excellent, for the old and the new application as well. The users liked the new one, but also the old one because they used it for 10 years.

* * *

The first time when I encountered this, my self-esteem was on the floor. I spent a while thinking about what should I do: accepting the compromise or resigning. Of course, I also questioned my design abilities and my communication skills.

I found that the design downgrade is acceptable when I have used the same empathetic approach not with the customers, but this time with my own project team members. In this way, I have better understood how the due dates or budget constraints are perceived by different types of people. I have seen how is it to face professional challenges, way out of someone’s comfort zone.

For instance, deal with this dilemma: the dev team does not have enough desire or even experience in order to implement what you designed. Pushing them from top to bottom creates conflicts, replacing them will exceed the budget.

What I’m doing now is to talk with them about my proposals before presenting them officially, in front of the upper management. In this way, the first thing I win is their trust. The second one is that I get the best UX value with the existing resources. And this is better for the final users as well.

Another frequent situation is when I have to do a visual uplift of some 15 years old application. For these cases, there is a lot to compromise but still, I provided something refreshing which brought joy for those who need to work 8 hours daily with it.

For me is important to set a bottom limit from the beginning. Below this limit, the compromises are not acceptable for the sake of the direct users.

As a contractor, I decided, twice already, to walk away from projects where, overall, the vision of the customer team about UX was deformed and my expertise could not add value.

* * *

Every time when a new project started, I should have begun the case study for that project as well. The purpose of this is to be able to sell the newly gained experience as soon as the project is closed. A case study shows better the value in front of upper management and customers.

I know, there are NDAs! What can be done is to change some numbers, labels, lists and maybe colors as well. Ultimately, a check with the “legal” will eliminate any doubts. After all of these, you will get a very anonymous case study but still with a lot of things to share with the rest of the world.

Recently I started to build the case studies of some of my projects completed years ago. I have problems in remembering details, and I really miss the enthusiasm and the passion which I had then and are gone now.

* * *

In complex projects, I need to interact with a lot of people, spread on different hierarchical levels, with various problems, feelings and working patterns. Despite “professional attitude”, some things will be very personal. This is why I need diplomacy. I need to adapt my voice and my attitude to specific situations in order to get a project done with the highest possible UX value.

A simplified approach, which helped me deal with this, is to distribute the people into 3 categories: “problem-solvers”, “problem-makers”, and “problem-avoiders”.

Of course, good communication skills are the ground-base of any diplomacy.

When I’m asked to do something really stupid, I try to reply with “This is unusual, but I will think about it!”, when I have to cross-check information, I do not use “John said that …”, but “My understanding is that …”. When I need to have my expertise voice heard, I’m confident and convincing, but also humble.

Years ago I haven’t thought so, but now I strongly believe that the most successful driving factor in enterprise UX is given by diplomatic skills.

* IT ENDS HERE *