There are a lot of things that are good for you – vegetables, a good night's sleep, fresh air, exercise. And there is something else that is good for you and your development team's health – User Experience.

Yes. I'm not kidding.

Sometimes people have the perception that the UX team just makes a site or application acceptable to users. We make it "pretty", "understandable", "easy to use", and sometimes, just "usable." But like everything, there is also a side effect of having a User Experience team – having clear product requirements.

Yes, you heard me right – clear product requirements.

When a development project is kicked-off, usually the business team will meet with the developers and brainstorm about what's possible. Sometimes at these initial stages, a UX person won't be involved (although that should happen, it often doesn't and that's the topic of a separate blog entry), and the conversations that take place during this early stage are often very abstract and grounded in a few whiteboard sketches. After a few sessions, everyone starts to feel like they have an understanding of what the product should generally do. The key words here are "generally do." I will almost guarantee you that each person in that room had a different idea of how that system should generally work (I've witnessed this too many times). The sketches that go up on the whiteboard keep diverging, words to describe functionality keep changing or represent a concept that works for the engineers, but the business team just keeps looking confused (or vice versa).

It all turns into chaos pretty quickly from there.

After another session or two like that, someone on the team finally says something like, "We should bring in a UX person so this application is usable." The UX professional is invited to the meeting, and maybe that UX person invites a visual designer and a copywriter. And if he doesn't invite those two sooner, he does later.

At the next concept meeting, the UX professional draws some sketches of what the application "could" be and facilitates  a group discussion where everyone is asking:

• "What does that do?"
• "Do we need that?"
• "Did we discuss this?"
• "Why would we do that?"

These are the right questions at the right time – it's early enough for the product to change course if needed and it's early enough to be sure that everyone is focused on talking about what this application SHOULD do. The engineers are getting clarity about what the business team wants; the business team is understanding what engineering is talking about; and everyone is understanding how a user could perceive the new product. It's times like this that I'll often sit back and smile, thinking, "Clarity is a wonderful thing!"

Sure, this product will go to usability testing and participants will give direct feedback; however, during this visualization process all teams will start to understand how this application will work in greater detail than those preliminary discussions.

Then, when the visual designer starts giving the application a look and feel, everyone understands how the app will work and get a more detailed understanding of what it will do. Those wireframe sketches don't always give a great visualization for how the pulldown may look, or how that layering effect discussed in early concept meetings will really work. After the comps are completed, and in some cases implemented, the team understands in greater detail what is missing (if anything at this point), what else is needed, and how it all flows together.

When the copywriter starts writing instructional copy and providing final labels, the team starts to realize that maybe some of the fields included aren't as straightforward as originally thought. Or the team realizes that the user needs a lot of direction to complete a task – so maybe the flow still needs to be simplified. Or the team realizes that honestly, no one really understands what a particular feature does – never did and probably never will. Maybe it's time to kill it?

The User Experience team is providing clarity about what the application is, what it does, and how it should work. Everyone on the larger team can address the details about specific features, referencing the visualizations, and encourage the UX team to create more prototypes and visualizations to be sure everyone is clear as to what's going on. The entire process gets the team communicating directly with each other and stops them from making assumptions about what may happen when the application is built. These conversations develop an emotionally healthy, functional team. I mean, who doesn't like a team that communicates directly about specifics?

I guess it is safe to assume, then, that including a User Experience Team in your development process helps your product in more ways than one. Not only does it bring in the users as an audience/stakeholder during the design process and testing, but it helps your development and business teams communicate clearly and be a more functional team.

It's a little like eating your vegetables. It's good for you.