Should User Interface (UI) Be a Part of “Requirements”?
By Michael Shrivathsan on Nov 20, 2009 in Product Management, Requirements Management Basics, User Experience
Just a quick post to address a question that seems to come up quite frequently.
Should “User Interface” (UI) be a part of requirements? Do UI specs constitute requirements?
Here is my quick answer to this question…
Does “UI” Meet the Definition of a Requirement?
Here is the definition of a requirement from my earlier post:
A requirement is a capability that a product must possess or something a product must do in order to ultimately satisfy a customer need.
In my opinion, User Interface (UI) is without a doubt a capability that a product possesses. As a matter of fact, it might be one of the most important capabilities a product possesses.
As a result - I strongly believe that UI should be an integral part of the requirements.
A lot of software companies tend to build their apps first, then slap on a UI. In this model, UI is usually not a part of the requirements specifications. However, this model is quite flawed and leads to apps that are extremely hard-to-use.
A far better approach is start with UI specs from day-1 and make them an integral part of your requirements. By the way, this is how we do it at Accompa.
What are your thoughts on this? Chime in here…
1. Steve Johnson | Nov 21, 2009 | Reply
Alas, I must disagree. User interface is HOW, not WHAT. You wrote “something a product must do” and nobody wants to DO a user interface. Alas, many product managers put UI in requirements since to show their developers HOW to accomplish a requirement but t hat doesn’t make it right. UI belongs in a specification, the HOW document.
UI describes the ideal way to interact with the product but the requirement isn’t to interact with the product; the requirement is to address a task or solve a problem.
For more on requirements, see my article at http://www.pragmaticmarketing.com/publications/topics/09/on-reqs-and-specs/
2. John Westerveld | Nov 22, 2009 | Reply
I must agree with Steve on this. When I write requirements, my focus is on what the product must do. The specifications describe the how. In my case, however, we are fortunate to have an excellent UI designer who’s job is to focus on how something is done and she writes the specs.
I’m curious to know what companies do when they don’t have a UI specialist? Our developers are excellent, but they often see things from a developer’s perspective rather than a from a users.
3. Travis Jensen | Nov 22, 2009 | Reply
I think John’s question is extremely pertinent to this conversation. I agree with Steve that UI is part of the specification, but I’ve had very bad luck leaving UI to developers (as opposed to UX designers). In those situations, I’ve pulled UI back into the requirements. I’m not a UX expert, but I at least have an understanding of the problems the customer is trying to solve and I’m not neck-deep in the code.
4. Michael Shrivathsan | Nov 23, 2009 | Reply
Steve - Good comment and article. I think PMs should specify the HOW as well - at most companies, they’d do so together with UI designers as John pointed out. But, I don’t think PMs should just specify the WHAT and then wash their hands off it. We’re probably saying the same thing, but at many companies PMs specify the WHAT and then don’t care much about the HOW. The end result being products with extremely poor UI.
John - Excellent question about companies that don’t have a UI designer. In these cases PMs should step up - if not, the products will be poor from UI perspective. I believe UI is the most important part of a product - it’s the only thing users see and interact with.
Travis - Excellent point, I agree.
5. Pete | Nov 23, 2009 | Reply
A lot of Scrum preaches min spec requirements which can in turn lead to less focus from a UI perspective. As a PM I find I need to account for this by making the UI requirements to keep them in consideration for the min spec.
Our industry users are much more likely to adopt something that is easy to use and looks good so the success of a feature is very much dependent upon the UI. To me that justifies making it a requirement. Without it, the feature may not succeed.
6. Jeff Kim | Dec 7, 2009 | Reply
While I agree that UI should be handled by UXD pros during the Design phase, I frequently include draft UI in my PRDs. It helps me to convey the WHAT of my requirements, much better than a user scenario can. However, I clearly communicate to the UXD designers that the UI belongs to them and that my drafts are just to better communicate requirements.
7. Rian | Jan 1, 2010 | Reply
I am for a hybrid approach of what many of you are saying. I agree with Steve that it is important to differentiate between Requirements, Functional specifications, and Technical specifications.
I believe that PM’s should lead the Requirements and Functional specifications phases. UX design happens during Functional specifications (and engineering input on the UI during Functional specifications is essential). Engineering should lead Technical specifications (with input from PM).