Beyond “Lipstick on the Pig”

Instead of Another Opinion, Let's Get Evidence

Design discussions can become surprisingly subjective.

One person prefers A.

Another prefers B.

Both can produce convincing explanations for why they're right.

The Oregon Department of Education work gave us an opportunity to replace some of that argument with observation.

TCC sent UX people to the client site to conduct usability sessions. That was a meaningful change in the company's process: rather than relying exclusively on internal interpretation of client requirements, we would sit with the people using the system and watch what happened.

We had two competing interface concepts.

So we tested both.

A/B Didn't Mean “Pick a Winner”

Annie Rayhill and I conducted roughly 30 moderated sessions.

We deliberately crossed the designs between moderators.

I conducted sessions with A and B.

Annie conducted sessions with A and B.

That mattered because otherwise the moderator could become another uncontrolled variable.

Two senior Oregon staff members helped record observations and results while we conducted the sessions.

The interesting result was that the research didn't tell us:

A wins. Throw B away.

Users revealed useful things about both.

Some interactions worked better in one concept.

Others worked better in the other.

The answer wasn't A or B.

It was evidence for C.

We took what users showed us and moved toward a hybrid that combined the strongest parts of both approaches.

That is a much more interesting outcome than a design contest.

The Mockups Were Never the Product

The sessions would have had limited value if the findings ended in a research report.

They didn't.

The Oregon work directly informed what became Ascend, TCC's commercial product offering, and Oregon became its first client.

I worked on both the Ascend Scrum and Oregon Scrum teams afterward.

That gave us something I consider extremely valuable:

continuity between discovery and delivery.

The person who had watched users struggle with an interaction could still be present when the team discussed how that interaction should behave in production.

Research didn't have to become a document somebody else interpreted months later.

It remained part of the development conversation.

UX and Business Analysis Needed Each Other

Another useful consequence came from the relationship between UX and business analysis.

Business analysts understood requirements, processes, client obligations, and domain rules.

UX was asking a different set of questions.

How does a person know what to do next?

What do they think this control means?

Where do they hesitate?

What information do they need at this moment rather than three screens earlier?

Neither perspective was sufficient by itself.

The Oregon work demonstrated how effectively the two could operate together.

That BA/UX collaboration became a model TCC could use beyond the original engagement.

That may be one of the more important outcomes of the work because it wasn't merely a screen we improved.

We improved part of the process that produced screens.

Then You Still Have to Build the Thing

Research doesn't eliminate engineering constraints.

Eventually somebody has to turn the recommendation into working software.

My role at TCC increasingly crossed that boundary.

I wasn't only interested in what the interface should do.

I could follow the question into the front end and help determine how it should do it.

That mattered on Ascend and Oregon, and it became increasingly obvious in the other work I inherited.

The Corporate Website Was a Different Kind of Reality Check

I initially helped Adam Clark with e-tcc.com and eventually inherited essentially the entire front end, excluding the backend and API work.

The site lived in an ASP.NET environment.

The frontend needed stabilization.

CSS had accumulated.

Performance could improve.

So I cleaned it up, moved styling toward Sass, and worked on front-end quality and Lighthouse performance.

That work also provided a useful reminder about professional influence.

I could identify an accessibility problem.

I could explain it.

I could recommend correcting it.

But I wasn't always the person with final authority.

A teal treatment used on the site did not meet the contrast standard I would have chosen. I raised the issue. Product owner Steve Fey wanted the treatment retained.

So it remained.

That's not a story about ignoring accessibility.

It's a story about accurately understanding your responsibility inside an organization.

My responsibility was to identify the issue and make the recommendation clear.

The final product decision wasn't mine.

Vertex Put Me in the Technical Lead Seat

The Vertex work pushed the development side of my role further.

JR and Audi handled the visual direction.

I led the technical implementation.

The project began in Angular 5 and continued evolving as the framework moved forward. By my final week at TCC, I had completed the move to Angular 8.

That progression mattered because it reflected how my role had changed.

I had started at TCC in an environment where UX improvement was described as putting lipstick on an existing system.

Now I was leading the implementation of a modern Angular application.

One of the most visible pieces was a carousel built for Vertex's trade-show presence.

It used the donut and particle effects that became part of the visual experience, and it had to be delivered on a compressed timeline.

That project reinforced another useful collaboration model:

The designer didn't have to become the Angular developer.

The Angular developer didn't have to pretend to be the visual designer.

JR and Audi could concentrate on what they did best.

I could concentrate on turning the visual concept into reliable software.

Not Everything Around the Work Was Healthy

The technical and UX work existed inside a company experiencing increasingly serious organizational problems.

TCC went through five CFOs during roughly four years.

There were payment problems involving major client work, including Oregon and Michigan.

Eventually the financial strain reached the staff.

I was part of the first group of 14 employees laid off.

More people left during the months that followed.

That isn't a UX failure or an engineering failure.

But it is part of the case study because products don't exist separately from the organizations building them.

A team can be doing useful work while the business around that work is unstable.

You learn to distinguish those things.

How We Navigated It

When we lacked evidence, we went to users.

When A and B both contained useful ideas, we didn't force a false winner.

When requirements needed interpretation, UX and business analysis worked together.

When visual design and implementation required different strengths, we divided responsibility accordingly.

When I inherited frontend debt, I improved the layers I actually controlled.

When I identified a problem whose final decision belonged to someone else, I made the issue visible and documented the recommendation rather than pretending I had authority I didn't possess.

And when the organization itself became unstable, I kept the quality of the work separate from the condition of the company around it.

Products Aren't the Only Things You Leave Behind

Looking back, the most interesting result of TCC isn't any individual screen.

Some of the artifacts belonged to TCC or its clients and appropriately stayed there.

Some applications evolved after I left.

Some organizations changed.

That's normal.

The more durable outcomes were patterns of working.

Go watch the user.

Test the competing assumptions.

Let evidence change the design.

Keep UX connected to implementation.

Pair domain knowledge with interaction knowledge.

Let specialists own their strengths.

Identify problems clearly even when you don't control the final decision.

And understand that sometimes the most valuable thing created during a project isn't a particular interface.

It's a better way for the people around that interface to work together.

I arrived at TCC hearing that we were putting “lipstick on the pig.”

Four years later, I had conducted client-site research, helped turn those findings into a product, worked across two related Scrum teams, developed a BA/UX collaboration model, inherited and stabilized a corporate frontend, and led Angular implementation for Vertex.

The biggest change wasn't the technology.

It was my understanding of what UX could be.

UX wasn't the coat of paint at the end.

It could be research.

It could be requirements.

It could be code.

It could be collaboration.

And sometimes it could change not only what the team built, but how the team learned what to build in the first place.