Work in progress!!!

What I learned at GTRI

Overview

Redesigning a Quality Management System website for ELSYS at GTRI.

Timeline
2 years (and still going!)
My role
UX research & design
Skills
Personas, empathy maps, sketching, wireframes, prototyping

The Goal

Create a simplified website that allows employees to quickly and easily find up-to-date, relevant documentation for their projects.

The Problem

The ELSYS lab at Georgia Tech Research Institute (GTRI) takes on large contracts which require thorough paperwork. The current ELSYS website holding these documents (Quality Management System (QMS) website) has become antiquated and difficult to use, resulting in many complaints.

My role

My role is to be a third party which analyzes and diagnoses the site's current issues with user research, and to design an improved user interface that will provide ELSYS with a clarified product development process website.

Context

keep both end users and client-side stakeholders involved.

When I first started on the project, I was focused on collecting data from the site’s end users. I worked with QA to build and distribute a survey and conducted a series of interviews, and learned about our end users and the problems they experience with the existing site.

I quickly learned that in addition to user research, there was a great deal I could learn from the people who helped to build and maintain the site. People on this team had a range of expertise and backgrounds, from detailed knowledge of the QMS to in-depth technical experience.

Ultimately, it was crucial that I used findings both from end users’ and the client’s side. Connecting frequently with my team meant that I had more diversity in my insights, could better understand technical limitations, and ultimately a design a solution that met everyone’s needs.

lesson 1

Keep careful track of process documentation.

The process of this project was far from perfect – many times, moving forward on the website design meant taking steps backwards. Conducting user testing on a prototype would sometimes reveal a big design oversite – we would have to step backwards and re-consider these features.

I learned that keeping documentation stored and well organized was critical. It helped me save time, by helping me to find relevant documentation and also preventing me from redoing unnecessary work.

In these instances, the documentation that was most helpful provided a synthesis of key insights and findings in an easy-to-digest format. For example, I revisit personas, affinity maps, and documentation outlining site goals very frequently.

lesson 2

The fidelity of prototypes determines the feedback.

After the first round of user feedback, I presented my findings and the current prototype to the project team. At this stage in the project, I wanted feedback to be based on navigational experience and organization, not content or aesthetics.

The fidelity of the prototype ended up working against my feedback goals. The prototype had colors and content. Immediately, the team started providing feedback on the color scheme or details about sentence structure and grammar. Despite my efforts to reroute the conversation, I found that it was too late – these topics of conversation kept resurfacing and valuable time was lost.

I learned that it is my responsibility to guide these conversations. Alongside writing a schedule for these meetings, I adjusted the type of information in the prototype. When I wanted feedback on site navigation and structure, I would use filler text and minimize the amount of color on the prototype. In addition, I would bring documentation that showed the site at a higher level, such as a site map, so that the team could visualize structure more easily.

lesson 3

Every solution will require some compromise.

We are currently trying to decide on a platform for the future site. There are several viable options, but the two on top are Confluence and WordPress.

The proponents of Confluence are our end users. Teams at GTRI often use Confluence – putting the new site on Confluence would simplify their workflow and make training new employees easier.

On the other hand, our technical consultant is very critical of Confluence – he has seen many ‘trendy’ solutions at GTRI that end up quickly replaced.


We are still working on deciding on a platform – it seems like a battle between longevity and convenience. Either solution will require us to compromise on one of our site’s end goals. So far - my strategy on making a decision is to complete a Pugh Matrix comparing the two options, and holding a group meeting between the entire team to collaboratively discuss my research findings and find common ground.

lesson 4