UX • Development

Enterprise Wireframing Tool

Interactive tool used by content owners, reviewers, and developers to create accurate mockups for CMS-based pages.

The Problem

Global 500 company uses a standardized CMS to develop hundreds of landing pages per quarter. Originally, content owners had to consult with design agencies to create static page mockups. Because of how strict the CMS rules are, reviewers would need to manually check all character counts and image sizes. The mockups would be passed back and forth between content owners, stakeholders, and the design agency for reviews and edits over the span of days, if not weeks. Upon final approval, the design agency would then create a "dev mockup" (a marked up mockup with spacing, font sizes, colors, as well as any asset exports), which would be passed to the development team. The amount of back and forth between content owner, reviewers, design agency, and developers was inefficient and time-consuming, making the idea of a "quick turnaround" almost impossible.

The Interactive Wireframing Tool expedites the content-to-live process by allowing content owners more flexibility and control of edits, which reduces back and forth time between the content owner, approver, and development team. Once the mockup reaches the developer, it is guaranteed to be "development ready"- character limits, image size restrictions, and CMS-specific rules are set in the Tool and the mockup cannot be approved until the rules are satisfied.

Since going live in early 2020, over 1,300 pages have been created using this tool.

The Results

Key Features

Conditional sections based on chosen templateNo confusion about which modules are allowed within which templates
Live validationCharacter limits and input-type checks mean content owners are able to see where they need to adjust their content before it's submitted for review
Developer-friendly UIThe new "dev mockup" includes easy-to-copy textareas with relevant HTML tags included and dynamically named assets for convenient uploading and referencing

Initial sketches to illustrate settings "drawers" in Edit mode

In edit mode, the less visible settings for a module would be tucked away in a slide-out panel or "drawer," so that the page itself could remain as uncluttered and close-to-actual as possible. A shows the edit page on default; B and C show the drawer.

Developer's settings "drawers" in Preview mode

Preview mode is the closest approximation of the live landing page. All of the elements, settings, and information not visible on the page itself is not shown in preview mode, to give content owners and developers a reference for how things "should" look once the page is developed. However, there are a lot of additional, non-visible, CMS-specific settings needed by the developers.

Each module has a settings "drawer" associated it with it, which holds all of these details. While these drawers are accessible to anyone looking at the preview page, they are designed with the developers in mind. When content paragraphs are added in edit mode, users use a WYSIWYG editor where they can bold, italicize, and add hyperlinks. In preview mode, the developers can use the settings drawer to access the content converted to appropriate HTML tags, from an easy-to-copy-and-paste textarea.

Email flow

In order for the tool to remain efficient, it was important that, at every stage, the relevant users were notified of what stage a mockup was in.

We started by going through the initial requirements provided by the client. This included going through the original submission process (which was done using a Word doc) for landing pages and understanding where the current pain points were.
----
We discovered that asset sizes/dimensions and character limits were some of the largest frustrations for content owners and developers. Requirements were often missed (or ignored) because they weren't obvious and there was no way to validate it in the Word doc.

This led to the live validation feature. Requirements per module are determined in the backend and checked at various points during content population. For assets, width, height, file type, and weight are checked, displaying an error message when something doesn't meet a requirement. For character counts, this accepts up two parameters and displays two states to the user:
‍
1. Hard stop: This is the maximum possible characters a user can input - they will not be able to type past the hard stop. Users get a displayed message when this is hit
2. Soft stop: This is optional and dependent on the field. This is considered the "recommended" maximum. For example, the Title field for Meet the Team cards has a soft stop of 50 characters. Users can actually input up to 75 characters (the hard stop), but the 50 limit is what is displayed in the character counter. In testing and reviewing existing pages, we saw that multiple job titles on a single person was not uncommon and, being that this was a global tool, some languages had longer words and would hit the max quicker. The soft stop combined with the hard stop allows for more flexibility, while still maintaining rules and encouraging the recommended limit.
----
Although each template only included "allowed" modules, it was easy to copy/paste a module from one Word doc into another. Similar to the character counts and asset dimensions, this would cause trouble with the developers later on- the mix and matching across templates is not allowed in the CMS, so it would have to be sent back to the content owner to fix.

This led to conditional sections based on the template. Once a page is created, the user will only be able to add modules based on the page's template. They are forced to use only what's available to that template, so a page will never make it to development with unusable modules.

Process Highlights

hannah kelley

Enterprise Wireframing Tool