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.
Like This Post? Get More by Email
3) Do not read this blog one sentence per day during your lunch break, while eating a
A functional requirement arises in the domain being automated, so it isn’t about software at all. It’s about doing work.
A feature exists across a network of view elements, model elements, and control elements. A feature exists in the API as well as the UI. A feature is more than its UI.
If a product manager is going to specify a UI, are they going to specify an API as well? No.
The various team members contributing to a product make decisions. That’s what they are paid for. In a product, those decisions must be consistent. Those decisions are made within the context of the line organizations as well. A product manager leads best when all the contributors are making decisions and moving the ball where it needs to go.
The constraints on where that ball goes are not owned by the product manager. They can be moved by the product manager, but not arbitrarily. It takes consultation. It takes constant communications. It takes context. It is more than a document.
A requirements document isn’t the only or last word.
It’s far easier to communicate amongst your stakeholders if you consider basic UI design as the first tangible step in communicating your understanding of the requirements.
Critically it’ll enable you to validate your understanding of the requirements with the often unrecognised “silent” stakeholder, the customer/ end user. Then you can proceed into your requirements documentation / implementation process with confidence that the product you’re describing will be useful and comprehensible.
NB. This is not BUFD, just prudent risk reduction.
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).
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.
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.
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.
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.
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.
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/