.png?width=400&height=79&name=SilverLogic_LOGO_TAGLINE_Vect%20(1).png "SilverLogic_LOGO_2018.png"){kind=logo}
What are User Flows?
As a popular component of the agile software development cycle, user stories help to articulate what value a product feature can bring to users and to understand why users want a particular feature.
User Flows can be described as a user-centric tool that helps the product manager and development team shift their focus from writing about the features of the software to discussing the value the users will receive from them. (GatherContent.com, Dec. 2021)
User flows, in UX Design, are visual or written representations of the many paths a user can take when using an app or web page. From the user's point of view, it depicts the workflow or procedure. User Flows depicts the task as a visual with blocks connected by arrows in its most basic form. The diagram, like the tasks in the program, does not have to be linear. It might contain several pathways, loops, and other features.
User Flows come in a variety of shapes and sizes but the 2 most popular are Task flow and Wire Flow/UI Flow:
Task Flow
A Task Flow is a User Flow that focuses on the user's single task. The whole solution flow is not depicted.
Wire Flow/UI Flow
Wireflows are a form of deliverable that incorporates both wireframes and User Flows. Wireframes are used instead of raw blocks. As a result, the team and stakeholders can rapidly visualize how the application will interact. Wire Flows with high-fidelity mockups are called UI flows. (uxmisfit.com, 2020)
But, for the purposes of story-writing, a set of bullet points in chronological order seem to be effective in documenting the sequence of steps a story should take from the beginning to the objective of the story.
As user stories primarily serve to guide developers during implementation and to communicate with stakeholders what developers are doing, it is important to describe both the value the work will bring to the user and the “hard” acceptance criteria associated with the story. Software development agencies in particular must pay attention to both aspects as the agency-client relationship may sometimes drift a bit more in the “contract negotiation” direction than the “customer collaboration” direction.
Using a User Flow to Draft User Stories
Some user stories may be written without a flow outline. For example, when actions are very simple don’t have to be performed in a specific order. However, most things follow some sort of sequence, and a suggested sequence might be helpful for both the development team and future users.
When preparing stories based on a user flow, make sure each step is clear, in the first person, and in an order that clearly delineates the steps the user should take towards attaining their goal.
In the example below, each bullet point or set of bullet points in a list can be fleshed out and translated into a user story, and can also be used to specify what is expected for a story to be considered done.
Let’s prepare the first story by rolling the first two steps of the flow into one user story:
Here, we rolled two steps in the flow into one story.
Step 3 seems like a candidate for this user story:
What if a User Story is Too Large?
I enter shipping and payment information before confirming an order
Perhaps after a team meeting, the team determines this step in the user flow is quite complex in practice and would be better served by being split into multiple stories. A simple heuristic is to split wherever you read an “and”.
In this case, the user story mentions shipping and payment information; these items could be split and would look something like this:
There are many strategies a team can use to split stories, and some stories may have to be split or reworked multiple times before they are accepted by the client and development team.
Story Splitting: Further Reading
Carefully Written User Stories Save Time
Carefully written user stories can save you time. They can be reprioritized, added between other user stories, and can remain in the backlog if they remain a low priority. The user stories and their associated acceptance criteria are always there to be discussed, refined, and worked on at a later date.
Additionally, a review of finished work can be used to adjust the scope of the feature user stories through progressive refinement. For instance, the credit card info may end up being inconvenient for your customers given how your app and business work, you may decide that you want to use PayPal instead of taking Credit Cards directly.
Reviewing Acceptance Criteria
While user stories help focus the software development team on the value to the user, the acceptance criteria guide the conversation and implementation so the team won't forget about specific details or rules that need to be considered. The acceptance criteria help the team define scenarios and how the final product will behave so the team doesn’t have to go back and redo some pieces because they don’t align with the business or the environment's restrictions.
The SilverLogic
The SilverLogic is an agile software development company that has leveraged well-written user stories into features and software for our clients for over a decade. Carefully crafted user stories save our clients time and money while enhancing productivity and reducing development costs. We work collaboratively with clients from start to finish so users, staff, and/or customers get the user experience they need to deliver the results their business deserves. Contact us today for help with your big idea!
