UX: The Time Between Empathy and Visual Design

I've been asked to discuss some of the UX activities that I'm using with my team. Here I will share some details about how we approach UX projects.
Designing with Empathy: 
Our design process starts with empathy. This empathy is not only with users, but also with our team members and all stakeholders involved in a project. At the end of each project we are always hoping to see all of us, as a team, sharing the same concerns and working toward solving the same problem.

In discovery phases, we always try to determine what the personas involved in that project are and try to consolidate as much user research info that we already have, and come up with themes of problems. Yes, we all love to work in agile environment and we should accept that there is not much time to go through all the design research processes that we all believe as user researchers. However, we would try to use the existing knowledge that we and our peers have about our users, such as existing user feedback, customer service phone call transcripts, user researches that are done from older projects, and so much other usable information that could be found in all departments of our company. Then we will go through all of that data and share that with our teammates to find potential pain points about the personas involved in a project.

Empathy Mapping: 
Well, now it’s time to have our empathy map session. In these sessions I usually invite the scrum team members involved in a project and also the stakeholders of that project, if there are any, to empathize with the persona targeted for the scenario that refers to the project or a big problem statement. Then we try to see what those personas Do, Think, and Feel, while being in that scenario and dealing with the problem statement that we already discovered.
Having a general journey map in every team is a must have, but based on the project we would specialize the journey maps to focus on a specific scenario. Being aware of user feelings, actions, and thoughts helps us to have a better understanding of the possible problems when walking through the journey map as a team. Now there is no personal opinion involved, all that matters is our goal to solve a problem based on what we empathized in our empathy map sessions.

Identification of Problems: 
After coming up with pain points in the empathy maps it’s time to have them defined as problem statements to start ideation for a possible solution. Once we have the statement, I would encourage my teams to say what we do well and what we do wrong to deal with that issue within the current system (if it's a redesign project). We all still refer to feelings, thoughts, and actions that users take. Then we get together as team, if it’s a big group, to come up with very quick sketches about our possible solutions, targeting personas, and pain points listed from our discovery and empathy process. We believe everyone can sketch, sketching on a piece of paper doesn't need special talents. All of us can draw a simple rectangle and few lines to describe our overall idea.
At the end of each design session, we all critique each others ideas, and come up with a final sketch together. Usually using the magnetic wireframe tool (watch video) that came up from my master thesis few years ago in Arizona State University. This allows all the team members to start their work right after our design sessions and it's the designers job to just clean up those designs and come up with clickable prototypes to run some potential test sessions.

Designers take over:
Now it’s our turn, as designers, to go and design digitized wireframes (usually in balsamiq) and create a quick prototype (usually with InvisionApp) of what the solution looks like. We send these prototypes to some of our users, stakeholders, and also our scrum team members (they validate if the idea is doable) to get feedback, iterate, and fine tune the finalized ideas.
Well, now it's time visual designers to help their teams to make the wireframes be colorful, user friendly, and branded based on what the UI guideline says; having a UI guideline is super important, it allows our developers to start earlier and have a base for what they are going to code for. We also have close collaboration to define animations, if required, and polish a usable design. Then we will create another prototype and it’s ready to be tested if needed (based on the time and budget). Actually in some of our projects that prototype can be the MVP of our idea and we can collect users' and the community's feedback based on those simple clickable prototypes.
Once the project is launched we will keep track of all of them and make sure all the feedback from different channels is being collected correctly.  As well as, having follow up actions and research items listed, if required, to make sure the project is causing an improved experience for the users.

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.