Since the advent of the software industry, User Interface (UI) has been an afterthought – for the most part. UI is something the teams building the software slapped on the software at the end of a project.
Kinda like a coat of paint after the house was built! 🙂
The conventional wisdom (especially in B2B software) was that customers did not buy the software for the UI, they bought it for the functionality.
From this piece of conventional wisdom, another one followed: UI should *NOT* be a part of requirements. Rather, UI is something added after the requirements (use cases or functional requirements) were defined.
Is this still true? Read on for the answer…
User Interface in the Cloud Era
As you know, companies are embracing cloud software for more and more of their business needs.
Perhaps the biggest benefit provided by cloud software is: “Ease of implementation.” Everyone recognizes this. A much less heralded – but equally important – benefit is: “Ease of use.”
Ease of use: How intuitive do the users find the software for performing their day-to-day tasks?
While many factors contribute to “Ease of use” – I believe the primary factor is the UI.
Should User Interface (UI) Be Part of Requirements?
As a result, I believe the UI should indeed be an integral part of requirements – rather than something that is slapped on after the requirements are defined.
In summary:
Cloud software has made the UI a much more important element of the software. As a result, UI should be an integral part of requirements definition process.
Are you wondering “Hey Michael, what stage of the requirements definition process should we write the UI specifications?” Great question – in fact, that is the topic of my next post!
Until then, to your success…
