MBT Blog Series: Tips and Tricks for UI Modeling

by January 19, 2018

UI modeling 101

One of the most common requirements modeling exercise involves the User Interface (UI). In particular, UI modeling is one that is designed to describe or test the functionality of the UI. Arguably, almost all companies, even individuals have a ‘front-end UI’. This is place where a user will interact the most with a product and it is vital that it behaves as intended.

Within this blog, I will describe a reliable method to follow when embarking on doing functional UI modeling.

Deciding on your level of abstraction

One of the key skills to gain when you’re doing UI modeling or modeling any system for that matter is to decide on your level of abstraction. Try to model too much and you will be left with an illegible, tangled mess. Try to model too little and the requirement won’t contain enough information or worse, incorrect.

UI modeling skill is even more prevalent due to the large number of actions that can happen at any given time. Take for example an e-commerce store, http://demo.nopcommerce.com. When a user lands on the homepage there are over 50 actions that can take place: clicking links, entering text to search or taking part in a poll. Several business processes can also occur from this point including logging in, registering a new user or searching for a product to buy.

Of course, one could attempt to do UI modeling by creating flows within a single UI model, however, this would result in an extremely complex model.


Models are supposed to convey complex information in clear, unambiguous and simple fashion. Remember, 56% of defects can be traced back to inconsistent requirements. The simpler the model the better.

Another downside of complex models are the numbers of test cases that will be generated. If we estimate that there are on average 30 actions on a web page which can either link to another page or leave you on the same page. Then, the approximate number of possible paths for a user doing just 10 actions on the website would be 3010. That is a potential 600 million million test cases that could be generated. If each test were to take one second to complete then we would need around 18 million years to test everything. That is roughly the same time we’ve been evolving from our great ape ancestor – and we’re still monkeying around with testing!

How can we approach such a large problem? Before we even start talking about optimisations, we need to reduce the scope of the model. The easiest way to do this is to design only the one business process at a time. Or, if the model becomes too complex break it down into separate components.

For instance, one business process for a commerce site would be to register a new user. This is an extremely simple process but each part could include more detail. Here the process from landing on the homepage. Clearly, this model is at a very high level of abstraction. To add more detail, we will need to model the registration page.

UI Modeling

Create a happy path

A registration screen is quite a common with UI’s, with forms being found in almost any site.


But where to start?

We’ve all stared at a blank page waiting or inspiration to strike, “Modeller’s Block” is not uncommon either. Thinking of what you want to design and how to do it can leave you stuck.

We can visualise the process by creating a happy path of our business process. Below is part of the happy path for registering a user from the registration screen.


Once we have a happy path we can decide whether the level of abstraction we have chosen is too big or too small. In total, there are 10 elements to interact with. If we had decided to use any more, like the links within the headers, then this would have become possibly too complex. Around 10-15 elements in generally the maximum you would have for one model.

Adding business logic to a requirement

Once we have an understanding of the scope of our model in our UI modeling exercise, it is easy to flesh out the details.

The requirement for the registration form “A user enters their details in the form. If all the details are valid then the user is registered on the website otherwise, they are not registered. If it any point a user enters invalid details an error will be shown.”

For any element, we can have an invalid or valid outcome. Let’s take a text field, the first name field for an example. You can either send text to it or just leave it empty. Whether either of these is valid depends on whether the field is mandatory or not. This is summarised in the table below.


A logic table is a great way of detailing business logic as it starts to visualise the options in a digestible manner. Modeling is an evolution of this concept and so, we can easily add this logic to the model.

First, create a decision block with the interaction types that can happen and any process blocks for errors that could occur. If an interaction is invalid then link it to the next error block or, if the interaction is valid link it to the next element in the form.


Next, we can repeat this for every element that we need to interact with inside the UI. By doing this for the whole business process we have now created a functional flow to represent it!

Finally, we need to make sure that for any error we don’t register a user. There are several ways that you can do this depending on the tool you are using.

How to do this in CA Agile Requirements Designer can be found here and here.

Creating end-to-end tests

Once we have created a flow, we can link it with others to create end-to-end tests. This a crucial part to model based testing. If the complexity of one area was too large you can combine separate models to create larger business process or models. This is extremely important because it allows complex information to be stored within the requirement without compromising the simplicity of the model.

We can combine flows in this manner by using subflows. Sublfows use the end points from the flow they represent as outputs. Below, you can see the updated high-level business process which now contains two possible results, registering a user or not.

Flowcharting visual

Moreover, we can now reuse the model in other processes. In doing this, we are not only saving time but are now able to react to changes in requirements quickly. If a change to register user requirement occurs we can see what test cases are impacted and identify what areas will needed be tested, providing valuable information to all stakeholders.

Check with stakeholders

The last thing to do with your model is share it. No matter who is creating a model BA’s, Testers, Developers, or Product Owners it is vital that is discussed with other stakeholders. Models will naturally highlight ambiguities in thoughts between anyone involved in the process.

This means that by sharing models early, defects will be caught quickly as ambiguities in the requirements can be ironed out before reaching later stages. An easy way start shifting left.

What next?

Like any good artist, you should never be satisfied with your work. There is always more you can add to a model:  add test data at the block level to automatically generate or profile the correct data for tests as they are generated; apply more detail to each block to create usable manual test cases and insert snippets of automation into a model to create automated scripts at the click of a button.

CA offers comprehensive solutions that automates the most difficult testing activities – from requirements engineering through test design automation and optimization. Start your Free Trial of CA Agile Requirements Designer today and fast track your testing at the speed of agile.