A long, long time ago while working on a web-based product, a colleague of mine came up with this idea of writing a user interface or screen specification. The purpose of this requirements specification is to detail out the rules behind a specific page. Sure, this type of document can become “implementation” than “requirements” but the fact is when you are building a complex software application (and that includes web-based applications) the way a specific page is laid out and, just as important, what data elements belong where, is very important.
Why Specify User Interface Requirements?
Think about the home page of your company’s website or your LinkedIn home page. Complex pages that display massive amounts of information in intelligible ways don’t just create themselves. They are products of intentional design and careful analysis.
- As a BA, do you tend to leave these “design” elements to your development team to flesh out?
- How much churn is that creating during implementation?
- Would you be interested in exploring a better way to capture these rules, without over-stepping your role as a business analyst?
Elements of a User Interface Specification Template
A UI specification defines the rules of engagement for a user interacting with a specific page on a website or screen within an application. A UI specification can have the following elements, take or leave a few depending on the situation:
- Visual overview of the screen. Break the screen up into sections. This will help organize your document. You can do this in Word with a few text boxes. Label each section and include a “section” in your document for it.
- Within each section, look for the display rules. For example, on a search results page, how are items sorted? What fields are displayed? What if a particular field is missing?
- Consider messaging. Do you want to display specific messages in specific conditions? If so, what are they?
- Evaluate the links. Is it obvious what pages each link should be directed to? If not, specify it.
Good UI specifications take into account the data and context of the user within the application. This sort of requirement specification does not replace UI design, but it does help you lead your team through thinking through the UI design and how users will actually experience information within it.
Fitting the UI Specification Into Your Requirements Model
There’s an obvious blend here between functional requirements and non-functional ones. Sometimes a few functionality requirements make their way into your screen specs. I try not to worry about this to much. But if you find yourself writing out a bunch of “if then” statements, then you are probably trying to use a UI specification to substitute for a use case or other functional spec, and you might consider breaking it out and simply “calling” that use case within the screen spec.
And on a final note, not every screen needs a UI specification, only the more complex screens. The intent is to reduce ambiguity and drive alignment around complex rules. For a simple screen with a few rules, these rules might be best captured in the special requirements section of a use case or in a separate business rules document.
>>Don’t Start From Scratch
If you’d like to create these types of user interface specifications on your next project, I’ve made an fully annotated version of my UI specification template available (along with a host of other useful and practical templates) in the Business Analyst Template Toolkit. The toolkit includes 11 additional templates covering common BA documents, each accompanied with a work sample too.