Earlier this week I took part in an interesting conversation about how much UI design should a requirement document (to use the generic term) contain. I’ve seen this same discussion pop up before, both in projects that I took part in and also from other people’s reports, so it appears to be a common discussion amongst people who do any form of agile software development. I thought I’d share my thoughts on the issue by describing the ideas that go on at the two extremes, from the point of view of the Product Manager or Product Owner writing these documents.

Requirement documents should have no UI at all

Non-designers should only convey ideas, not implementations, to designers. Hence, tools like Balsamiq Mockups and many others make your mockups look like they are temporary on purpose, so it’s clear they are temporary drafts that can be thrown away if something better comes up. There is no investment in making them look good or professional so that change is as painless as possible. Product Managers should be concerned with not “leading” the designer towards a solution but rather suggest what needs to be solved.

Requirement documents should include all the UI needed

Product people are the best people to suggest solutions for their products since they are the ones who are most familiar with the problems being solved and the product’s vision and therefore are capable of making the most informed recommendations. Detailed prototypes can be built because by the time a designer gets involved the final UI solutions are known and their job is just to polish things up and get them ready to be implemented as code.

Clearly these are conflicting points of view. However, I think they can both be used effectively – it will all depend on your team and what your work process looks like. The first approach can work really well when you have experienced UI designers who are an integral part of your team and are very close to your product’s vision, whihc means that making design decisions based on abstract input is easier. The second can also work well when you have a product team that has experience with UI design and in cases where dedicated UI designers are either not available as part of your team (ie are contractors) or have very limited availability.

The benefits of having a UI/UX designer as part of your team at all stages is enormous, so the first approach is desirable whenever possible. In real life, though, you can’t always get what you want, so we need to figure out what’s best for each specific scenario.

Have you ever tried either of these approaches? Or perhaps you treat UI on a different way within your requirement docs? Reach out on twitter or Google+, let’s discuss!