UX: The Time Between Empathy and Visual Design

I’ve been asked to discuss some of the UX activities that I’m experiencing with my team and here I would share some of the details about how we approach UX projects.

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, are sharing the same concerns and working toward solving the same problem.

In discovery phases we always try to see what are the personas involved in that project and try to collect as much as 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 not much time to go through all the design research processes that we all believe as user researchers, but 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 many other usable information that could be found in all departments of our company. Then we will go through all of them and we would also share that with our teammates to find potential pain points about the personas involved in a project.

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 is 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 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 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.

After coming up with pain points in the empathy maps it’s time to have them define 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 with 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 coming up with a final sketching together, usually using the magnetic wireframe tool 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.

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, stakeholder 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 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 community’s feedback based on those simple clickable prototypes.

Once the project is launched we will keep track of all of them and we will make sure all the feedback from different channels are being collected correctly and we have follow up actions and research items listed, if required, to make sure the project is causing an improved experience for the users.