What are the risks involved when setting up an internal UX team?

Usability teams are a beast that has to be stopped.

OK, not always. It’s not that bad. But still, here we go with some consequences from the experiences of our team. We wish we knew about these problems before.

1. Lack of features to test

Developers can’t produce features so quickly. A usability team might find itself idling.
A quick usability test takes up to a week from recruitment to preparing a report. It’s fast.
In contrast, a scrum sprint usually takes two weeks, and not all sprints result in features big enough to test. Sometimes we make small enhancements or features that have no UI.
Times vary: there are longer usability tests (for example, performance testing requires many more participants than our usual group of 3–5 people). There are shorter sprints (for example, some new teams have one-week sprints), but still, there’s an apparent disjunction: -criticizing is easy- usability is faster than development.

2. Too many usability bugs

Developers can’t fix them so quickly, and the backlog grows. Future testing doesn’t make much sense.
Everybody likes usability bugs that are easy to fix: changing text or making a button bigger. On the other hand, it’s painful to see when a feature is fucked up entirely: people don’t understand why it’s needed in the first place, which is the case with our Pedro.
It takes a brainstorm to invent a fix, but it may take a sprint of multiple developers to implement it. Broken schedules, rewriting the code again and again, and making difficult choices — the team might remind you of a married couple in crisis.

Other Problems

Something of less importance, but still it’s something that we didn’t expect:

1. Recruiting is difficult and expensive

It’s more difficult and more expensive than we were supposed to. We’re making professional software, so we need professional designers and front-end developers. Apparently, we faced a hard choice of either recruiting somebody we didn’t plan on involving initially:

• beginners in the profession
• or people who already know our product

2. It’s more iterative than we thought

• Usability testing generates a loop:
• Testing finds problems
• Fixing generates new UI
• Leading to more testing
• Generating new UI
• Leading to more testing
• Generating new UI
• Leading to more testing
• Generating new UI

3. The final UI can be overworked

I think a great example is Ethnio; we use it for recruiting participants. For each button, there are 3 alternative buttons, so the interface became bulky and difficult to comprehend.

Conclusion.

No matter how problematic it may be to keep your own UX team, it has many benefits, one of which is direct communication with your audience. Some small problems may reveal some bigger ones and definitely impact the way you develop new features. You don’t have to run interviews every week or so, but outsourcing or part-time scheduled studies is always better than nothing.

Also, usability studies can be quite fun. Check out Don’t Listen to Users and 4 Other Myths About Usability Testing

Another example of how usability studies and user feedback benefited one independent developer is Design Without a Designer. One Developer’s True Story

---

About the Author
Ivan Boyko is the founder of Icons8. He got his first job after drawing a banner with a CTR of 43%. After years of creating icons, he specializes in rapid prototyping and backlog grooming.