Flags are a flexible way to organize and prioritize transactions. How can we make them even more useful and easy to use?
My Design Process
Step 1
What’s the problem?
Customers want bulk editing and customization for their transaction tags. What is the underlying problem that they are trying to solve? What assumptions are we making about this problem?
Step 2
Get inspired
Countless apps use flags and categories to help organize their data. What can we learn from them?
Step 3
Sketch, sketch, sketch
When it comes to idea generation, quantity leads to quality. What ideas can we (literally) draw from our inspiration?
Step 4
Define our principles
Which design ideas that we created are most likely to solve our design problem? What are the design principles behind these ideas that will guide our solution?
Step 5
Design the screens
What will our solution look like when live in YNAB? What are the details that we need to account for?
Step 6
What’s next?
How can this design could be improved with more time and cross-team collaboration?
Step 1
Define the design problem
Users tell us they would like to see two changes to transaction flags: bulk editing and customization. To understand this concern more deeply, let’s examine tagging within the entire journey of a user interacting with their YNAB accounts.
Select
Account
→
View
Transactions
→
Flag
Transactions
→
Take
Action
→
See
Results
✓
Users are not flagging transactions JUST TO ORGANIZE THEIR DATA. They are doing it to make it easier to take action.
Examining the journey tells us that flags are a means to an end for users; they are used to improve a user’s experience in taking action. YNAB users are not interested in flagging for its own sake, or as a way to simply organize their transactions. Flagging is done to improve a user’s workflow.
The Design Problem:
Create a flexible system for organizing and prioritizing transactions that improves the experience of taking action on transactions.
Assumptions
The design should not break existing functionality. For some users, the current flagging implementation is perfect as it is. For these users, the transition to a new system should not be painful.
The design should be self-evident. The design should not require additional help text or guidance; it should seamlessly augment existing capabilities.
The design should be constrained to the problem. This design is meant to address a specific concern: the goal should not be to create a new feature for its own sake.
Step 2
Gather inspiration
Flagging is a non-hierarchical method for categorizing information, and is related to the concept of “tagging” found in many applications. We can look to these applications for ideas of practices that do and do not apply to YNAB.
Things for iOS
Quick Tagging and In-Context Updates
Things offers a quick modal to apply tags to content in the app, and the ability to create, rename, and delete tags is available in-context.
OmniFocus for iOS
Accessible Tag Names
By using full tag names instead of just icons or colors, OmniFocus creates an experience that is accessible for all users.
Gmail
Customization and Complexity
Gmail uses tagging extensively for categorizing its information, and allows for deep customization in tag details and what is shown and hidden. This results in significant complexity in its settings.
Things for iOS
Natural Filtering
A top menu allows users to filter their data to specific tags, and the resulting filter is easy to view and remove.
Step 3
Sketch, sketch, sketch
Drawing inspiration from Things, YNAB’s mobile app can use a modal to bulk assign flags to transactions. The same modal can be a launching point for managing the flags.
Within this same modal, flags can be created, renamed, and re-ordered.
Also drawing inspiration from Things, YNAB mobile can display an information bar to show that the transactions have been filtered or sorted. A single-tap can undo the filtering or sorting that has been applied.
Drawing inspiration from OmniFocus, we can create a system that is accessible to all users. One way to do this is use a combination of text, color, and icons to define each flag, so that users can have a variety of ways to quickly distinguish their flags.
The web app can also use a modal to allow for quick application of flags to transactions. The natural launch point for this modal is the header menu on YNAB.
If a user would like to manage their tags within the web app, a sliding panel or large takeover modal can be used to enable additional features.
Step 4
Define our principles
Reviewing these sketches against the original design problem gives us three ways to move forward.
Limit the number of flags and options. As we saw in the Gmail example, a system for unlimited tags can be complicated. Furthermore, introducing icons and the ability to add or delete flags would only further complicate the interface, especially for users happy with the current implementation. To solve the stated design problem, we can limit the tags to the six currently available, and just add the ability to sort and rename the flags.
Leverage existing YNAB elements where available. On mobile, where there is currently limited support for flags, we can create the modals and “information bar” sketched above to create a simple system for assigning and filtering with flags. For the web, where filtering and sorting is already available, we should leverage the existing icons and menus and seamlessly integrate new functionality within them.
Create consistency with system standards and YNAB elements. On the web app, YNAB currently relies on modals for settings and other secondary actions. Introducing entirely new elements in isolation, like a sliding panel, will appear jarring to our users. Continuing to use modals, and especially leveraging existing ones, will simplify and streamline the experience.
Step 5
Design the screens
Bulk assign flags
iOS
The “More” button that is shown when selecting multiple transactions in YNAB is a natural place to add assign flags. Opening this menu will show an option to open the Flag transactions modal. A “Done” button will help in those scenarios in which multiple transactions with different tags are selected.
Rename flags
iOS
When selecting a flag to assign to transactions, the same window can be switched to an iOS-standard “Edit” mode to reorder or rename flags. Reordering allows users to customize the order in which transactions are displayed when ordered by flag. Renaming addresses a primary user need to customize flags.
Bulk assign flags
Web
Since our goal is to avoid introducing unnecessary new interface elements, a Flag menu can be added to the existing Edit menu in the web app. A link to manage flags is included in this menu, which launches a modal for renaming or reordering flags.
Filter by flags
Web
Similarly, adding flags to the existing “Filter Transactions” menu is a natural place to add this feature for the web app. Users will be able to use the same paradigm for flag filtering as they have been for date-based filtering.
Step 6
What’s next?
Since we are working in an agile environment, the steps below would happen iteratively, concurrently, and in conjunction with design.
Prototyping and Visual Design
What’s been presented is a set of static designs meant to convey how transaction flagging can be updated in the web and iOS implementations of YNAB. A user’s true experience with this feature, however, will be determined by typography, animation, and all of the other design elements that these static prototypes do not convey. Working with our visual design team will help take our design to a stage ready for development.
User Testing and Customer Service Insights
When creating these designs, it was assumed that the existing flag features should not be disrupted for current users. Working with our customer service team is a terrific way to validate this assumption, and better understand how this feature is being used. Is there an appetite, for example, for removing and replacing the current flags implementation entirely?
After an update is launched, customer service insights can similarly be used to understand how our customers are using the new flag features. Is the number of flags correct? What other features are important to our users?
Development
Without input from our engineers, the presented designs are purely conceptual. Working with development will give us the bounds of what is possible in our solution, and see where our design is not feasible — and where it can do much more.
Marketing and product planning
As the capabilities of flagging in YNAB are improved, does it make sense to still call them “flags”, or should they be referred to more generally as “tags”? What is the user-perception of both of these terms, and what is better suited for YNAB overall? How does non-hierarchical data organization fit into YNAB’s larger goals, and what are the related features that should be addressed in terms? Working with our peers in marketing can broaden our work and help us plan for the future.
Appendix
The above discussion encapsulates approximately four hours of design work. As an additional exercise, to help illustrate the above prototypes in context, I spent a bit more time and created a few additional screens to help illustrate the end-to-end workflow of the new flagging features, which are hopefully of use to the YNAB team. Click on any image to open a carousel view of the designs.
