UX Research for GEODE Usage Data Tool

Working on a team of project managers, developers, and marketers, I worked as the UX lead on a project that had the goal in mind to research, develop, and implement a usage data tool for internal and external usage of Elemental Technologies streaming solutions. I create the information architecture, conducted internal interviews about project needs and goals for usage data, designed workflows for the UI, created personas, and helped explain the reasoning behind design decisions in the final project pitch.

Plugins-17

Problem

The overall issue, which was the lack of usage data for the company to use, was near to my heart. As a UX’er, knowing not only who are users are, but also what they’re doing, using, and running into, is crucial to creating intuitive products for all kinds of people. But also, at Elemental Technologies, there was a lack of emphasis on researching and designing products using typical and robust UX methods, so as a singular UX professional at the company, I needed to not only help the project run smoothly by researching and designing the interface and information architecture, but also figure out the best methods of buy-in and utilization of my research and design recommendations.

Research methods and creating buy-in

The first thing we wanted to know when creating the usage data tool was features. What did people want in the final service? What was currently missing in the company that could be improved with this tool? How can we design a product that has continued use and maintenance? What kind of information is most important?

geode-interviewfindings

I interviewed multiple managers, stakeholders, developers, designers, and marketers to ask about how their current job could be improved with this tool. Some had clear cut-outs of what they wanted from the tool, while others helped us see a lot of current issues with internal tools that we could avoid when creating the product. One thing that I kept in mind was that, since these interviews were so important, there needed to be a way that I could emphasize the importance of talking to people first, before a product is created. And so I encouraged our team, which was mostly made of developers, to take the time to sit in on a few of the interviews and ask questions as they came up. This proved useful, and I could see a lot of the conversations in stand-ups being centered around what current pain points are, what our users need, and why we need to make sure the product is made in a certain way.


Personas and workflows

After a lot of my research was completed, I created personas that could be utilized by the developers and aid me in talking about the product in out project pitch. I also created potential workflows for how people will run through the site and where we need to structure the information so that people can find and use the pages easily.


 

personas-02


personas-13


personas-12


 

Even though we were going with an open-source platform that had an easy-to-install UI, I needed to create the structure and design of the site. I utilized a lot of information architecture best practices from card sorting practices and data from the interviews to figure out how the navigation should be set up. The platform, which was an internal database, needed to be quick and intuitive based on user needs. After the initial workflow and architecture was created, I put the interface in front of potential users as quick as possible, and tweaked the design based on feedback and usability issues.

kibanaworkflow2-01

After the project was completed, I documented and pitched the design of the UI for future implementation after my internship was completed. I also reflected quite a bit about the impact on my confidence and the ability to rapidly research, design, and communicate my designs in different ways.