Correlation of Psychology with Software Engineering (UI/UX)— Personas

As Software Engineers, we often build digital solutions for our end-users. In the last 5 years, I have created 3 production-level web applications.
- NimbleBuy: A portal for users to buy groceries.

- Diaspora: A portal for immigrants to get acclimated to a new place they move to. (mobile app)

- Banter: A portal for students to connect, converse, exchange ideas, trade books, and other items.

It can easily be inferred that the target users for each of those 3 applications are entirely different. Our job isn’t just to churn out code for the bottom line. In my opinion, building digital solutions go beyond the realm of computer science and into the realm of psychology.
When I work on any project that involves some type of UI that a user sees, I spend a big chunk of time doing the following -
- Picking a color palette (Good Color Theory)
- Picking a UI design pattern/philosophy (To Minimize Cognitive Load)
- Prototyping the user interface (Visual Harmony)
- Getting feedback (To increase empathy)
Some if not all of these activities that I do have strong ties with some concepts in psychology. Mind you, I have had no formal education in the subject until now. But my first week in a graduate seminar on Internet Psychology at UT- Arlington has positively reinforced these activities that I do.
These activities mostly revolve around catering your product to different users or as we’d like to call it: User Personas.
In psychology, a persona is defined as the aspect of a person’s character that is presented to or perceived by others.
In SE/UX, a persona is an archetypical user(s) whose objectives and attributes represent the demands or needs of a wider set of users.
In essence, both fields talk about attributes and characteristics but SE/UX groups certain combinations of these attributes and gives them a tag, and then aims to build solutions that would appeal/be useful to users belonging to all these tags.
Ex: You build a home page and put a blue button in the middle. You sit and stare at your design for 5 hours and pat yourself on the back for the amazing job that you did. You then show this page to a bunch of your peers/potential users and they make a face and ask you — “Why is the button blue?😒”. “Why is it in the center like that? 🤔 It doesn’t look good 🥸”.
This is what is referred to as Self Referential Design which should be avoided at all costs. Building something that we think looks amazing but in reality, our users don’t find it appealing or useful.
In this case, we failed to account for the different kinds of users that would use our app. It is impossible to add a different color to the same button for the different users based on their tastes.
However, this problem can be addressed as follows:
- Brainstorm the different types of users that might use your product. Some attributes that you can consider are — age, gender, and profession. Show your design to about 50 people and get their first impression. Then take in their attributes.
- Find the common attributes of persons who gave positive impressions of your design. These attributes will form your Elastic Persona or Primary Persona.
- Build your design around this Primary Persona.
The example just showed a button color problem. But the same holds true for any design problem. Ex — Writing a post, uploading a picture, placement of UI elements, and could even be about the content in your app.
Advantages of working with personas:
- Building empathy: This helps you gain different perspectives and helps answer “Who am I building this for?”
- Prevents self-referential design
If you scroll back up to the top and see my apps again, you will realize that I have taken my own advice and built my solutions for different types of users as they would like to see them.
At the end of the day, we should put ourselves in our user's shoes and build what they would like to see/use, not what we would like to see/use even if it goes against our ideologies and perspectives on technology.
Comments
Post a Comment