In support of streamlining future projects, I developed a series of task flows that would be common to all future applications. The flows included email registration, verification, personal information, business information, and payment. The flows were developed for desktop, tablet and mobile.
Equifax has produced a wide range of products over the years. However the appearance of the products has differed from product to product. To align the look and feel of new and updated products, a design system was introduced. The system included the the grid, navigation, components, and visual design as well as a code base. This increased the efficiency of the design team, as well as developers. To further this efficiency, I designed a series of task flows that could be applied to user tasks common across products.
The first step was to identify the most common task flows across multiple products. This included current products, and any future products.
The service blueprint identifies the touch-points where customers interact with the business when using a product. This provides insight into how our products are designed and function, as well as the operating procedure and requirements of the business. For example, users may be required to leave an application at some point and email or phone the business for support or other reasons by design.
I interviewed product owners to identify any products that will be updated over the next 12 months. These were generally products important to the business that had either a high or decreasing customer user base. I also asked about common features across products.
I also interviewed the operations support team to get an understanding of issues users were having with our products, and where these issues might be. These issues could possibly be addressed in the new designs. Without direct access to customers, this was the next best source of evidence.
By using a scenario template I had created earlier for Equifax, I gathered information on the characteristics of the users for each of the products identified. I also elicited scenarios user stories from the product owners from which I would be able to derive use cases later.
By using a range of products, I methodologically recorded the common task flows across products, and the screens, features and functions within the flows. I cross referenced these findings with the service blueprint to ensure I had a thorough understanding of the touch-points. I then reviewed the pain-points identified by the operations support team and mapped these against the flows to identify where the issues lay.
From the information gathered, I created requirements aligned to the future state of each of the task flows. From the requirements, I deduced features and functions required. These were aligned to use cases which would form the basis of the new task flows.
Function to flow mapping
With reference to the use cases and functions, I first wrote out the screens I thought matched each flow in question. This activity relies on the holistic knowledge of the designer, but serves to identify any features that may have been missed, as well as informs the designer of the structure of the flows to be designed.
Lo fidelity screens
Although a design system had just been created, it was incomplete. I wanted to ensure the layout of the components on the screen was optimal, as well as the user experience from screen to screen. To test this, I opted to design first in lo-fidelity. This prevented the test users from assuming this was the final design, and allowed for free-er expression of opinions from the users.
I used the following methods to test the lo-fidelity designs.
5 second test
The 5 second test is used to quickly get users first impressions e.g. check if users can appreciate the layout.
First click testing
First click testing is used to check if users are able to easily identify any particular required actions.
Prototyping is used to check users ability to use the product.
Hi fidelity screens
I used the design system to design the hi fidelity screens. Where design patterns required were not in the design system, I kept true to the original design and sought solutions such as combining existing component designs rather than create new ones e.g. a horizontal scroll bar was not in the design system, however I used the vertical scroll bar and turned it horizontal, then placed it in a table to allow a table to be scrolled where it has large amounts of content.
Review with stakeholders
I presented the screens to senior stakeholders for final sign-off. In doing so I walked the stakeholders through the designs to ensure they understood the flows from both an aesthetic and functional perspective.
Delivery to developers
The screens were delivered to developers via the original XD file. This allowed developers to quickly identify spacing and padding.A table was created with rows for:
- user story (trigger, activity, goal)
- screen name
- screen purpose
- functionality on the screen
- mobile screens
- tablet screens, and
- desktop screens.
By providing the above information, developers are able to clearly see the purpose of the task-flow and the features and functionality of each screen.
By designing generic task flows for the most common actions of applications, the UX team was able to spend less time on common functionality, and more time on designing an optimal experience for unique attributes. This streamlines efficiencies within the business, and contributes to a greater customer experience, retention, and business reputation.