Conditional Page Navigation
Nintex
Focus
User Research, UI/UX Design, Interaction Design
Deliverables
Research Findings Summary Deck
High-Fidelity Mockups and Prototype
Conditional page navigation takes form respondents to specific pages based on their answers. This way, users only see the pages that are relevant to them as they fill out the form.
Overview
This feature was one of the most requested features on Nintex Ideas/Community forum, leading to a rapid release. However, it was ultimately pulled back for revisions due to UX concerns. This challenge became a valuable learning experience for the entire team.
The Challenge
How might we design multi-page forms so users are only brought to pages relevant to their selection?
Carmine, the app and asset creator
To understand this feature, we need to first understand “Carmine,” the app and asset creator. Carmine is usually a Business Analyst, though this role can vary by company, and falls into one of two subgroups:
Highly technical with engineering knowledge
Non-technical with very little to no engineering knowledge
Carmine is responsible for designing the form and setting up rules to make the content dynamic enough to ensure it is flexible for various scenarios. This feature must cater to both types of Carmine.
Despite initially exploring several options, our current rule engine could not support the "Go to" page condition I proposed due to its framework limitations. It was deemed beyond our available scope at that time.
The struggle between engineering vs. UX
The engineering team conducted a spike and proposed an alternative solution: a "Focus" condition. This would allow users to select an option and be automatically focused to a different control on another page, effectively navigating them to the desired location.
However, this approach felt like a "hack" and led to a confusing and unexpected user experience. While the "Focus" condition might be understood by highly technical users, it was not intuitive for non-technical users and it certainly wasn’t how users expect to configure conditional page navigation.
I shared my concerns with my manager, but unfortunately the escalation fell through from senior leadership at the time which resulted in the project moving forward.
#1 - Go to page
#2 - Focus
Taking a step back to re-evaluate and re-design
The feature was eventually halted due to concerns raised by senior leadership, as the initial design proved too complicated for our non-technical users. The user experience felt compromised because of the adjustments we had to make across other parts of the UI to accommodate for the “Focus” condition.
With feedback from the wider UX team, I completely overhauled the flow, focusing on creating a design that was intuitive for non-technical users, even if it meant increasing scope.
I prioritized the must-haves, should-haves, and nice-to-haves from the new designs and worked closely with the engineering team in a collaborative, iterative process to find a balanced solution.
Ultimately, we found the middle ground and landed on two potential methods to take into usability testing:
Task 2A - Hide pages
Task 2B - Go to page
Figma prototypes used in usability testing sessions. Please click full screen to view the prototypes.
Usability + A/B testing to pinpoint the best approach
This is what we set out to learn:
Understand if the overall design is intuitive and usable
Understand which method (Hide pages vs. Go to page) users prefer for setting up Page rules
Understand if what we’re proposing aligns with the user's expectations + identify any gaps or pain points
The results showed that while most users found the "Go to" option intuitive, it led to more complicated rule setups, with one user even describing it as "RULE HELL."
In contrast, the "Hide" pages approach not only met most customer use cases but also significantly reduced the number of rules required.
Users also noted that "Hide" pages is similar to our existing “Visible” construct for hiding/ showing controls on a page. Users also expressed a desire to have both “Hide” and “Go to” methods available in the future so they have full flexibility to accommodate all business use cases.
View the full research summary presentation here.
Thanks to this data, we ironed out details that made the whole experience more intuitive and consistent with our current framework. We were also able to define the first phase and subsequent phases to eventually work towards serving all customer use cases.
Data, data, data
Final prototype
Final Figma prototype demonstrating everything from turning on Conditional page navigation, setting up page rules and previewing the form. Please click full screen to view the prototypes.
Balance & trust among the trio is key
As the youngest team member, I felt pressured to deliver quickly and fit my design into the engineering scope, especially after the spike was completed on January 29, with the direction locked in within a week.
This situation highlighted the importance of each discipline having an equal voice in order to create a valuable, feasible, and usable feature.
In hindsight, I should have pushed harder for my voice to be heard. As a team, we should have escalated to leadership together, if more time is needed, rather than trying to squeeze everything in.
This would have given me the concrete data needed to support UX’s perspective in developing a feature with long-term growth potential.
Ultimately, despite the challenges we faced, we emerged from this experience stronger than ever.
