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 specification is to detail out the rules behind a specific page. Sure, this is more “implementation” than “requirements” but the fact is when you are building a complex web application (and, I imagine, any complex application) 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?
I want to distinguish a few things here for clarity. First of all, I rarely dabble in the world of true user experience and user interface design. I’ve read a few books on the topic, such as Don’t Make Me Think. I can mock-up pages, create wire-frames, lay screens out in logical ways. I can facilitate reviews of these wireframes and bring to bear the best thinking of several stakeholders to create some decent UI prototypes. But I am no usability expert. And I don’t deal with colors and logos and other “fluffy” stuff. There are people who are really good at that. I love to work with them. I am not one of them.
Elements of a user interface specification template
In contrast to UI design, 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 spec 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.
I have to say, I’m a little nervous to put this idea out there. It’s not UML. It’s not in the BABOK. I’m sure it breaks a ton of rules about how to formally capture requirements. But, I’ve seen it work time and time again and I’m not going to stop using it until I find a better way.
Thank you for reading and consider subscribing to our RSS feed to get the latest posts on Bridging the Gap or subscribing to our free eNewsletter.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 13 comments… read them below or add one }
Laura,
If it makes you feel better, it actually IS in the BABOK under the Prototyping technique (a UI spec is essentially a paper prototype).
We didn’t spend a lot of time on it because UI specs really fall into the user experience area, and like product management, that’s something that has a lot of stuff in common with business analysis while being different enough that it’s difficult to address it intelligently in the same standard. However, if you look closely at how we define requirement, a UI spec can definitely qualify.
Thanks, Kevin. I suppose I should dig a bit deeper into my BABOK before making such comments. I see the UI spec as separate from the prototype, which I often do as well, and focusing on the rules behind the screens, not so much the layout and look-and-feel that a prototype presents.
In my experience UI designers focus more on the look and less on the rules. There is often analysis involved in ensuring the screens are implementable against the information model.
A good start, but for better way see use of Visualization, which takes it from static to dynamic
Great point, Mark. I typically don’t start with these documents, but do start with dynamic, click-through wire-frames to get user feedback.
This will hopefully sound obvious if it is not something you are consciously aware of, but the value of software is derived through the experience. The best requirements and the cleanest code sitting behind a poor user experience will result in a failed product.
It’s good that you are stepping up to do this work. It is extremely helpful and will point out issues that can be resolved conceptually long before extensive code is written. Wireframes are often the first activity that I will introduce to an organization new to user experience as significant benefit and time savings are quickly realized.
However, realize that you are doing much more than just dabbling in user experience, by authoring this document, you are defining it, whether or not you have formal training or extensive experience as a practitioner of User Experience. Whether it is a designer, BA, or engineer, someone will ‘design’ the user experience. The more skill that person has, the more effective that activity will be.
The fact that you relegate UX to graphic design demonstrates that you have not had the pleasure of working with an experienced Information Architect, Interaction Designer, Content Strategist, or User Researcher. There is much more to creating a positive experience than the visual treatment. It’s good that you call out that this exercise is not a replacement for proper user experience work.
As an aside, UX work doesn’t have to take months, see Jeff Patton for integrating UX and agile.
http://agileproductdesign.com/blog/
Good luck. There are lots of resources, both educational and talent, that can help your projects progress and succeed.
Hi Jeremy,
Thanks for your comment. It provides an interesting characterization of the roles. In your experience, does a UX professional provide these level of detail? I have to say, in my experience, the UX is left at a fairly high level and without something like a UI spec that integrates the intended experience on the front-end with the information model on the back-end and all of it married with the multiple possible paths the user can take through the system, the user experience is not truly realized in the final application.
Cheers,
Laura
P.S. I see how my words could be read to infer that UX = graphic design. Just want to let all you UX-ers out there I was referring to two components of the user interface, neither of which I have any claim to expertise in doing, only facilitating.
Laura,
I think you’re mistaken if you say you’re not a “usability” expert. Understanding the users motivation and mindset is the first step to usability and that sounds exactly like what you’re doing.
Building a simple set of core-metaphors for the system and facilitating a set of UI prototypes that reflect how they will use and interact with these metaphors means a lot more usability than the “fluffy” side.
Users engage with UI mock-ups more than any other sort of model – the fact that it’s not in UML or detailed in BABOK doesn’t really matter.
P.S. Balsamiq or Niklas Wolkerts Visio stencils that give things a hand drawn look to mockups are really fantastic – separate out the layout and interaction design from the graphic design portions.
http://www.guuui.com/issues/02_07.php
http://www.balsamiq.com/
Thanks for the insight to writing UI specs. I believe the BA should be giving direction to design.
How do you feel about including screen captures in the use case (as a reference)?
regards
Maureen
Hi Maureen, Thanks for your question. I have often used screen captures in use cases and I think that’s a great technique to capture the intent of the requirements when a full UI spec is not necessary. In cases where a use case references a screen detailed in a UI spec I put the screen capture in the UI spec instead and “extend” the use case to reference the UI spec (or just reference it at the right point in the flow).
Laura
Thanks for your comments, Harris. I defer the claim to expertise if for no other reason that it allows me to put some tentative ideas out there without having to be “right”!
But I do agree that thinking through the rules around how the UI flows drives usability (or it’s converse), whether you bring formal UX expertise to the activity or not.
Laura
Hi Laura
I just found your blog and the entry on UI specification. Maybe you like to visit my blog, too. We could share some thoughts as I already wrote several papers on UI specification practice and the according tools.
Thomas
I like your idea of a UI spec “calling” a use case. For me the user interface is a gray area shared between requirements and design. My preference is to leave design to designers and requirements to analysts, but in practice both must contribute for an application to be to successful. A good BA has at least some sense of what the user experience should be.
Interesting article! We have actually implemented some tools and techniques within our BA team (working in a great web consulting company) to integrate use cases to wireframes & prototypes (made using Axure). For more complex websites (e-commerce) and web applications, it leads to interesting results.
As for who should handle this wireframing task, I think that BAs are well positionned to capture client needs and prototype them. We work closely with the UX/design team for their feedback, but the BA is in charge of creating the UI (and the specs required to document business rules).