We Wander World

Project details

Role: Designer (UI & UX) & Researcher
Tools: Figma, pen & paper
Product: CRM system

Introduction:

A travel agency that sells tailored roundtrips to destinations all over the world, is developing its own internal CRM/ERP application. A system built to support their unique way of working, help them stand out in the market, and enable their sales team to work as efficiently as possible.

The application is already in use as a CRM, and will eventually support product management, custom travel planning, automations of the customer journey, and way more.

A growing list of feedback revealed a lot of dissatisfaction and frustration. So I was asked to dive into it and (re)design the application.

Due to confidentiality reasons, I can’t share full project details. Names and visuals in this case study have been altered, and the wireframes shown are simplified.

This case study focuses on one crucial part of the CRM: the contact page. This is where users find all customer information, create and manage notes, read and send emails, and manage tasks.

I am able to show and explain more about this project during an interview.

Chapter 1: There is always more to the story

When it comes to user feedback, I believe it rarely tells the whole story. As a UX designer, I’m not just interested in what users want. I want to understand why they want it, and what they’re really trying to achieve.

So instead of just ticking off items on the feedback list, I used it as a starting point. I asked a few users if I could observe them while working and ask questions along the way. This led to the following insights:

• Creative workarounds
  Users had come up with all sorts of workarounds to make the system work for them. These hacks cost time, which they actually don’t have. They want the system to support their workflows.

• Clicking through tabs
  The contact page is divided into tabs: notes, tasks, emails, call records, etc. Users spent a lot of time clicking back and forth to find what they needed. There is an overview tab, but it doesn’t provide much of an actual overview, so it’s mostly ignored. Users want to find the information they need easily.

• Invisible labels
  Labels help users recognize customer types, so they can help them better. But in the design, these labels weren’t visible enough. Therefore they don’t get a clear image of the costumer when opening the contact.

Frustration and relief

During my observations, users shared even more pain points. Frustrations that hadn’t made it onto the feedback list, but are real and should be taken seriously. The conversations with users taught me that sharing these issues can actually be a relief for them. They like to talk about what’s not working; it gives them the feeling of being heard and understood.

Chapter 2: What users think they want vs. what they really need

“People don’t want to buy a drill. They want a hole in the wall.”
— Theodore Levitt, professor at the Harvard Business School

When it comes to good design, it’s not about what users say they want, it’s about what they really need to get their job done. In this case, users didn’t just want more room for emails or a bigger task subject field. What they really needed was clarity. A way to quickly see what’s going on with a customer and being able to easily manage their big workload.

Chapter 3: The way to the solution

Time to start ideating and coming up with solutions. I usually begin by sketching a few rough ideas in my notebook, then move on to Figma to explore further. Once I start designing, new ideas and solutions often come up along the way. Sometimes it leads to one clear direction, sometimes to multiple options. Throughout the process, I share and discuss my ideas with the product owner. Two minds generate more ideas than one, after all.

When it comes to the solution, I think it’s important to listen to users. But just as important is making sure the solution aligns with the business goals. You can’t design the perfect application for every single user and the business. However my goal is always to fit everyones needs as much as possible.

When I have a first (single or multiple) prototype ready, I share it with the users, to test en receive feedback.

The design:

The reaction of the users:

I brought five users together in a room to share and test my design. Here’s what they had to say:

• I like the timeline. This will really help me find the information I’m looking for.

• This looks promising!

• Is there a place for a general note field? Somewhere always visible where we can add the most important info about the contact? We have that in our old system and I really mis it.

• I really like the section on the left with the customer details and tasks. It gives a clear overview. The only thing I’m missing is a way to see task urgency. I’d like it to be immediately clear when a task is overdue. Maybe overdue tasks can turn red?

Based on the feedback, I made a few adjustments to the design:

• Overdue tasks are now marked in red and include a warning icon. This makes it extra clear when something needs immediate attention.

• Together with the users, I came up with the idea to make it possible to mark important (cal)notes sticky. You can now pin a note to the top of the timeline, so it’s always visible when you open the contact.

There’s more!

I created an interactive prototype in Figma to bring the design to life. It includes:

• An email pop-up with a insert template feature

• A create task pop-up, showing how users can create and edit tasks.

Want to see it in action?

Chapter 4: Time to reflect

This was my first full UX project, and I solo worked on it. That meant I had to figure out everything myself. I took time to dive into online courses, YouTube, and podcasts to learn more, but this can’t prepare you for everything. So a lot had to be learned along the way.

Looking back, there are a few things I’d do differently in future projects:

• At the start of this project, I spent a lot of time designing on my own. That was partly necessary to meet the team’s request for quick delivery, so developers could start building. Still, in the future, I’d involve stakeholders earlier. Co-creating with users, developers and the product owner turned out to be key for designing realistic, usable solutions.

• I talked to users regularly, but I’d now set up a more structured way to collect feedback and measure impact. For example through surveys or usability testing. During my psychology studies, I learned a lot about how to study human behavior. I’d love to apply that knowledge to improve my user research and get to even better design solutions.

• When it comes to design, I often feel the urge to start right away. Sometimes I already have ideas in my head and want to turn them into polished screens as quickly as possible, to make them come alive. But I’ve learned that good design takes time. In future projects, I want to give myself more time for ideation and exploring: starting with low-fidelity wireframes, testing multiple flows and solutions, and staying open to unexpected ideas before moving into detailed design.

Most of all, this project showed me how much I enjoy designing business tools. Solving complex problems and making everyday workflows better really energizes me, and that has given me a clear direction for how I want to develop as a designer.

What my coworkers have to say:

The goal of this case study was to give you a good impression of how I work, based on a real project. Due to confidentiality, I can’t share more details online. But there’s a lot more I’d love to tell you about in an interview.

If this case study caught your attention and you’d like to learn more (about the project, about me, or about what I can bring to your team). feel free to reach out.

You can contact me via:

• Ilse_huizenga@hotmail.com
• LinkedIn