The boundaries are blurring between software-as-a-service and application design. It’s not just about the consistency in separation of the front end of the back end. For your SaaS platform the best practices for well structured code apply as much to web front ends as to back-end infrastructure (what runs on the cloud). Web themes (also called templates, front-end component libraries or front-end design systems) help efficient design and testing, and enforce UI consistency.
- Starting from Modular Design: For B2B SaaS, modular thinking in software development applies to both Back end and Front End
- Avoiding common problems with design: Don’t make front-end reusability an afterthought
- Set Top Level Goals: don’t settle for bottom-up
- Best Practices & Real Life Examples: Learn from the best
- Style guides to Style Sheets : Now, less really is more
- One-Stop Dashboard Theme: A high leverage example
- Web Theme Requirements Checklist: make sure your plan includes these essentials
This approach is especially important in Agile environments, where enabling more efficient design workflows is critical to keeping the fast pace of development. When developed rigorously, web themes promote consistent design practices and enforce developer adherence to specifications.
1. Starting from Modular Design
Modular thinking in software development is a strongly established tradition. But it applies just as much to front-end design. In this context, modular design encourages us to think and design a UI and UX in patterns. For example, instead of designing a series of pages or views to enable a user to accomplish a task, we start the design process by understanding how the UI system is structured and how its components can be used to create the user flow.
As designers, we want to create a UI system that is efficient in both construction and operation (check out “Atomic Design”). When we find a solution to a problem, we want to be able to reuse the solution in many places. This not only saves time but also establishes a pattern that users can learn once and reapply in other areas of the application. We also want to be able to customize the system for certain scenarios without having to restructure everything. And of course, consistency has a huge impact on the stability and scalability of the back end.
When you’re building a B2B SAS application, there are multiple businesses who each want to have their own unique integrated interface. The challenge is to leverage the structure of the back end and data services without dumbing-down the front-end. Let’s take a closer look.
1. Avoiding common problems
50 shades of grey
UI and UX inconsistencies across the app are band-aids on a much bigger problem; without guidance, developers take shortcuts that won’t impress your customers
When answering even simple questions like “Which component should I use?” becomes very time-consuming.
Poor delivery quality
UX/UI inconsistencies make users confused and frustrated when they could not get their expected feedback.
Inconsistent code library
Sometimes the front-end guys come up with new components with a different look & feel instead of reusing the existing ones. But don’t blame the developer if reusability hasn’t really been thought through thoroughly.
3. Set Top-Level Goals
Lego is often cited as a metaphor for the modularity imperative in software design and SAS applications. The metaphor has its limits because you rarely have to live in a Lego castle or drive a Lego car in the real world. Thinking end-to-end about the SAS application, from web themes through to data multi-tenancy and infrastructure partitioning, requires more than casual inspiration.
Organization: Getting rid of a messy codebase and over customized UI components. Making sure top have a well-thought-out structure and approach.
Maintainability: Over time, there are going to be new developers jumping in to fix bugs and add features. We needed to have proper guidelines and conventions to make it easy for people to do things correctly.
Scalability: The app will grow in the future. Adding new product features should no longer be an unpleasant (and near-impossible) task.
4. Real Life Examples
- Atlassian UI
- Salesforce Lightning Design System
- Mozilla Sandstone
- Lonely Planet Rizzo
- Financial Times Origami
- Buzzfeed Solid
- Fontshop Styleguide
- U.S. Web Design System (USWDS)
- Starbucks Style Guide
- MailChimp UX Patterns
- Carbon Design System by IBM
5. Style guides to Style Sheets
It’s hard to overestimate the speed and flexibility that web design has introduced into B2B applications. For B2B SaaS Applications, it’s not just a matter of creating style sheets, which often remove complexity from individual pages, only to bury the fragments of complexity within a single client tenant application (ISVs who have tried to “port” their application front end to the cloud find this out the hard way).
Today, the most robust and complete approach to creating web templates is undoubtedly Bootstrap. However, when you are planning to grow your application to support multiple businesses, and deliver on the value they expect to get from leveraging your platform, it’s best to create a style guide. It serves as a foundation document for multiple implementations for multiple customers and avoiding fragmentation (as a side note, it also helps avoiding orphan front end fixes to one off customer requests, that can break the integration of new features released down the road.
Creation Tool Examples
6. One-Stop Dashboard Theme
Today, CloudGeometry Dashboard Theme powers small businesses to large enterprises for all their SaaS applications: custom admin panels, admin dashboards, e-commerce back-ends, CMS, CRM, all key elements of B2B SaaS.
Get in touch
Dashboards are particularly important because the customer can see directly impact of the value of your application platform, since it has all of the data about how your customers’ customers work with your platform in one place.
7. Web Theme Requirements Checklist
When you think about your web themes requirements in a style guide, we recommend you account for:
- Table of contents that splits components into easily-findable categories;
- Responsive layout or grid systems used to place common UI elements;
- Color palette of the product (HEX or HSL);
- Typeface styles which should include typeface name and foundry, sizes, weights, leading/line height, tracking/kerning, and the appropriate contexts of use for that text style.
For each of the specific UI elements:
- Description of the appropriate context of use (aka, when does it make sense to use one particular component vs. a similar one?)
- Code snippets
- Specs for implementation, including positioning and spacing information
- Do’s and don’ts for that element.
Ultimately, the goal for B2B SaaS applications is “design once, re-use continuously”. Picking through your style guide and the template it drives helps see to that result as your application and customer base grows.