This is what I tell my clients, and this is how I do it by focusing on users, not clients.

I will start by asking you why you think you need to provide this service; what are you doing and why? I conduct interviews in order to define the purpose and goals of a digital service for you. Which business problems will this service solve for you?

You cannot build a useful service without challenging the way you’ve conducted business so far.

I ask a lot of questions about your business, your business model, your products and the service you provide.

I ask these questions to help you focus. It can’t all be about end users. If every website and every app all revolved around what users want, most of them would just be pushing cat videos. The problems we solve for your users needs to align with your core business.

I ask these questions to help you understand what you need to consider and allow for in every aspect of user contact; in your support hotline, in your delivery insets, in your communication and behavior. The kind of projects I am involved with often tend to expand into business development when these things are scrutinized.

I ask these questions to help you identify weaknesses in your core offer, and to identify the demand to manage expectations for your users, as well as stakeholders.

I ask these questions, but I don’t really care about you. I care about users.  The needs of the users matter even more than your needs as an organisation. Lets talk about them.

Give me your users, not your idea of your users.

Who is using this service?  Which business problems will this service solve for them?

You can tell me who your users are and what you hope to do for them, but that’s about all you can do. I don’t want you to tell me what you guess about your users, and unless you’ve already done my job, you are guessing.

Ignorance is better than arrogance.

Forget what you think you know, everything needs to be validated against reality.

User research is about curiosity, skepticism, empathy and a great deal of interview technique. To ask the right questions and never ever ask what the users want.  Henry Ford once said:

“If I had asked people what they wanted, they would have said faster horses.”

Spoiler: Henry Ford never said this, but it makes for a relevant quote.

Image by Scott Adams, Dilbert.com

We can get to know our users in a number of ways:

• Bad – Being told about users from a business owner.

  Please don’t do this. You may have done your market research but you’ve probably focused how to get your users to do what you want, how to achieve your goals.

• Still bad – Being told about users from a role that actually deals with users.

  Better, if the role talks and interacts with actual users, but still bad.

• Better – Being told about users from a user.

  We’re talking to actual users, can’t get better than this right? Wrong. Users are not service designers and it would be bad to assume that they understand and can breakdown their own problems. We certainly can’t expect them to be able to design the best solutions to their problems.

• Jackpot – Observing users in their natural habitat.

  Now we’re talking context. The full who, where, why, when. We can fully understand the scenarios in which the problem needs to be solved. How the information we provide will be used. Why the problem needs solving. What their conditions and possibilities are.

  There is till a bit of talking involved. We need to really get to know our users. To understand their needs, their behavior, their capabilities, their mood, their pain points inside and outside our service. And we shouldn’t downplay the importance of old school ergonomics. No one cares about your fancy dark-themed design if they can’t see it because they use your service outdoors in direct sunlight.

The result of this research is often a deliverable in my projects. A documentation with user scenarios and personas which needs to be approved by the client before moving on to actually solve the problems outlined.

Do less, better.

Your users will have many needs, probably too many. The same goes for the organisational businees problems.

Let’s talk focus. The best service imaginable is the service which solves one problem (and does not create new problems).

When people ask me for examples of good design my first answer is open_in_newvecka.nu. It solves exactly one problem, it tells me the current week number. It could do more, it could tell me the date or day of week, it could allow me to authenticate and show the information in my custom colors, it could provide links to other resources. This would make it worse.

It is very likely that there are users who would like that, and why wouldn’t we want to satisfy their needs? The service would still satisfy my needs and more, right?

We don’t want to satisfy everyone’s needs because satisfaction is not enough. We want to delight!

Image by Scott Adams, Dilbert.com

A service which tries to please and satisfy everyone is a mediocre service. We need to choose. We need focus. Who is our primary user? What is their primary scenario? We need to choose who we want to delight, at the expense of other users. We can probably still satisfy others but we need to understand that all users cannot be equally prioritized; in art direction, in information hierarchy, in copy tone, in interaction and information design. Some users information will be less accessible, their interactions will be designed to fit someone else better than them.

This is the price of delightful design for the right user.

Solve for X.

Design in the purest sense is about solving problems, and if you are with me so far we should know exactly which problems to solve, and for whom, and in which context. This is the how. How can we best solve our users’ problems based on what we think we know about them? The process is iterative and a lot of roles are involved but the concept; a basic information architecture and a user wireflows with actions and conditions should be settled before any graphic design or copywriting is begun.

Once the foundation is laid, the solution phase involves documentation, wireframes, prototypes, mood boards and art direction, design mockups, sample texts, sample photos and so on from all kinds of project roles. After that we’re off to implementation.

Projects are collaborative, and user experience design must be too. User research and user insight is little worth if it cannot be understood by everyone involved in a project; the graphic designer, the illustrators, animators, speakers, copywriters and project managers. What we think we know about our users should influence every design decision. Design patterns and praxis needs to be validated against our assumptions.

Image by Scott Adams, Dilbert.com

Test! Test! Test!

No matter what! Test everything! Test early! All the time! Test your assumptions, your copy, your interactions. Proper user testing is not unlike the user research we conducted earlier; optimally by observing users in an environment as close to the natural one as possible, asking them to think out loud, using tools to track their eyes and cursor.

Don’t lead them on and don’t help them. If your in-service onboarding process is not good enough, and your service needs introduction or education before sitting down with it, you’ve failed. Start over. Do not pass go. Do not collect $200.

Image by Scott Adams, Dilbert.com

If we don’t have a budget for user testing (which you would have if you would have involved me in the project budgeting and planning) we can still harass coworkers, family, friends and strangers with a bit of guerilla-testing. Any testing is better than no testing.

Assess, evolve, experiment, iterate.

Don’t settle for good enough. Even if we can accomplish your business goals, that’s no reason to not be better. Develop a strategy for statistics and its use by figuring out exactly which questions we want answers to and employ someone who understand statistics to form the data to answer them.

Plan and budget for A/B-testing of tweaks, and for further development following the release of your service.

Software is never finished, only abandoned.

I you don’t continuously evolve, you’re likely to become extinct. I did not mean for that phrase to come out so catchy, sorry.

What I do and what I don’t

Having worked in the industry for close to 20 years, and with experience in broad number of disciplines in software and service development, I am fairly certain about what I want to, and should, do. And it is where you will get your moneys’ worth.