A Case Study:

UX Process Development

ACS Technologies

One of the first things I did as the UX lead at ACS Technologies was circle the team around establishing our intended process. We looked at how development was done, identified and isolated the problems we were facing, and concocted a process that would help us tackle those issues.

The Problem(s)

Since we were just starting out as a team, we knew that we had to build credibility with the development teams we were trying to serve, and the stakeholders on the product.

Our development processes were flawed too - despite a recent move to Agile methodology, the stakeholders were often unhappily surprised with what was being built and released.

We were unsure that we were building the right things in the right way, but some on the team were hesitant to push too hard, having been treated poorly when they tried to push for higher standards in the past.

UX design had been outsourced, too - and since the designers weren't integrated into the process, developers were taking significant liberties with the design as they implemented, so there was no guarantee that what was designed was what would be released.

What research told us

First thing I learned was that ACST has many stakeholders - not just our Functional team leads (R&D, IT, Support, etc.) and our Customer team leads (based on church size, organization, etc.), but also people in Training & Implementation, Documentation, and of course the C-suite of executives. That's a lot of people to keep in the loop and a lot of disparate expectations to manage.

And many of those stakeholders had significant knowledge that we needed to leverage as part of our process, not to mention the various SMEs (Subject Matter Experts) scattered throughout the company. That meant that for each project we did, we'd have to manage the knowledge both inside and outside of ACST.

Another thing was that R&D was highly sensitized to two things: one, anything that would become a bottleneck to the development teams; two, anything that didn't seem to fit how they understood Agile.

As an organization, we were unclear on how to decide on work to do and prioritize it against everything else; the idea of opportunity cost seemed new, and there was a widespread assumption that we could do anything and everything. Stakeholders would assume that we were working on one thing, but the POs may have decided autonomously that something else was more important.

We needed a process that would fulfill these goals:

  1. Help ACST understand what was most important to work on at any given time.
  2. Collect input and feedback from a wide variety of users, stakeholders and developers, at the best possible time for the project.
  3. Inform and update everyone regularly, and give visibility into the work being done to increase confidence in what we build and why.
  4. Include stakeholders, production teams and others in the process so that we can eliminate fences and operate as a single team with collective ownership over the results and less surprises.
  5. Set expectations around time requirements, and show the value of drawing out the process enough to facilitate better understanding of the problems we faced, and enable proper validation of our design and development work.

Really, we wanted to build a process that would do right by our Users, our Stakeholders and our Devs.


If I remember right, this is what happens when you use windex on a whiteboard. Now you know.

What we did

At the start I outlined a basic process:

  • Project research
  • Problem definition
  • Epics, Scenarios and Stories
  • Define MDP (Minimum Desirable Product)
  • Wireframes
  • Team Review
  • Visual Design & Development
  • Final Review
  • Release

Our group discussions fleshed out the details of each phase, including who was involved and what our deliverables might look like, on our filthy whiteboard. At the end of our meetings, we had what we felt was a pretty good plan, and we had the approval of our R&D director and our Chief Product Owner.

We got things going for a few months, worked with POs to build out the process, and then evaluated how we were doing.

One thing I discovered about running a bi-coastal team (or any team with remote members, for that matter) is that it's critical to be face to face at least a couple times a year; any less than that, and trust erodes, you get out of sync, and relationships begin to atrophy. There are still a few things that video conferencing doesn't do well - and true relationality is one of them. So every six months or so we planned a UX Summit, headed one direction or the other, and met together for a few days. And we always talked about process.

So about six months later at our UX Summit we looked at some problems and some places where things weren't going to plan, and revised. In the interim, our product marketing plans had changed (to a three-tier model), and we were having much more in-depth conversations around concepts like MDP, Jobs To Be Done, and Scenarios. We worked out how to build those concepts into our process, along with better definition of generative research and validation research.

We ended up with a much nicer diagram that time.


Nothing like a good diagram to help people understand. Note my sweet, sweet symbol for 'iteration'.

But as we implemented our process revisions, we noticed that there were still some things that were missing: the most significant was that we still lacked an overarching vision for the product (which is an alarmingly common issue in Agile shops). And while we were trying to hold all that together as a UX team, it was clear that each production team was marching to its own drummer and our cohesion as a product was suffering.

I got together with some of the stakeholders and recast the vision for the start of our process - and the concept of SuperEpics (now called Themes) - a very large swath of functionality that would cross teams and disciplines, require a good amount of back-end work, and would need to adhere to an overarching vision. I added that to my diagram (which, thanks to an enterprising stakeholder, was printed up and hanging in poster form in one of our conference rooms) and started to look at our projects in a bit of a different light, which has led to some significant improvements in how our organization looks at its product and process.


New 'Super-Epic' bit, and clearer review steps on the other end, too.

Impact and Takeaways

The process has continued to adapt in the last couple years - this story ends in about January of 2016 - but the process of building and developing it has borne a lot of fruit in our company:

I changed how our UX team works. Instead of our UX team operating across all production teams and managing its own backlog, each production team now has its own designer and researcher who work in a more dedicated fashion with the team. Some designers and all researchers support multiple teams; however we are able to maintain far greater focus and better communication, and each designer and researcher attends most of the Agile meetings (story point, sprint planning, etc) with each team. But it's important to note that we still operate as a Community of Practice, meeting weekly to discuss and review our design and research work together, and to work on projects that supercede the production teams - like User Personas, Design System, etc.

We implemented the idea of Design Studios to include the developers more deeply in the design process. In a nutshell, it's an intensive that lasts a day or two and focuses on a specific theme or epic, and while it's taken some doing to work out the kinks, it's been a great way to foster much deeper collaboration in our projects, across all disciplines.

Recently we recognized that for all our process and communication, there were still unknowns that were creeping into our process far later than was acceptable, and it was derailing sprints; some of that was due to design surprises, but some was due to other support teams (like Architecture or DevOps) being brought into the project far too late. We recently created some checklists that have helped - specifically Theme Ready, Design Ready and Engineering Ready. These force awareness around our unknowns, and help us remember to push for clarity all the way through the process so that our planning, design and development efforts are seeded with as much truth as possible. 

Considering that we started as a ragtag group of pot-stirrers, our UX team has gained a great deal of credibility in our organization, especially among stakeholders, but also among our development teams. While a process isn't the end, but only a tool to get there, it's given us an agreed-upon framework through which to pursue excellence for our product. The product itself, and our relationships with those who contribute to it, have benefited greatly from the work that's gone into creating it, and it shows.

Our discussions around Themes led to a corporate realization that we needed to resurrect the discipline of Product Management (rejecting PM for Product Ownership is a classic blunder in Agile). This group now exists outside of R&D to do the upstream research for themes, connect them to business goals, and prioritize our work. It's early yet, but things have already improved a great deal, and it's forced many an issue around transparency, opportunity cost, and the true vision for our product.