APP BUILDER
Lead Designer
UX / UI / Interaction
2 Months
The first step in our process was to collaboratively identify and process the core needs and challenges of the application builder module. I worked directly with product owners and developers to understand initial constraints and expectations.
Additionally, we leveraged direct discussions with our partners to map out the goals of the module. Because the user groups of this product were niche, discussions with partners became a crucial opportunity to create feedback loops and iteratively improve upon our designs.
The module itself had editing functionality baked into nearly every component of each page, within elements both broad and granular. As such, the UI had to seamlessly accomodate configuration at all levels.
There was a wide range of complexity to be expected as a result of providing configurability across all components. A core goal between product and design was to provide a seamless experience that felt above all simple to use.
Though users would be directly editing and updating content as needed, the experience of the module needed to prioritize visual recognition of the pages themselves, ensuring user comfort in viewing their configurations and how it impacts the overall application.
A core part of the design process for the module was fleshing out and defining the interactions of content editing. Application pages sat across a wide spectrum of complexity, with each page having a different set of content that could be configured.
To guide the design process, I mapped out some guidelines that allowed for configuration interactions to be streamlined across all pages, starting from a top-level perspective and narrowing it down into nested editing. The interaction model naturally builds upon itself through layered touch points, ensuring that at every level the UI affords clear affordances to the ways in which a user can interact with the product.
Configurable content relies on hover indicators within the application page, providing clear affordances to editable content for users.
Users can click into a focus state for content they want to configure. Other page content fades to the background, with focused content keeping prominence.
Interaction with editable content follows a "drill down" approach, with additional configurable content appearing once a user enters a focused state within the application page.
The module flashes all focus states for a brief period of time upon entering a new application page, allowing users to get a clear glimpse of what content can be configured without becoming obtrusive.
For some pages, additional configurations needed to be accomodated within the UI. In these cases, the module utilizes configuration components to the right of the focused content. Alternatively, if another layer of configurations is needed, they are loaded directly beneath, following a "cluster" method of interaction.
Though pages could house direct editing such as text control, it became clear that the envisioned product needed many more layers of configuration than what could be cleanly presented within the application pages.
The panel’s appearance is triggered whenever a user enters a focused editing state, occupying the "ghost column" directly to the right of the content. The panel itself allowed us to support additional configurability while avoiding unnecessary UI clutter.
The panel utilizes a progressive disclosure approach to allow for information to be accurately condensed and revealed based on necessity. Toggles are utilized in turning configurations on/off, allowing for familiarity and ease of use.
The UI of the editor panel naturally adapts to the additional editing options of the focused content, allowing additional details to be entered and stored compactly.
Text editing is handled directly within application pages, and can be edited immediately upon entering a focused state on content within the page.
Text configuration is available across all content- including control within question titles and, for some content, individual labels. Configurability follows the precedent set within the interaction model, aligning with a "drill down" action to edit specific content.
Users can control the visibility of select questions through the editor panel visibility toggle. The application adjusts to hidden content with visual indicators placed in-line with the content.
Additionally, hidden content is clearly denoted within the ghost column, and utilizes hover-state information as well as a simple undo action to make hidden content visible.
Because the loan decisioning process is reliant on consumer data and applicant information, disclosures and consents were given a prioritized and separate "hub" within the Application Builder module.
Links are loaded into the product as individual components, contained within the Consent & Disclosure section.
○ Text / title editing
○ Link "on-click" functionality
Disclosure links then combine to form consent groups, which can also be edited within the Consent & Disclosure section.
○ Consent confirmation functionality
○ Add / remove additional disclosure links to groups, if needed
Consent groups can then be added to specific pages where applicable. In such cases, floating action buttons are present.
○ Standard visibility controls
○ Remove consent group from page
Users can edit their disclosure links title and on-click interaction through the module. Users have the option of having disclosures open new tabs, uploaded PDF's, or a modal, with the interface naturally adapting to handle configurations.
Due to legal regulations, consent groups cannot be generated organically by users. Instead, consents are loaded in pre-defined groups of disclosure links directly into the module. Users can then configure groups as needed, and add any additional links to the group if they desire.
Pages that are applicable for additional consents have a floating consent button within the right-hand side, allowing users to add a consent group with a simple click.
In addition to configuring existing application pages, from direct partner feedback, we learned that having a fully customizable page that partners could add their own unique questions too would be a large selling point.
Working with stakeholders as well as developers, I fleshed out the dynamics and experience of the Custom Questions page, including restrictions and overall approach. Users would be able to add up to seven customized questions, controlling the typing and content of each.
Because of the additional customization options associated with the Additional Information module, the editor panel needed to be expanded to match. In addition to the toggle-based controls of the panel, within the module users have the option of directly controlling question types, as well as deleting a question and its content completely.
Though standard page editing utilized the right-side ghost column to add additional content to pages, an exception was made for the Additional Information module.
Users can directly add a question through a persistent button nested within the custom application page itself. In doing so, the UI assists in creating an understandable, linear process of adding custom questions to the page.
Users can easily switch between different formats through the updated editor panel. Page content parallels the chosen question type, with the UI and information collection intentionally mirroring what the component will look like within the finalized application, such as with dropdown options.
The Application Builder module is slotted to be built and launched during Q2 of the 2024 calendar year. Before the build kick-off, I was working with other designers to continue strengthening the system design of the Self-Service product as a whole.
There were many challenges and pivots during the design of this module as well as the Self-Service product as a whole. If you'd like to further discuss it with me, let's chat!
LIAM MADIGAN
CHICAGO, IL
© 2024
LMADIGANDESIGN@GMAIL.COM