UX: “better than nothing” is not enough.

I’m a UX designer. A few months ago I left a company where I had a great UX reputation and where I was doing a good job.
For all the years I worked there, my top performance objective was to help all the teams with their UI and UX needs. I was a UX team of one, wearing different UX hats to accommodate different requests. I thought I was doing a good job… 

But I failed.

I was (and still am) extremely passionate about the UX discipline; about solving the human problem; proper UX process, and all the right things.
The organization was not UX mature and I advocated for investing in UX by showing teams the value of it and that doing at least a minimum UX is better than nothing.

The mistake I made.

Advocating for UX was the right thing to do. I knew the value that UX brings and tried to accommodate every team which needed help. But sometimes I could only do so much for the time I had. As a result, it wasn’t the best UX that could be delivered if I had had more time to invest in it.

Unintentionally, it created a false impression that the UX work was done versus the UX work that was actually needed. And overall, it was masking the need for larger UX capabilities in the department.

Applying a minimum UX work to accommodate all projects masked an actual problem the department, and the whole company had: there weren’t enough UX capabilities to do the right job.

An opportunity to improve.

There were a few things needed in order to improve the situation:

  1. I needed a proper estimation of the design efforts for each project.
  2. I needed to remove silos and communicate clearly how much UX work was needed across different teams.
  3. I needed to state my availability clearly and not overcommit.

Proper estimation: measure how much UX work is need

One of the steps in the process of bringing UX into an organization is to realize and measure the amount of UX work needed and the proper capabilities to support it.

Cristian Bosch in his article “How to think like a Product Designer”, talks about the estimation of the work and why it’s important: “Before getting to work on a new product, set the stage by defining goals and a timeline of the work involved for each phase. This will give a clear picture of the design efforts ahead and will allow you to align with other teams as well.

Do not over-commit.

If you know how much time it will take, you can plan accordingly. Right? The math here is simple, but somehow I kept stumbling. It was not a coincidence that one of the most common feedback I received from my teammates was about overcommitting to work with everyone who needed UX on their project. I realized it was not easy for me to say no to a work request. But, to have the UX work estimated correctly, it’s important to plan realistically, and stick to it.

To have the UX work estimated correctly, it’s important to plan realistically and be able to say “no’ to constant demands to deliver something quickly but shorthanded.

Visibility and communication: removing silos, creating a backlog of work, and task prioritization.

I realized there was another opportunity to improve the situation by simply making requesters aware of other work that I was doing. Having my own backlog of items was not enough – the work had to be visible to different requesters.

In my other article, “The productivity of the team of one: from sticky notes to a personal Kanban board“, I wrote about an adaptation of Agile methodologies and a journey from using sticky notes to a personal Kanban board that helped to make the work visible.

But, besides creating the backlog, and visualizing the work to estimate, and measure what is needed, I realized I needed to know the strategic priorities, projects, and timeframes.

To measure and prioritize UX work across multiple teams, there should be an alignment of UX work with the product’s roadmap, and a cross-team backlog of work items.

Prioritization and backlog building should be a group effort that involves multiple teams. That’s why the effort should be supported by the leadership.

As the organization matures in the UX discipline, there are certain steps and events that happen over time. As a team of one, I couldn’t control the progression of those steps, but I contributed to the process, and saw slow improvements: there was support from the leadership, and there were changes in teams’ understandings of the UX discipline.

Leadership support.

The leadership’s understanding, support, and investment into UX capabilities is a sign of the organization’s UX maturity.

The process of UX maturity was something that I contributed to by advocating for the UX process, educating my team about UX, and doing as much as I could to show the value it brings. But as it is with any growth process – organizational UX maturity takes time and a sequence of certain steps and events. It’s like a child becoming an adult – you cannot force the process and leap to adulthood.

At that time, the organization invested in an adaptation of a framework for scaling Agile across the enterprise. They used SAFe (I have my reservations about this framework, but it’s a topic for another article.) The one important thing that happened at that time – there was a multi-team effort to plan the work and improve communication between groups. The new process also raised some visibility to what UX is needed across different teams.

When the business learned how much UX work was required they realized they needed more people to support that work.

The UX mindset.

I wrote this article a few months ago but it was sitting in my drafts until now. Since that time I switched jobs and can report that the previous company hired four UX professionals – the minimum number of UXers that was needed to do the right job in that department.

A few months passed. In a conversation with my former coworkers, I heard a phrase, that “nothing really changed with four UX professionals on the team”. That made me think that hiring more UX designers was the right thing to do, but no matter how many people are working, there always will be more work.

In a recent article “Build Up Your Organization’s UX Design Capacity” written by Jared Spool, the author says that “your team will never be large enough. …Instead of focusing only on growing your UX team, you need to increase your organization’s overall UX design capacity. …You need to grow everyone’s ability to make smart design decisions.

. . .

I’m confident that many UX teams started from a team of one, and progressed through a similar growth process to become larger and more mature UX organizations. I hope that sharing my experience might help others in similar shoes to make their work, and UX maturity progress more efficient.


3 thoughts on “UX: “better than nothing” is not enough.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.