Just-In-Time Teams — My take on “Lean” Enterprise UX Team Structures

Over the course of this past year, I’ve been looking towards how collective UX teams are organized from an Enterprise perspective. When I say “Enterprise”, these are a few of my assumptions that I use to define that word, “Enterprise”:

• Larger overall team, with separated and defined teams covering various disciplines (e.g. visual design, front-end development, content strategy, etc.)
• Various approval processes and … erm… processes… to follow.
• Release schedules
• Timelines, deliverables, handoffs, kickoffs (no it’s not the NFL).

Okay, so with that out of the way…

With all of this Enterprise separation and process, it can be extremely difficult to align UX teams properly to allow them to work in a Lean fashion while adhering to all of the necessary structures.

But what if we could? What if, just by chance, Executives would listen and align teams to work in the most efficient way possible? What would that look like?

In a short sentence, I believe that these teams would look like small, cross-functional communities surrounded around a single group of outcomes.

A look at the dysfunctional community

To understand the idea behind functional communities, let’s first take a look at how our current communities are a bit dysfunctional.

An example Enterprise team structure

• Team: Visual Design & Information Architecture; Members: 8
• Team: Accessibility & Usability; Members: 2
• Team: Front-End Development; Members: 6
• Team: Content Strategy; Members: 4

In our pseudo Enterprise team, we have each team separated by discipline. Depending on your management structure, that can make sense regardless of how things go from a project process standpoint.

Seems pretty functional, right?

The dysfunction becomes more apparent when we start to peer into the daily working lives of the members on each of these teams. The reason the dysfunction generally exists? It’s so easy to miss.

See, the dysfunction exists in what isn’t there. We look into the daily lives of our team members, and we see them working beautifully. Our Visual Designers are designing beautiful treatments, and our Information Architects are plotting wonderful user journey’s. Content Strategists are creating the next bit of copy that will guide our users through the journey that our IA’s are so artfully directing.

Oh wait…

Does the Content Strategist know the journey that our IA is so artfully directing?

Therein lies just a highlight to the overall, glaring dysfunction. This doesn’t even begin the discussion that in most cases, the Front-end Development community members (our teammates) haven’t had a glance at, nor heard notion of, the ideas so beautifully being created.

Too often, these very talented teams are working on the same project, but over the course of an extended duration, and often not together.

“Just-in-Time” Teams

In my mind, a Lean Enterprise UX team, is a team that resembles the moniker of a “Just-in-Time” Team. The lines of separation on these teams are erased so that your full team is a collection of each discipline as necessary. This team sits together, meets together, works together.

This team is available for each other, and the business, Just In Time.

What this means is that, regardless of release cycle, your teams can begin building new ideas more rapidly by leveraging the Just In Time connection for rapid iteration.

Why spend so much time in discovery as separate teams? From the moment requirements are reviewed, these teams can rapidly sketch and prototype together. Having the perspectives of each discipline involved from sketch to development creates a highly centralized user and business focus.

An org chart should not determine how your User Experience organization operates

It is of my opinion, that User Experience organizations should be ran in a manner that all teams within the common organization work fluidly with each other. I believe, too often, teams are pitted against each other while hearing the mantra of, “if one fails, we all fail.”

In a world where so many deal with the constant pressure of “security only without failure”, the struggle to build “one team” is real. That, however, is not a good reason to settle.

A Reorganized Example Enterprise “Just-In-Time” team structure

• JIT Team 1: Visual Design (x2), Information Architect(x2), Front-End Development (x3), Content Strategist (x2), Accessibility & Usability (x1); Members: 8
• JIT Team 2: Visual Design (x2), Information Architect(x2), Front-End Development (x3), Content Strategist (x2), Accessibility & Usability (x1); Members: 8

The reorganized team structure above, uses the exact number of community members, but puts them together into two, focused Just-In-Time Teams. These team members are aligned to leading specific objectives and outcomes for the organization.

Who’s missing?

There are a few teams of course missing here; our CMS team, our testing teams, our project management team, etc. There could be an argument, depending on the organization and setup, for including members from the testing or CMS team within these JIT teams. Structuring modular, and reusable content components within a content management system is a huge part of modern web direction. Being able to rapidly test pieces in an agile fashion as they are developed, is a new skill and challenge for many of our Enterprise testing models.

How is it different?

The Just-In-Time Team Model is different in that it allows you to have highly focused teams, dedicated to building rapid components and sections of business goals. This higher level of focus around the combined and holistic user experience, as well as the detailed project plan with feature priority, allows for every Line of Business to hit publish timelines — on a highly, consistent basis.

That’s not to say it’s all moonlight and roses. There are several challenges to overcome within an organization when you make the leap to a Just-In-Time Team model. Some of the larger things to consider, include:

1. Deliverables
2. Approvals
3. Testing Scope and Dependencies
4. Historical Documentation

Deliverables

As disciplines get blended, teams begin working in the same space… a lot. I think that is fantastic. However, those wonderfully defined Axure wireframes we’ve always approved suddenly (or potentially) start to disappear. The perfectly designed Photoshop comps to a perfect pixel are now prototypes shared in a browser. Determining how that works for your organization around roles and responsibilities, requirements, and other details is something that should have a large amount of focus early on.

Approvals

Those deliverables we just talked about? Yeah, they completely throw a wrench into our classic approval models. Executives used to approving design comps are now being asked to look at prototypes in the browser, or on various devices. As we work out the deliverables, the approval process naturally weaves it’s way into the discussion. What does not seem to always become a focus is education for those approving. Just as we are discovering this modern world of rapid development, those approving our deliverables need to be given the time and focus to understand exactly what they are seeing. The more we do that, the more we get everyone on the same team and the same page.

Testing Scope and Dependencies

For larger organizations, there are lots of considerations and variables in play when it comes to not only the scope of testing, but the dependencies required by the testing teams. Are we providing design comps for each and every breakpoint, for each and every unique layout within a project? Are we providing a living style guide that defines component behavior and style, along with a layout library of approved page layouts? Testing teams are our final line of defense when making sure that we keep consistent brand treatment and expectation. Defining clear dependencies, who is responsible for delivering them, and when is key.

Historical Documentation

This fourth challenge, of Historical Documentation, is one that may take the form of whatever the final deliverables were. Whatever it is, there will need to be a historical reference of the project. In many organizations, design comps and other specifications have served as this historical record. Initially, this may be something as simple as screenshots to serve in the place of fully baked comps. Long term, perhaps even a tagged version of the prototype in a feature branch in a GitHub / GitHub Enterprise repository. Hey, I can dream (it happens somewhere!)

Bottom Line… Let your teams work together more!

Regardless if your organization is ready to make the Just-In-Time team model shift or not, all organizations need to let our creative and engineering disciplines work together more! The various members of the community generate a laser focus of the team’s perspective of the outcome, and not on one individual’s gut feelings.