Responsive Page Templates
Responsive Page Templates
Responsive Page Templates
Reusable, responsive page-level templates that enable responsive design across the product, improve UI consistency, and streamline frontend development.
Reusable, responsive page-level templates that enable responsive design across the product, improve UI consistency, and streamline frontend development.
Reusable, responsive page-level templates that enable responsive design across the product, improve UI consistency, and streamline frontend development.
Project Type
UI design • systems
Tags
scalability
Roles
design lead
Association
Design Systems Manager
at
CallRail
in
2023
Project Framing
Problems
User pain points: Minimal responsive design support on desktop; nearly none for tablet and mobile. Page layout inconsistencies such as CTA placement.
Internal pain points: Inconsistent use of grid systems during development. Unclear best practices for designers to follow regarding aforementioned user pain points.
Goals
Create reusable page-level templates that are responsive down to mobile.
Desired outcomes
New page-level design templates in Figma that account for desktop and mobile layouts.
New frontend development guidelines for responsive layouts.
Standardized team approach to responsive grid systems.
Future: page-level templates available in our code base.
Project Framing
Problems
User pain points: Minimal responsive design support on desktop; nearly none for tablet and mobile. Page layout inconsistencies such as CTA placement.
Internal pain points: Inconsistent use of grid systems during development. Unclear best practices for designers to follow regarding aforementioned user pain points.
Goals
Create reusable page-level templates that are responsive down to mobile.
Desired outcomes
New page-level design templates in Figma that account for desktop and mobile layouts.
New frontend development guidelines for responsive layouts.
Standardized team approach to responsive grid systems.
Future: page-level templates available in our code base.
Project Framing
Problems
User pain points: Minimal responsive design support on desktop; nearly none for tablet and mobile. Page layout inconsistencies such as CTA placement.
Internal pain points: Inconsistent use of grid systems during development. Unclear best practices for designers to follow regarding aforementioned user pain points.
Goals
Create reusable page-level templates that are responsive down to mobile.
Desired outcomes
New page-level design templates in Figma that account for desktop and mobile layouts.
New frontend development guidelines for responsive layouts.
Standardized team approach to responsive grid systems.
Future: page-level templates available in our code base.
Process
Phases
Broken down by design pattern. Each phase includes:
Design pattern audit
Design templates
Updated code to reflect design changes
Strategy
Prior to this project, I explored a high-level strategy for bringing responsive design into our existing web app. Those explorations included auditing our existing design patterns. The audit helped me see more clearly which patterns we would need to address to bring more responsive behavior to our web app. And through that through process, I considered two approaches:
Bottom-up: Redesign individual patterns to be responsive. Then, rebuild them in code to reflect the changes.
But there are a couple big challenges with this approach. For one, we have a lot of patterns that need to be updated to be responsive. It would take some time to work through them all. And on top of that, even if we update all of them—every button, table, form input, etc—we would still have to update our page layouts before any of the component-level work have any real effect. The scope of work needed before seeing any meaningful impact on users was simply too large. So I considered reversing the approach, focusing on the page level first.
Top-down: Design page-level templates to be responsive, first. Then, make associated changes in our code while establishing new page template guidelines to encourage future frontend dev work to be more streamlined and connected to this approach.
Immediately, this approach drastically reduces scope by focusing on a significantly smaller set of patterns that need to be redesigned. Breaking down the product into page-level templates would result in only a handful of patterns vs every single component across the design system. It’s a way more manageable place to start. This also allows for further scope reduction and flexibility by selecting a limited number of page templates.
it’s assumed that by allowing page layouts to be responsive before worrying about all lower-level patterns (buttons, tables, etc.), we would be allowing any existing responsive patterns to flow into place as expected, leaving only the non-responsive patterns left to address. And limiting scope to only a handful of pages to start, we could get closer to a few fully responsive pages a lot faster than trying to solve for all patterns and all pages across the product.
Starting at the atomic level and working our way up may seem more attainable to start, but would largely be ineffective until working all the way up to the page level. Without page-level responsive support, component-level responsive behavior will not be enough. However, launching page-level responsive layouts would make more sweeping improvements across the experience with smaller elements able to follow when ready.
Process
Phases
Broken down by design pattern. Each phase includes:
Design pattern audit
Design templates
Updated code to reflect design changes
Strategy
Prior to this project, I explored a high-level strategy for bringing responsive design into our existing web app. Those explorations included auditing our existing design patterns. The audit helped me see more clearly which patterns we would need to address to bring more responsive behavior to our web app. And through that through process, I considered two approaches:
Bottom-up: Redesign individual patterns to be responsive. Then, rebuild them in code to reflect the changes.
But there are a couple big challenges with this approach. For one, we have a lot of patterns that need to be updated to be responsive. It would take some time to work through them all. And on top of that, even if we update all of them—every button, table, form input, etc—we would still have to update our page layouts before any of the component-level work have any real effect. The scope of work needed before seeing any meaningful impact on users was simply too large. So I considered reversing the approach, focusing on the page level first.
Top-down: Design page-level templates to be responsive, first. Then, make associated changes in our code while establishing new page template guidelines to encourage future frontend dev work to be more streamlined and connected to this approach.
Immediately, this approach drastically reduces scope by focusing on a significantly smaller set of patterns that need to be redesigned. Breaking down the product into page-level templates would result in only a handful of patterns vs every single component across the design system. It’s a way more manageable place to start. This also allows for further scope reduction and flexibility by selecting a limited number of page templates.
it’s assumed that by allowing page layouts to be responsive before worrying about all lower-level patterns (buttons, tables, etc.), we would be allowing any existing responsive patterns to flow into place as expected, leaving only the non-responsive patterns left to address. And limiting scope to only a handful of pages to start, we could get closer to a few fully responsive pages a lot faster than trying to solve for all patterns and all pages across the product.
Starting at the atomic level and working our way up may seem more attainable to start, but would largely be ineffective until working all the way up to the page level. Without page-level responsive support, component-level responsive behavior will not be enough. However, launching page-level responsive layouts would make more sweeping improvements across the experience with smaller elements able to follow when ready.
Process
Phases
Broken down by design pattern. Each phase includes:
Design pattern audit
Design templates
Updated code to reflect design changes
Strategy
Prior to this project, I explored a high-level strategy for bringing responsive design into our existing web app. Those explorations included auditing our existing design patterns. The audit helped me see more clearly which patterns we would need to address to bring more responsive behavior to our web app. And through that through process, I considered two approaches:
Bottom-up: Redesign individual patterns to be responsive. Then, rebuild them in code to reflect the changes.
But there are a couple big challenges with this approach. For one, we have a lot of patterns that need to be updated to be responsive. It would take some time to work through them all. And on top of that, even if we update all of them—every button, table, form input, etc—we would still have to update our page layouts before any of the component-level work have any real effect. The scope of work needed before seeing any meaningful impact on users was simply too large. So I considered reversing the approach, focusing on the page level first.
Top-down: Design page-level templates to be responsive, first. Then, make associated changes in our code while establishing new page template guidelines to encourage future frontend dev work to be more streamlined and connected to this approach.
Immediately, this approach drastically reduces scope by focusing on a significantly smaller set of patterns that need to be redesigned. Breaking down the product into page-level templates would result in only a handful of patterns vs every single component across the design system. It’s a way more manageable place to start. This also allows for further scope reduction and flexibility by selecting a limited number of page templates.
it’s assumed that by allowing page layouts to be responsive before worrying about all lower-level patterns (buttons, tables, etc.), we would be allowing any existing responsive patterns to flow into place as expected, leaving only the non-responsive patterns left to address. And limiting scope to only a handful of pages to start, we could get closer to a few fully responsive pages a lot faster than trying to solve for all patterns and all pages across the product.
Starting at the atomic level and working our way up may seem more attainable to start, but would largely be ineffective until working all the way up to the page level. Without page-level responsive support, component-level responsive behavior will not be enough. However, launching page-level responsive layouts would make more sweeping improvements across the experience with smaller elements able to follow when ready.
Research
Audit
Through auditing our existing page templates, my direct report and I broke them down into groups and accounted for how many pages fell within each. This helped us quantify which groups were larger and just how common some of our page-level patterns were. From there, we outlined next steps. The following images are the slides we presented to the UX team on our findings.
Diving deeper
The audit helped give us a high-level view of how our pages can be broken down into templates. But in order to define each template and ensure each page gets a template structure applied to it, we have to look at the design of each page. So for our next steps, we picked a layout type to dive deeper. Of the 4 options, we picked Wizards for the following reasons:
Lead Center is mostly already responsive
Call Flow Builder is a combination of low priority and high difficulty.
Regular 1 Column pages account for far too many pages and variations to be an easy entry point.
Wizards have a relatively number of variations and only account for 14% of pages. They are also a critical pattern used throughout the user’s journey including onboarding, billing, and multiple setup experiences. This was an easy choice for a starting point. We also had planned upcoming work on Wizard experiences that could benefit from improved layout standardization and responsive behavior.
From here, we performed audits on Wizard pages to find all existing pages using that pattern. This was also an important check point with Product Management to ensure we were focusing on the right places. The intent was to comb through all existing designs, consider consolidating similar patterns, and include a mobile-responsive variations for any Wizards that were not yet mobile-friendly.
Research
Audit
Through auditing our existing page templates, my direct report and I broke them down into groups and accounted for how many pages fell within each. This helped us quantify which groups were larger and just how common some of our page-level patterns were. From there, we outlined next steps. The following images are the slides we presented to the UX team on our findings.
Diving deeper
The audit helped give us a high-level view of how our pages can be broken down into templates. But in order to define each template and ensure each page gets a template structure applied to it, we have to look at the design of each page. So for our next steps, we picked a layout type to dive deeper. Of the 4 options, we picked Wizards for the following reasons:
Lead Center is mostly already responsive
Call Flow Builder is a combination of low priority and high difficulty.
Regular 1 Column pages account for far too many pages and variations to be an easy entry point.
Wizards have a relatively number of variations and only account for 14% of pages. They are also a critical pattern used throughout the user’s journey including onboarding, billing, and multiple setup experiences. This was an easy choice for a starting point. We also had planned upcoming work on Wizard experiences that could benefit from improved layout standardization and responsive behavior.
From here, we performed audits on Wizard pages to find all existing pages using that pattern. This was also an important check point with Product Management to ensure we were focusing on the right places. The intent was to comb through all existing designs, consider consolidating similar patterns, and include a mobile-responsive variations for any Wizards that were not yet mobile-friendly.
Research
Audit
Through auditing our existing page templates, my direct report and I broke them down into groups and accounted for how many pages fell within each. This helped us quantify which groups were larger and just how common some of our page-level patterns were. From there, we outlined next steps. The following images are the slides we presented to the UX team on our findings.
Diving deeper
The audit helped give us a high-level view of how our pages can be broken down into templates. But in order to define each template and ensure each page gets a template structure applied to it, we have to look at the design of each page. So for our next steps, we picked a layout type to dive deeper. Of the 4 options, we picked Wizards for the following reasons:
Lead Center is mostly already responsive
Call Flow Builder is a combination of low priority and high difficulty.
Regular 1 Column pages account for far too many pages and variations to be an easy entry point.
Wizards have a relatively number of variations and only account for 14% of pages. They are also a critical pattern used throughout the user’s journey including onboarding, billing, and multiple setup experiences. This was an easy choice for a starting point. We also had planned upcoming work on Wizard experiences that could benefit from improved layout standardization and responsive behavior.
From here, we performed audits on Wizard pages to find all existing pages using that pattern. This was also an important check point with Product Management to ensure we were focusing on the right places. The intent was to comb through all existing designs, consider consolidating similar patterns, and include a mobile-responsive variations for any Wizards that were not yet mobile-friendly.
Design
Pattern consolidation
After collecting mockups of all the existing Wizard experiences into one place, my direct report took ownership of exploring how we could consolidate similar patterns to reduce unnecessary variation that had cropped up over time as new Wizard experiences were designed. For example, multiple billing-related workflows had been designed, but didn’t always follow the same exact layouts or had different solutions for similar design problems.
Review
As we had updated designs to look at, we held a few review cycles to get feedback from designers, engineers, and product managers. This helped us ensure we were still on the same page and that the updated designs still effectively solved for the original problems that each Wizard was created for.
Rinse, repeat
Once we’re all the way through at least handoff of the Wizard patterns, we’ll repeat this phase for the other layout types. Those will happen as separate future phases of this project as we’re able to resource them.
Design
Pattern consolidation
After collecting mockups of all the existing Wizard experiences into one place, my direct report took ownership of exploring how we could consolidate similar patterns to reduce unnecessary variation that had cropped up over time as new Wizard experiences were designed. For example, multiple billing-related workflows had been designed, but didn’t always follow the same exact layouts or had different solutions for similar design problems.
Review
As we had updated designs to look at, we held a few review cycles to get feedback from designers, engineers, and product managers. This helped us ensure we were still on the same page and that the updated designs still effectively solved for the original problems that each Wizard was created for.
Rinse, repeat
Once we’re all the way through at least handoff of the Wizard patterns, we’ll repeat this phase for the other layout types. Those will happen as separate future phases of this project as we’re able to resource them.
Design
Pattern consolidation
After collecting mockups of all the existing Wizard experiences into one place, my direct report took ownership of exploring how we could consolidate similar patterns to reduce unnecessary variation that had cropped up over time as new Wizard experiences were designed. For example, multiple billing-related workflows had been designed, but didn’t always follow the same exact layouts or had different solutions for similar design problems.
Review
As we had updated designs to look at, we held a few review cycles to get feedback from designers, engineers, and product managers. This helped us ensure we were still on the same page and that the updated designs still effectively solved for the original problems that each Wizard was created for.
Rinse, repeat
Once we’re all the way through at least handoff of the Wizard patterns, we’ll repeat this phase for the other layout types. Those will happen as separate future phases of this project as we’re able to resource them.
Development
Handoff
With finalized updated Wizard designs, we worked with engineers to draft handoff documentation and ensure they had what they needed to effectively and efficiently build in the design changes made to our Wizards. However, there was one big problem. We didn’t actually have a responsive grid system in place that our engineering team considered current and standardized across the product.
Rinse, repeat
At this point, we were pretty far along. But it was absolutely necessary to ensure we have the right foundational development tools in place before we can implement responsive behavior into our web app. So we redirected our attention to solve for this first before moving any further.
Responsive grid system
Through our design systems guild (Caboose Crew), we discussed how to approach standardizing a new grid system. And over the course of several meetings, we finally landed on an approach that we felt would solve for our long-term needs while also respecting each cross-functional team’s freedom to chose how to approach a given project they were tasked with. With a new approach in hand, we could pick back up on the development phase making updates to our Wizards.
Implementation
With a fresh strategy for how we plan to approach responsive work through grid systems, our engineers began work on implementing changes to our Wizards.
Retrospectives
Though not entirely specific to the development stage, we began doing retros to discuss what parts of this project have worked well and should continue for future phases and where we can improve. There’s quite a bit of work to do over the long-run to get through all pages and templates of the product. So ensuring we a solid and repeatable process for this work will go a long way.
Development
Handoff
With finalized updated Wizard designs, we worked with engineers to draft handoff documentation and ensure they had what they needed to effectively and efficiently build in the design changes made to our Wizards. However, there was one big problem. We didn’t actually have a responsive grid system in place that our engineering team considered current and standardized across the product.
Rinse, repeat
At this point, we were pretty far along. But it was absolutely necessary to ensure we have the right foundational development tools in place before we can implement responsive behavior into our web app. So we redirected our attention to solve for this first before moving any further.
Responsive grid system
Through our design systems guild (Caboose Crew), we discussed how to approach standardizing a new grid system. And over the course of several meetings, we finally landed on an approach that we felt would solve for our long-term needs while also respecting each cross-functional team’s freedom to chose how to approach a given project they were tasked with. With a new approach in hand, we could pick back up on the development phase making updates to our Wizards.
Implementation
With a fresh strategy for how we plan to approach responsive work through grid systems, our engineers began work on implementing changes to our Wizards.
Retrospectives
Though not entirely specific to the development stage, we began doing retros to discuss what parts of this project have worked well and should continue for future phases and where we can improve. There’s quite a bit of work to do over the long-run to get through all pages and templates of the product. So ensuring we a solid and repeatable process for this work will go a long way.
Development
Handoff
With finalized updated Wizard designs, we worked with engineers to draft handoff documentation and ensure they had what they needed to effectively and efficiently build in the design changes made to our Wizards. However, there was one big problem. We didn’t actually have a responsive grid system in place that our engineering team considered current and standardized across the product.
Rinse, repeat
At this point, we were pretty far along. But it was absolutely necessary to ensure we have the right foundational development tools in place before we can implement responsive behavior into our web app. So we redirected our attention to solve for this first before moving any further.
Responsive grid system
Through our design systems guild (Caboose Crew), we discussed how to approach standardizing a new grid system. And over the course of several meetings, we finally landed on an approach that we felt would solve for our long-term needs while also respecting each cross-functional team’s freedom to chose how to approach a given project they were tasked with. With a new approach in hand, we could pick back up on the development phase making updates to our Wizards.
Implementation
With a fresh strategy for how we plan to approach responsive work through grid systems, our engineers began work on implementing changes to our Wizards.
Retrospectives
Though not entirely specific to the development stage, we began doing retros to discuss what parts of this project have worked well and should continue for future phases and where we can improve. There’s quite a bit of work to do over the long-run to get through all pages and templates of the product. So ensuring we a solid and repeatable process for this work will go a long way.
Current state
At the time of this writing, we’re in the process of making responsive updates to our Wizards. We still have a lot of work ahead of us. But we’ve laid the foundation for how this process can apply across more layout types.
We don’t yet have true templates. But that will be another follow-up focus once development work on the Wizards is complete.
Current state
At the time of this writing, we’re in the process of making responsive updates to our Wizards. We still have a lot of work ahead of us. But we’ve laid the foundation for how this process can apply across more layout types.
We don’t yet have true templates. But that will be another follow-up focus once development work on the Wizards is complete.
Current state
At the time of this writing, we’re in the process of making responsive updates to our Wizards. We still have a lot of work ahead of us. But we’ve laid the foundation for how this process can apply across more layout types.
We don’t yet have true templates. But that will be another follow-up focus once development work on the Wizards is complete.