Defining the Users of Your UI/UX Project



Who exactly is going to be using your product? If you ask that question in a room full of your peers, you will often get a slew of unique answers. Most of which will have some variation of "it's for everyone." I'm sorry to say that "everyone" is the wrong answer.


This can be one of those contentious points amongst more stubborn colleagues and clients - often with the staple argument being, "We don't want to ostracize a portion of the market. The more people we can get to use our product, the better." It's a valid point but here's the problem. It's not possible to target everyone as your user base. The reason why is very simple, you can't satisfy everyone and you'll drive yourself insane if you try to. And also if you go down the path of trying to satisfy everyone with one product, you can almost guarantee you'll end up satisfying no one.


Your app shouldn't be for everyone, it should be for anyone.

Trying to target and satisfy everyone with one application isn't possible. To any spiteful people out there, don't take that as a challenge - it really isn't possible so don't burn yourself out trying. However, that doesn't mean that "everyone" can't use it. While you're not targeting everyone, you should still build your app so that anyone can come in and use it.


There are certain scenarios where you may have to forgo making your application for "anyone" due to the content that needs to be displayed inside your application or the subject matter it pertains to. For example, if you’re creating an application to be used by Healthcare Professionals, then there is probably going to be a fair amount of medical jargon that needs to be used in the content of that application. By all means you should use the necessary content wherever it needs to go but there will also be instances in your applications where you can simplify the language and actions regardless of the intended audience. Anything that doesn't absolutely have to be user or industry specific should be designed as if anyone may access your app. By doing this you’re making sure that you aren’t making the application that you’re developing any more difficult to operate or understand than it needs to be.


Because there can be a lot of variables when it comes to the “ideal” or “target” user for the application that you’re developing, it’s important that you and your client spend time defining who your ideal user(s) is. There may be only one type of user that encapsulates your entire target audience which makes things nice and easy. More often than not, however, there are going to be multiple. Regardless of how many user types you may have, the best way to define these users is by creating user personas.


Most people are aware of what user personas are in this day-and-age but the understanding of what is needed in a user persona is usually pretty gray. Some people keep user personas pretty light while others write entire backstories for each one of them. The truth is, there isn't a "right" way to create a user persona. But I would say that there is a minimum for the information that is needed in each of their profiles.


Name/Title

This is just more of a formality but it’s always good to label your user profiles just so you can reference them easier in documentation and conversation. Saying that you’re talking about “Jane” or “The Doctor” is easier than saying that you're referencing “the user that works as a Sales Rep who is using the application to document their expenses.”


What problem are you solving for this user?

This one’s pretty self explanatory. What problem(s) does your user have that you’re aiming to fix with your application? What actions or processes led your user to come face-to-face with that problem?


What types of software or applications are they used to?

Having a list of applications and software that your target users are used to using is very handy when it comes to referencing paradigms for certain actions. Things like if they are an Android or iOS user, if they mainly use the computer over smart devices, or if there are any industry specific applications that they are familiar with. This can also be a place to list competitor apps or software that your target users currently use in order to attempt to alleviate the problem, with no avail, that you’re trying to solve.


Everything in UI/UX development is meta - it builds off of and references itself and its predecessors. This is why when you install a new app on your phone, you already know a good portion of how to navigate and control it. By knowing what your users are used to interacting with when it comes to UI and UX, you can lift functionality and paradigms that your users are already familiar with. This, in turn, will make your app or software that much easier for them to pick up and use effectively.


What does the outcome of the right solution look like to this user?

So, you know what problem you’re aiming to solve for your user(s) but what does that solution equate to for that user? Is it reducing stress? More time to work on other things? Simplifying a process? What does your user hope to gain out of the use of your application? This information will be helpful for gut checking yourself and your team as you build your solution.


Are there any special circumstances that need to be considered?

You wouldn’t want to design a red and green application for a user who’s red-green colorblind. I hope that’s not the only thing that’s stopping you from doing that but, hey, you’re your own person. There are many things that can impact a user’s ability to use your application - Eyesight, age, color blindness, disabilities, the list goes on and on. If a majority of your target audience meets any special circumstance that needs to be considered while designing, then you need to list it here. The last thing you want to do is ostracize your users because you forgot that a majority of them can’t read a font smaller than 20pt.


Like I said earlier, you may only have one user type or you may have multiple. If you find that you are going to be catering to more than one user type then it’s important for you to look at your defined profiles and figure out which one is primary, secondary, tertiary, etc. There can only be one primary user type. When you have multiple target users, there will be instances in the design process where you’re going to have to make decisions and trade offs for features and functionality. By deciding who your primary target users are going to be, you are drawing a line in the sand that will help you make these trade offs easier because you know that the right decision is the one that suits your primary users.


There may be more to your user personas based on what you, your team and your client define as important information about each user but there shouldn't be less. These few criteria listed above will give you the basis of who your user is and will help you stay on track design-wise and decision-wise.


Remember, by refining your target user through user personas, you're not excluding people, you're just not focusing on them. What you're doing is refining your offering so that, when the right user engages with your product they get exactly what they need.