Audience and Challenges

The audience for this product was marketing communications across various levels of leadership. Individuals on the teams also had multiple and different levels of clearance due to the position held or project they were working on. The most unique factor of this project was the constraint that comes with confidentiality. The users of this tool all had different projects they were working on and strict deadlines for each one at the time. It was challenging to get a moment of their time and gain their trust enough to be in a location I was authorized to be in. When we could get a moment of their time, we had to make it count, and this came from developing trust and being empathetic to their needs.

Our users shared many hesitations and pain points, such as tight deadlines, the tool being only accessible on the desktop, and security concerns due to the sensitivity of their work. We created three different user profiles to accommodate our audience's needs.

• Managers who need to assign and remove disclosures, regardless of their disclosures, cannot see assets they do not have a disclosure.

• Administrators who need to add new users, assign teams, and make users active or inactive.

• Standards users who need to create projects, edit their personal information, and develop assets and tickets. A standard user would be any user who does not have extra privileges, such as a manager or administrator.

Studio Artist - Standard Users goals and needs:

• Creating assets required by cross-functional teams. 

• Editing and updating assets are in line with the notes given. 

• They have a strong relationship with artists and cross-functional teams. 

• Delivering assets on tight deadlines. 

• Communicating with studio managers and cross-functional teams.  

Responsibilities

When I started this project, it was a small team of project managers and developers. I was brought on to begin with QA and was able to speak directly with the developer about the tool's design. As time passed, our team grew to include four additional QA engineers and another developer, allowing me to refocus my time on research and innovation. I was responsible for most of the onboarding and creating documentation for our tool and analyzing documentation, additional user testing, user interviews analyzing user testing data, and occasional code support.

Process

The first step in this project was to get a high-level understanding of the tool people employed, how they used it, and their roles in the company.

Next was to understand what the new tool did and how it worked. Because the pressing task was to run QA on the software to find bugs and get everything ready for release before adding new features, I developed a deep understanding of what the users should be able to do with the tool. I developed a relationship with our users during this time because we worked together in the same office. The ability to create trust with our users was helpful because they could openly discuss their dissatisfaction with the current tool. Through this guerrilla-style testing, I learned about the user experience and interface issues causing their frustration. This information allowed me to sketch ideas and speak directly to the developer to see what we could fix in the current tool while looking at our backlog for the new product to ensure we had stories addressing our users' needs.

Knowing my time was limited because of my contract. I wanted to leave the team with detailed, easy-to-navigate documentation. This mindset helped support and onboard our new team members, and I was able to walk away from QA responsibilities and focus on user research and design. I reviewed and synthesized previous usability testing results and conducted additional user interviews. The relationships I had established in the studio helped me get interviews with stakeholders who needed more time to spare. When meeting with these people, I used our time effectively to determine how they used the current tool and see what workarounds they created to compensate for the tools' shortcomings. These conversations led to adding features and functions to the existing device. They influenced the design of the new tool. I created wireframes and mock-ups of search pages, artist dashboards, and project assignment authorizations.

Outcomes

Ultimately, some of my recommendations could be incorporated into the current tool to improve the production artists' workflow while the new device works. This addition was a goal because improving a small thing can significantly affect someone's life, and enhancing someone's workflow when they have a highly demanding, high-pressure job is a win. Another important overarching lesson I learned from this project was how to work on something with confidence as a top priority and work with users who need to be mindful of the information they share to stay in line with the NDAs they have agreed to for their jobs.