Starting a redesign, how I analyzed our UX interviews

December 4, 2017

The design and tech teams at Industry Dive decided it was time to begin the process of redesigning our content management system (CMS). As the company has grown, the CMS has had to adapt, but the system’s architecture is starting to show its limits. Components and features have been added ad-hoc throughout the years, resulting in a cluttered user interface with deprecated features and tedious processes. Through a redesign I hoped to improve workflows, reduce tedious tasks and create greater design hierarchy.

The redesign will be a large undertaking as stakeholders exist across multiple departments who use the CMS on a daily basis. A thoughtful approach with detailed user research will help to ensure we do not eliminate crucial functionalities or disrupt departmental workflows. To segment the project and make it more approachable, I started by only evaluating the editorial part of the system. This includes the elements of the CMS that help with writing and publishing news posts as well as sending daily newsletters.

CMS notes
A glimpse into our current CMS user interface.

1. Conduct the interviews

To start learning more about the editorial side of the CMS, myself and Nan Copeland, a former front-end designer at Industry Dive, took on the task of interviewing six editorial staff members of varying publications. Their roles ranged from associate editor to managing editor. Our interview outline:

  1. Define your role and duties
  2. Define a successful CMS
  3. Explain your greatest challenges using the CMS
  4. Walk through your common processes
  5. Explain any bugs and frustrations when using the system
  6. Any questions or concerns about the redesign

2. Embrace the sticky notes

After the interviews, I went through and made sure all the notes during the interview were clear and concise. I was then left with pulling out key issues and common hold-ups to help us know where to start with the redesign. I also wanted to discern themes across different roles and understand how the users interacted with the system. To do this, I started by finding sticky notes and a good sharpie in the office.

CMS notes
The process of how the interview notes were broken down by role and type.

First, I drew a large Venn diagram on the wall with each circle representing a different position (managing editor, editor and associate editor). I then pulled up the interview notes and started with those from the managing editors. As I read through the notes, I wrote down the information that corresponded with five different categories. For each category, I would write the note on its color-designated sticky note.

  • Problems
  • Ideas
  • Tasks
  • Wants
  • Notes

As I stuck the notes into their corresponding circle, I would place them in an overlapping section if the note applied to multiple editorial roles. I then repeated this process for all the interviews. By the end, I had a rainbow Venn diagram full of issues and ideas that we could use for our redesign.

CMS notes
The final result after compiling and analyzing the UX interviews.

3. Revealing the themes

I then found myself staring at this larger than life Venn diagram trying to take in all the different themes and ideas for new features and adjustments. Rather than having to get up and revisit the visualization every time I wanted to verify a theme, I figured it would be best to write them all down. I then combined the questions used in the UX interviews with my Venn diagram findings. This turned into the following outline:

  1. Definition of the three roles and their corresponding roles and tasks
  2. Themes users found that would define being successful
  3. Tasks and their corresponding habits, barriers to achieving goals and current work arounds for technical bugs.
  4. Ideas and recommendations for improvement

This outline and the Venn diagram set us up for a successful next step in the UX process: auditing the system as well as documenting the current user flows. We will then have a full list of current functionalities and the requirements for the new mocks.