At first glance, nailing down the requirements for a system’s user interface probably does not seem as daunting to a business analyst as handling the complexity of its backend operations or data flows. Once that functionality is well-defined, it should be relatively easy for a development team to build a user interface that will make it all work and reduce software project risk, right? Well, not exactly.

As this fantastic post explains, UI requirements are usually captured with a screen shot and, if the development team is lucky, a list of written requirements to accompany it. However, with this method it’s nearly impossible to ensure that you have captured everything; that’s why we use DAR models. (See this blog post for a great explanation and a visual example of what DAR models are; see this later post for a discussion of DAR model reusability.)

A project recently worked on has used DAR models extensively and untraditionally. Rather than using them only as guidance to the development team (which, by the way, is much better than not doing them at all), we’ve also found that DAR models are a helpful tool even at the beginning of a project.

There are a few reasons why it makes sense to use DAR models early in a project:

1. DAR models help elicit information from business users. By creating conceptual mockups of different screens early in a project and reviewing each piece of content on those screens with the business users, you can uncover valuable pieces of information. The people who will be using the application usually have the best perspective on what layout and page structure will be easiest for them and can provide meaningful feedback on the features you’ve included. Also, nearly all stakeholders, business and IT people alike, can understand a DAR model. Business stakeholders may shudder when looking at a complex data model, but they’ve all seen application screens before. The simplicity will allow even the least technical members of a project to participate meaningfully in the conversation.

2. DAR models are easy to iterate, if you use PowerPoint. If you are going to create screen mockups early in a project, you should expect them to change as you elicit information and receive feedback. But you don’t have to start over with completely new DAR models for each iteration. Using the “Slide Master” feature of PowerPoint, you can paste your screen mockup onto the Master slide. The mockup will then become the background for all slides in that presentation. Then you can put each DAR model on its own slide, using ovals (or boxes, or whatever) to highlight the piece of content that you’re discussing on that slide.

When the mockup changes, you only have to paste the new one into the Master slide, and the rest of the slides will update with the new mockup as the background. This method also provides built-in coverage assurance. You will probably have to adjust the position of the ovals to match the new mockup (for pieces of content that stayed the same) and create, delete, and revise your DAR models (for pieces of content that were deleted, added or whose functionality changed). But going through each piece of content systematically and making sure it has an updated DAR model can ensure that you’ve at least called out everything.

3. DAR models help identify hidden assumptions. The beauty of DAR models, as the aforementioned blog post explains well, lies in the level of detail that they can communicate. What’s in the details? The devil, for sure, but also an opportunity. By specifying exactly how each piece of content operates, even if it seems obvious (“a log in button will allow the user to log in,”) you will find that your team members may have had competing assumptions about how that piece of content might work. What will happen when you click that button? Will a modal pop up? Will it take them to a new screen? What will the button say if the user is already logged in? Probably not “Log in,” right? Should the button appear at the top of the page? On the right rail? On all pages, or just the homepage?

One DAR model can capture all of this and communicate it clearly to everyone. And if it turns out that these assumptions are not as clear-cut as you thought they were, aren’t you glad you’re finding out about these now, rather than later?

For some “how to guides” especially useful for business analysts, check these out:
https://seilevel.com/requirements-resources/how-to-guides/