Problem solve Get help with specific problems with your technologies, process and projects.

Defining a User Interface (UI) during the requirements phase: A mistake?

Many teams are using the requirements phase to define the look and feel of the user interface (UI). According to an expert, this is a mistake and can cause the team to digress from its primary task of identifying true business requirements.

Should the User Interface be designed during the requirements phase?
A User Interface ( UI) is not a business requirement, which is what should be identified during the requirements phase, regardless of what type of methodology you are using in my opinion.

The UI is not even a product, system, or software requirement, which is what most people (mistakenly in my experience)...

think should be the subject of the requirements phase.

A UI is part of the physical product, system, or software design which details how the product, system, or software requirements will be implemented. Other parts of the physical design tend to be more technical, such as program and database specifications. Thus the physical design often is called the technical design.

In my opinion, regardless of the methodology being used, designing a UI is not appropriate while one is defining requirements. That said, designing a UI is one of the most common activities carried out in the name of requirements definitions. When folks think the UI design is a requirements definition deliverable, they almost certainly won't have accurate business requirements and probably won't have product/system/software requirements either. However, they are very likely to have creep.

For reasons that continue to confound me, even and often especially those who seem to know a lot about software development feel compelled to say something to the effect: Sure, that's well and good; but wouldn't a UI be helpful anyhow for defining requirements?

Let me reiterate. The product, system, and software you intend to create—including its UI—are NOT the user/customer/stakeholder's requirements.

Instead it's your presumed way of satisfying their requirements. Focusing on the UI, system use cases, prototypes, visualization, and other forms of product/system/software solution description in the name of requirements makes virtually it certain that the developers (which include analysts and testers as well as programmers) will not be paying sufficient attention to what is really needed.

In medicine, prescription prior to diagnosis is malpractice. The UI is a prescription; and thinking it will lead to proper diagnosis is misguided. The fact that many people believe it, including many supposed authorities, doesn't make it so. Just because most people believed the earth was flat prior to Columbus in 1492 didn't make it flat.

UI design has a role, as part of design, after the requirements are known accurately. The same is true for prototyping, which typically focuses on the GUI and shortcuts the guts. Requirements are mainly addressed in the guts, not in the GUI, which is why prototyping's value often is negligible for confirming, let alone defining, requirements.

Dig Deeper on Topics Archive