Read Blog Post

Read Blog Post

Contributed on March 30, 2021

13

321

How to design for users despite growing challenges

Blog: Capgemini CTO Blog

The perceived importance of users, as the final recipients of a solution, grows continuously – not only when it comes to developing commercial products used for private purposes but also in the work environment. All in all, being useful, effective, and increasing the productivity of performed tasks are the key elements of many solutions. However, to meet these expectations we must hear what the users expect. And this is where things usually get tough. I’ve heard these statements many times:

Users are important … but:

• We don’t have any users yet.
• We have many users. Hundreds! Thousands! Hundreds of thousand! And all of them are different.
• Our project is so specific. There is no way to gather feedback.
• We just can’t change the solution.

So, we can’t conduct any research. We can’t design for users.

Interestingly, as a psychologist in the IT world, I see that when the topic of people, peoples’ needs, or worse still, peoples’ emotions appears on the horizon, some get tight-lipped. Alternatively, suddenly available project resources get really scarce and there is not much space for user research. This might be the result of the previously mentioned attitudes, though. In the end, our finished solution is ready not for people but for the solution itself. So how to overcome those challenges and design for real, for people? Let’s find answers to the above statements:

• We don’t have any users yet.

No users? Well, we don’t build time machines (yet!) so somewhere there should be people who use similar solutions or have similar needs. We can engage an external agency to recruit user research participants based on our requirements, look for a specific community on social media, or even ask our colleagues for help. Let me give you an example of what I mean. Let’s consider an app presenting different data for further analysis. In many roles, you have to use some kind of dashboard, analyze data, download reports, etc. But, why not ask colleagues for help? Although the content will be different, the usage patterns might be similar and the feedback will be priceless. Or, conversely, the feedback can have very specific value; the value of not developing solutions with significant flaws and redoing that after all.

• We have many users. Hundreds! Thousands! Hundreds of thousands! And all of them are different.

This is a frequent notion in big organizations. Should we give up without even trying? No, it is always better to ask a few people than to not ask anyone. According to Norman Nielsen (the top UX consulting organization), five users are enough to find 85% of usability problems in design.^[1]. Of course, when we design for groups of users with significantly different needs and contexts, it gets a bit more complex and more users are needed to test – still not hundreds, but much smaller numbers. Let me better visualize this. If 5–6 users can’t find the button to submit an IT issue in a self-service IT portal or 4–5 users spend 10 minutes scheduling a meeting in an app dedicated to this, it means that we have a serious problem. What is important, it is that we don’t need to worry about statistical significance and we don’t have to ask hundreds of people to get valid feedback. Even a relatively small sample can direct our attention to aspects we overlooked because  we were familiar with the product and observed as it developed over time.

• Our project is so specific. There is no way to gather feedback.

I agree that every project is different and has other challenges regarding designing for experience. I can’t, however, agree that in some cases there is literally no way to figure out what can be improved to create a user-centric solution. I believe that there is always a way to find people who would share their feedback. Sometimes, they will even feel appreciated and listened to (at last!). It all depends on how we present the need for user feedback.

Even if we find the right people, there can be a language barrier. We used to cooperate with translators, still having interactive exercises or engaging conversation with our research participants. Or, let’s imagine the need to gather user feedback regarding a service, as opposed to the more tangible tools (e.g. web application). That’s not a problem at all. We can use storyboards, record a short movie, or describe the solution in any other ways enabling us to learn how it can be improved– but I have to admit that a bit of creativity is needed here.

• We just can’t change the solution.

In many projects, Capgemini CIS implements out of the box solutions, e.g. Microsoft M365 suite (with Teams gaining popularity during the COVID -19 pandemic) or the ServiceNow platform. In most of these cases, we can’t change the features (although in some we successfully did!). But even if a single functionality can’t be adjusted to the organization and its users, we can significantly change how the solution will be perceived by users. Our Digital Adoption Managers team is responsible for activities aimed at increasing tools adoption: communication, marketing elements, gamification campaigns. Although tools can’t be changed, we can improve users’ perception of new solutions. They do not have to perceive new systems, applications, or services as a brand-new, top managers’ whimsical idea to make their life even more difficult. If we highlight benefits, present how new tools will help them to overcome current daily struggles in a targeted and innovative communication campaign, the results will be impressive. Nonetheless, a proper understanding of different groups of users (personas) is crucial to design a proper solution, no matter if that is a tangible device or application or much less palpable communication being sent to users. To adjust these activities, of course a relevant research should be conducted.

I hope that you will find some of these ideas useful in your projects. If you have other challenges or want to learn more, contact me directly on LinkedIn.