Everybody Conga! or: How to Break Free From the UX Bubble

A discussion against the rigidity of a User Experience support team.

Aug 8, 2018 · 7 min read

Software and tech companies are realizing more and more how critical User Experience is to the livelihood of their products but are still torn on the best approach for utilizing UX professionals to their full potential. Companies recognize that User Experience is needed to make products that people can actually use and ones they really want but they may struggle in the application. This is, in part, a role that UX engineers must help define.

The challenge is two-fold: many companies see UX as an after-thought to development and may stretch UX engineers too thin over many tools. This lends itself to creating a support team mentality where a group works outside of the development teams to provide support ad hoc. I prefer to refer to this approach as the UX Bubble. Characteristics of this approach include:

  • Self-contained group of User Experience Engineers
  • Team owns their own individual process (Kanban, Agile, etc.) separate from development team(s)
  • Designs and concepts are delivered and the development team creates their own requirements based on work received
  • UX acts as link between customer and/or user but are excluded from engineer’s processes (and engineers are likewise excluded from UX processes)
  • UX value is seen only to make interfaces look pretty/sexy/flashy and therefore are brought in much later in the development process
  • Isolation reduces understanding about UX importance and soft-skills, therefore UX becomes “just mockups”
  • Development progress frequently blocked by UX support

The Bubble approach can be effective in letting the UX team be free from team’s demands, technical constraints, and allow them to create designs that are based solely on user feedback and customer requirements. However, it is very easy to become isolated from the development team during this process and inadvertently forces a delivery-based schema stunting creative exploration. The freedom to produce the project’s dream vision is put on hold while the team is stuck working in a factory line.

Isolation in design stunts discussion between UX and software developers where a shared vocabulary is key to product development. In order to design interfaces and workflows that would ultimately create a useful product, UX needs to know: what technologies are available? How do they function? What is the best way to use them with these design patterns? UX needs to be able to verbalize to customers how the tool will work technically and understand the technology used in order to “sell” design decisions to the customer and be able to create compromises between production requirements and end user needs. Customers can easily buy into a grand vision but a UX team can quickly design themselves into a corner when the finished product does not reflect what was promised in those early interviews, as such, you are practically guaranteed to produce a completely different product from what was originally intended.

The Bubble Method also puts strain on the engineering team when their work does not match the original high fidelity design.

For a short period of time I was working as a member of a User Experience support team where we created mockups, conducted user interviews, and held customer meetings for a variety of software tools. We had our own kanban board completely separate from each development team and no insight into what the priorities were for any of the developers. I was tasked to do a mockup for a specific feature and was given a maximum of three days to complete it. Imagine this: no access to technical information (what language/library/style?) nor did I know where this would fall into their sprint. The best part of this was I was told I was not allowed to reach out to the developers on the project unless I scheduled a formal meeting with a handful of other people, and that would take weeks.

The best I could do in this scenario was make a wild guess and pass the wireframes off via email where we asked for changes within a set number of days. I never heard back. I later moved projects and did not know if the feature was ever implemented.

This was the standard procedure for years on this particular project and I would hear my teammates complain, months after design, that the engineers had “Gone Rogue”. Now the team had to spend time putting in requests for tickets for developers to fix their code and design because it did not look or function as designed. With no communication, can you blame them?

When people live in the Bubble, they seem to exist beyond others and that fosters feelings of resentment or fear, leading to a “them vs us” mentality, where the end product may be completed but is not nearly as successful.

With that being said, it seems almost contrary for me to mention that there may be cases where some may feel that the Bubble is an appropriate approach to include User Experience Engineers within the development cycle. Perhaps there are more projects than UXers forcing them to juggle many projects or it is a method to protect them from those who ask a little too much of them. However, in my experience, the Bubble fosters isolation and exclusion and that should not be a solution for any team.

In my experience, projects tend to be successful when everyone participates in the Conga Line. I prefer this term because it illustrates a group of people, all working together, in the same lane, to reach a common goal (and they do it with a smile).

Opposite to the Bubble approach, the main elements of the Conga Line feature:

  • UX is included early in the development cycle and have a part in the team’s production process
  • User Experience Engineers included in the overall team structure and, when included early, UX does not hold up development progress
  • Designs and concepts are created and reviewed with shared knowledge and input from the development team
  • UX acts as link between customer/user, developer, product owner
  • Avoid “show and tell” — UX mockups are reviewed with developers to discuss technical constraints, customers to match requirements, and users to analyze level of usability
  • Allow developers to learn about UX and give them hands-on experience — Creation of “Shared Vocabulary”, insight, and comprehension

The Conga Line inherently tells everyone that they are all on the same level and aims to remove any sense of superiority from one’s role. A shocking truth is that UX is not lower, or above, developers and are just as crucial to the creation of successful software.

Team members can save time and avoid needless redesigns through better communication and mutual understanding. Communication can be enhanced by UX members allowing developers their world: developers should listen in on user interviews, let them see how the users think, and help them understand design thinking techniques — not just the technical aspect but also the human portions.

On a previous project of mine, I asked one of the front-end developers on our team to accompany me to a meeting with one of our key end users. I took with us copies of mockups of our proposed redesign and just a pad to jot down quick notes as we went through the proposed workflow. I did my usual: run her through the designs, tell her what to expect when she clicked where, jotted down her thoughts, analyzed her pauses and responses to “how does this make you feel?” questions.

Not surprisingly, being a power-user, she had quite a few technical questions that I did my best to answer and left the rest to my coworker. We all left the session feeling quite pleased.

Afterwards, my coworker was full of ideas and we shared a great discussion on how things might work and look. He talked about his experience with the rest of the team on many occasions about what he learned and felt that he had a better understanding of the people who use the tool. By letting him into my world, and him sharing a bit of his, we were able to create features that made our power-user incredibly pleased in the end.

“A critical piece in the UX Agile puzzle is that, on successful teams, developers respect UX people and their processes, and are willing to listen to their insights and ideas. But this state of facts comes only after working together in close proximity: UX professionals must earn developers’ trust by rigorously validating design ideas, improving them, and communicating that rigor to the rest of the team in an honest and approachable way.”

— Neilsen Norman Group (Agile is not Easy for UX)

There is a distinct difference between UX hard and soft skills, where hard skills are (but not limited to): executing user testing, designing wireframes, and research analysis. Soft skills include the ability to analyze why things should be a certain way, empathizing with user needs, and interpreting vague user requirements. When everyone involved understands the task at hand, what needs to be done, and how, it increases communication within the team. Better communication leads to a better team relationship which, in turn, leads to a better product because people are able to communicate more openly about what works and what does not

You may find that UX professionals naturally stop being needed simply for support when you practice the UX Conga Line and soon UX processes happily co-exist in the software development cycle. The customers and end users will be happier with a functional and usable tool.

Additional Reading:


Written by


Trained illustrator and professional UX Engineer with a passion for creating visceral web experiences.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade