Refresh: cause and effect of a designer’s seemingly simple decision

 

The JIRA story was written to allow the user a manual refresh process for each real estate area of the home / landing page of the mobile application.  The story was written from the perspective that the user could be in control of what content they wanted to re-fresh without having to run a full content refresh for the entire page. In theory this would reduce the user’s data usage by allowing them more control over what and when they download new content.

As the JIRA story progressed through the sprint, User Experience made the decision to reduce visual clutter on the page by reducing the number of manual refresh CTAs.  The decision, however was made without discussing the ramifications of the desired change with the larger team.

A user hitting refresh two or three times over the course of their visit will push up the API counter exponentially fast. If the user did this several times per day costs could quickly escalate.

Working with the business, the BA, UX and design, the happy place was found to be a single manual refresh button that would refresh all the content in each of the respective areas of the home / landing page, however in the background, the weather API will have coded logic to limit the number of times the external call will be made (and therefore incrementing the API counter) to once within a 60 minute window.

The lesson learned is that a seemingly simple decision to deviate from the story could lead to huge costs for the business; everyone must work collectively and harmoniously to make sound decisions together that benefit the user and the business while being supported by development and technology teams.