ESTABLISHING UX-FOCUSED CULTURE AND METHODS

Promoting Empathy Between Stakeholders and Ensuring UX Vision and Business Needs are met

When I was first hired to work as a User Experience Design Technology Specialist at General Electric shortly after finishing my bachelor’s degree, I was under the impression that I would be working partly as a UX designer and partly as a front-end developer. However, what I did not anticipate was the lack of experience and design knowledge most of my team had. In retrospect, this task of introduction and implementation of UX principles and methods to the team was perhaps the largest in my tenure as a new, solo UX designer. Over my three years at GE, I would set up a framework for including UX specialists, principles, and methods in every stage of our team’s development process, including gathering requirements, implementing designs, and validating our interfaces through usability testing.

The problem:
How can UX vision, implementation feasibility, and business goals be balanced while incorporating UX best practices in an Agile structure?

My Role:

UI/UX Designer
UX subject matter expert
UX Researcher

The Team:

UX Designer
Front End Engineers
Product Manager

Tools Used:

Teams
Github
Whiteboarding

My Contributions:

Coordinating meetings between UXer, Engineers, and Management
Set ground rules for UX practices in Agile Development

The Process:

Empathize

Talk to front-end developers and managers

Specify

Identify priorities for stakeholder groups

Ideate

Write ground rules early on
Discuss edge cases with stakeholders

Bring to Life

Ensure an agreement is reached
Utilize these practices

Verify

Return to meetings to reevaluate set practices if needed

Outcomes:

Increased cross-functional collaboration between stakeholders
Effective usage of UX best practices
Reduced evaluation time for UX sign-off
- Designs more effectively adhered to in development sprints
Increased usability testing utilization
- New features would have usability tests following launch

DESIGN AND IMPLEMENTATION

Because my team placed my focus on due to our project manager handling most user research, my first major task was to establish a design standard as well as how to involve user-focused design in the process of creating pages and workflows for our website. With my team’s counsel, our first approach to address this came in three parts.

First, we segmented the work between my building of mockups and my team’s implementation of the designs present on them

Second, we established a plan to have all design work for a feature finished by the end of at least one two-week interval, known as a sprint, before the planned start of the development of that feature.

Finally, when the implementation began, we decided that the front-end development would not be approved for production until I made sure it was in line with the design schema.

Despite the segmentation and time delay, we also found that there was a need for feedback and reassessment of requirements for my designs, as leaving the design solely in my hands without collaboration would lead to confusion.

The solution to this was to set up biweekly design update meetings with my team. These not only allowed me to figure out what direction to take in designs based on my team’s feedback, but they also gave my teammates clarity on how to approach the implementation of the designs as the meetings also afforded me the opportunity to explain my design and workflow schemes in-depth.

ESTABLISHING A STANDARD

As our team grew in numbers, and as our site’s needs grew in complexity, I encountered my first major hurdle: there was a growing lack of education of newer members to our team, leading to a lack of adherence to our established rules and confusion on how deviations from designs should be approached.

To address this, I organized a meeting with my team to establish an explicit, written set of protocols for reference on how engineers and designers on the team would collaborate in feature requirement gathering and implementation of designs. One of my key points in this meeting was to listen to my team’s software engineers’ thoughts on how they wanted to approach the issue and find a solution that facilitated things for all involved.

In regards to the matter of feature creation, we decided that UX specialists on the team be included in meetings to set up requirements for features planned for our websites, brought in on conversations involving stakeholders such as developers of the products we were provisioning on our website. There, I would be able to ask questions such as the stakeholders’ goals with the upcoming feature, the information we would need to organize, and who our target personas are.

The matter of review of implementation, however, was more complicated. This was because while I wanted to prioritize adherence to design, the team at large was mainly concerned with maintaining momentum in development without too many design disputes obstructing the production process. We ultimately settled on a compromise:

Feedback from UX specialists was still necessary for the acceptance of front-end features before production pushes
UX specialists should be notified whenever changes would otherwise be ready for such pushes
However, only large deviations partway through development would warrant the UX designer’s immediate attention.
More minute changes could be overlooked and stockpiled for a much larger “mass fix” feature for a later date

These changes led to far more consistency in design, expedited production of features, provided a more official basis for back-and-forth feedback between myself and my team’s front-end engineers, and fostered more intuitive user interface elements being developed.

Most importantly, it led to much more cohesion throughout our team with both existing and incoming teammates.

COMING INTO MY OWN

With my job becoming more smooth as a result of our new team requirements, I finally felt confident enough to come forward with ideas of how to truly bring UX principles into the team: direct customer engagement and usability testing.

To elaborate, I hoped to engage with customers via direct interviews as a method of generating an outlook of their needs and pain points involving our website.

An opportunity arose when our team received a new product manager who also wanted to open up our relationship with our customer base more. After some preparation, we were able to meet with our main customer contact within one of GE’s subsidiaries, and I managed to conduct my interview, first addressing the “Five W’s” in the context of the customer’s usage.

Not only did we collect a bounty of feedback, but we fostered a deeper relationship with our customers in that business and set up the basis for a regular meeting cadence with them.

THE FIVE W'S (PLUS HOW)

Who the customer is (job, experience, etc.)
What their goal with using the site is
When (or how often) they use the site
Where (or on what device) they typically use the site
Why their pain points with the site are what they are
How to address their pain points

The case of usability testing was far more based on my own initiative than an opportunity. Upon the finishing of our first version of a new section on our website, I sought the assistance of willing team members to set up a plan for testing our design choices.

The procedure for usability testing went as follows:

Seek out individuals within our organization who knew of our site but did not use it
Provide the participant with permission to use our site's stage environment
- This environment was identical in functionality to the production site but did not affect our production site
Give the participant a set of tasks to perform using a recently implemented feature, encouraging them to think aloud
- Document the participant's thoughts and actions in notes
Ask for additional feedback following the tasks and document
- Make sure to utilize open-ended questions.
Combine notes of multiple tests into a report

After only a few iterations, the testing proved to be a resounding success as each individual pointed out similar issues in the pages such as layout and clarity of function, evidenced by the documentation of each test compiled into our team's repository.

Having developed my own UX schema around a team with a need for design focus, as well as bringing in proper UX standards, I feel like I have found my footing in my career in this field and have the foundation for building new things.