In my last blog post, I discussed why the User Interface (UI) specifications should be an integral part of requirements.
If you agree (fully or partially) with my take on this, the next question to consider is as follows: At what stage of the requirements management process should we write the UI specifications?
My answer for this is surprisingly simple, yet difficult to implement in most projects. But that is not bad news.
What is the answer, and why is it not bad news? Read on…
When Should You Write User Interface (UI) Specifications
The “surprisingly simple” answer I promised is:
As early in the requirements definition process as possible.
Why do I say this?
As I mentioned in my previous post, cloud software has elevated the importance of UI. Rightfully so.
This means, in most industries, having a better (more learnable & usable) UI is a huge competitive advantage. In our own industry, one of the top reasons Accompa beats competitors is having an easier-to-learn and easier-to-use UI (based on customer surveys).
As the UI is becoming critically important, it makes total sense to start writing your UI specifications as early in your requirements management process as you can.
Is There Such a Thing As “Too Early?”
Theoretically, the answer is “Yes.” We shouldn’t start UI specs work until after we complete requirements gathering (aka elicitation).
In practice, the answer is “No.” At most companies, UI specs work is started too late – not too early.
Ideally, you should start UI work when you start writing Use Cases. In this scenario, you will flesh out use cases and UI in parallel.
Unfortunately – or perhaps fortunately? 😉 – the world is not ideal. As a result, you should strive to start UI work as early as you possibly can. Odds are, your company starts it too late.
Try to move it up a little bit earlier. Keep moving it up earlier & earlier – until, someday, you get to the ideal scenario.
To your success…
