Article

Tech Tuesday: Responsive Acceptance Criteria

14 February 2017 | Robert Derbyshire | About a 9 minute read
Tags: acceptance criteria, Analysis, balsamiq, bootstrap, breakpoints, CSS, design, front end design, GitLab, gliffy, grid management, Mobile, mobile design, product analyst, responsive design, tablets


When writing acceptance criteria for screens which are expected to be responsive, what sort of information is useful to developers? How detailed do you need go? What information is unnecessary or even confusing? We asked some front-end developers, and got some tips and examples of good, responsive acceptance criteria.

What is Responsive Design?

Responsiveness is a browser-based design approach, whereby the layout and content of a page are adjusted according to the dimensions of the window they are displayed in. Although a browser can be any size, users will generally be viewing a browser to fill the screen of a mobile device, tablet or desktop. Responsiveness allows a single page to cater to a variety of sizes and therefore devices, removing the need to have separate pages, or even sites catered to specific devices.

How is Responsive Design best implemented?

Some of the best implementations of responsive design are implemented with a mobile first approach, and actually look better on mobile than desktop. In this approach, the mobile screens are the first designed and created, before even even considering what the desktop will look like. After the mobile version is done, the tablet and desktop screens can easily be created by increasing the screen size and making adjustments. It is a lot easier to go from mobile to desktop than the other way around, where not everything will fit.

  • Done well: GitLab.
  • Not done well at all: Evans & Peels. Note: this bar website was made to look like a detective agency website, and the desktop version is really cool, but the mobile version struggles because they tried to fit everything on a small screen and is fairly unusable. You can’t book or view any cocktails.

Very thorough testing is needed, sometimes on all devices, because every device has a different viewport. For instance, you could get caught out a lot when you first learn about Android devices, as they have different tablet resolutions than iPads. Always test your implementation and keep the mindset that your code should be available on any viewport.

Without any further ado, here are our tips:

Tip 1. Understand your CSS Framework.

Grab a front-end developer and ask them to talk you through it. It may have been custom built, or picked up off the shelf, like Bootstrap. Regardless, the UI will be structured in rows and columns, which all components will fit within. It will take care of things like margins, so you don’t have to mention them in the acceptance criteria. Otherwise, you end up repeating acceptance criteria for each user story, so the developers may miss the real requirements amongst all that fluff.

This image is a graphical representation of Bootstrap’s default 12 columns, which all assets will sit within.

responsive1

Tip 2. Write Acceptance Criteria about Breakpoints, not Devices

Acceptance criteria should not be created with specific devices in mind, e.g. iPhone 6, Samsung Galaxy Tab etc. This is an unscalable approach given that hundreds of devices are in use and coming out all the time. Instead, refer to break points, to ensure that all devices can be supported now and in the future.

Tip 3. Write Different Acceptance Criteria for each Breakpoint

Breakpoints are the dimensions at which you want to apply a different design, and this generally relates to the width of your screen, as your browser is resized or you browse on a desktop / tablet / mobile device. If your site has been developed for some time, find out what the break points are and write acceptance criteria to these. If this is a brand new site, you will have to set up breakpoints. Use your analytics tool to find out what devices your users are using the most, and adjust the breakpoints as appropriate. Typical breakpoints are as follows:

  • > 1280px: desktop
  • > 1024px: tablet landscape (optional)
  • > 768px: tablet portrait
  • < 320px: mobile

For any aspect of your functionality which behaves differently based on whether before or after a break point, write a separate acceptance criteria point for this so that it can be tested later. Also, write in terms of “screens below the mobile breakpoint” rather than “when browsing on mobile”, because the user could just be browsing on a small screen on a desktop, not on a mobile device.

The following examples show different ways responsive breakpoints can be used to alter the look and content of a page

Example 1: Show/Hide Navigation

We will have a simple page with a title, some text and a navigation bar to the left. This navigation bar should move into a burger menu when viewing in a screen in tablet portrait size or below.

Scenario 1: Tablet Landscape and Desktop Navigation

GIVEN that I am accessing example.com with a screen size at the tablet landscape breakpoint or above (> 1024px)

WHEN the page is loaded

THEN the navigation bar should be shown to the left of the content and the contents to the right of that

Scenario 2: Mobile and Tablet Portrait and Navigation

GIVEN that I am accessing example.com with a screen size below the tablet landscape breakpoint (< 1024px)

WHEN the page is loaded

THEN the burger menu should be shown, the navigation bar hidden and the text filling the page up to the margins.

 

response2

Example 2: grid (columns) management

We want to display a number of articles, for something like a blog, or a news site. Taking a mobile first approach, articles will be displayed in a single column. As the viewport increases, additional articles will be displayed in extra columns.

Scenario 1: Desktop has 4 articles per row

GIVEN that I’m browsing example.com from a screen size bigger or equal then 980px,

WHEN I get to the articles section,

THEN I want to see four articles on a row

Scenario 2: Tablet has 2 articles per row

GIVEN that I’m browsing example.com from a screen size between 768px and 979px,

WHEN I get to the articles section,

THEN I want to see two articles on a row

Scenario 3: Tablet has 1 article per row

GIVEN that I’m browsing example.com from a screen size smaller or equal 767px,

WHEN I get to the articles section,

THEN I want to see one article on a row

 

response3

 

Example 3: Component functionalities (device based)

When you need to change how functions work based on whether you have a touch device or mouse device.

Scenario 1: Non-touch devices

GIVEN that I’m browsing example.com from a non-touch device,

WHEN I mouse hover on the “?” icon,

THEN a tooltip with some text should be displayed

Scenario 2: Touch devices

GIVEN that I’m browsing example.com from a touch device,

WHEN I tap on the “?” icon,

THEN a tooltip with some text should be displayed

Example 4: Change element size

Sticking to our policy of using relative sizes, when setting the size of an image, it doesn’t always make sense for it to be proportional on every viewport. On a small device, an image that is 50% the width of the screen is still quite small, where as on a desktop it could be huge, so in this example we’re setting an image width on mobile to 50% and on desktop to 25%

GIVEN that I am browsing example.com,

WHEN browsing the site on a browser size under 768px,

THEN I want the logo image in the header 25% of the width of the screen

GIVEN that I am browsing example.com,

WHEN browsing the site on a browser size over 768px,

THEN I want the logo image in the header 50% of the width of the screen

reponse4

 

Tip 4. Use relative sizes wherever possible

Where possible, avoid absolute sizes like pixels. Instead, use percentages. This prevents the div, object or image from exceeding its container when the page is resized.

Tip 5. Add a max-size to your largest breakpoint

With a lot of TVs now being internet capable, there’s a good chance your site could be displayed on a very high resolution screen. Adding a max-width will ensure that layout is capped and doesn’t break when it gets too wide.

Zeplin gives developers all sizing, margin, text size, colour etc details. As such, it may not be necessary to specify these in the acceptance criteria.

 

zeplin-1 zeplin-2

 

 


Summing up…

I hope this post has been helpful in providing tips on things to avoid and examples of excellent acceptance criteria to be included in stories. If you have any questions or other examples of good AC, please feel free to post them in the comments. Otherwise, happy writing!

Read More From This Author

Share this blog post

Related Articles

Careers

We’re looking for bright, dynamic people to join our team!

Discover More Roles