The last evolution of "Joplin" (CMS) on left, which renders "Janis" (public-facing) on right.
Building an author and resident centric CMS for a city.
My role as design lead and interim product manager
I was responsible for designing the CMS application, IA, and overseeing the functionality and display of the corresponding public website.
Activities as design lead
Maintained focus on UX by mentoring across disciplines, and guiding discussions so that focus on UX and MVP remained top of mind
Coordinated research, wrote and conducted usability tests, created prototypes
Oversaw junior researchers, test plans, and syntheses
Designed the author application (Joplin)
Led cross-disciplinary design sessions and weekly design pin-ups
Oversaw visual design and interaction implementation
Led dev-design syncs
Coordinated with content team on content strategy, content models, requirements, and features
Activities as product manager
Maintained focus on incremental improvements, while inspiring the team with the big picture
Rallying team around goals
Established sprint goals and mid-range road maps
Evaluated strategic evaluations of effort versus gain
Issue wrangling in github; wrote requirements and acceptance criteria
Understand how the current CMS (drupal) was being used by city staff, uncover any functional gaps, and assess how the platform contributed to the resident experience, including content governance, records retention, and the delivery of services to residents.
Design a CMS that would better serve city staff as well as provide a mobile friendly City website that exceeded accessibility and language access requirements. Test with city staff and residents as much as possible along the way.
City author research summary
The City of Austin content authoring is distributed, not centralized, which means the majority of employees adding content to the website aren’t hired for their web skills.
Most have little or no training and are completely unfamiliar with the principles for writing for the web, like using common language or an inverted pyramid style. Most infrequently had to make updates, which made using a complex tool even harder due to infrequency of use.
Micro-sites were also a used to escape Drupal parameters.
We discovered templates were misused in order to achieve certain goals. For example, a news template was often used because that template allowed more formatting than other templates. Because the information hierarchy on the page was so poorly established by the template, authors resorted to text formatting in order to try to make certain text visible on the page. For instance they might make something red and bold so that it would be visible in a wall of text. Predictably, those work-arounds led to a messy and confusing resident experience, as well as not achieving ADA compliance.
Content was rarely sunsetted, due to lack of ownership caused by turn-over and vague legal requirements regarding document retention requirements that might vary according to department or even document type.
There was no way to share a draft page; authors had to publish the page, get their supervisor to look at it, and then unpublish for changes.
Overall, the UI was excessively complicated for most tasks; even the button for publishing wasn’t clear.
Objectives for the new city author CMS (code named Joplin)
Utilize modern UI patterns that would be familiar.
Construct content templates that serve real needs of the city author and resident as evidenced by subject matter experts and residents.
Impose strict formatting and guardrails on content types to ensure a consistent front end, both visually and from a pattern perspective (to make it easier for residents to learn), and that exceeds ADA requirements for accessibility
create a feedback system to help content authors learn and improve their content, like:
in context style guide for authors
in context help for authors
visibility and awareness of mobile viewport
visibility into pages with low views
employ a feedback loop which allows residents to comment on the page and how it did/did not serve them (very successful!)
Attempt to slow or stop the over utilization of inaccessible pdfs by providing better content templates that serve actual city needs.
Build accessibility into templates, including font size, color, contrast, structured data, and compliance with screen readers.
The evolution of Joplin
The decision was made to adapt Wagtail, an open source Django based platform to our purpose. I evolved the default Wagtail UI, starting with the “pages” view, content creation and then page templates and functionality according to most pressing need. Early testing with Axure prototypes received positive responses from participants, as they all noted how “easy” it seemed in comparison to their current tool. As we tested we also made notes of pain points, writing them into issues, and assigning them to page template types or overall functionality as appropriate.
Creating content flow
A primary flow of any CMS is, of course, to create new content. In this early prototype, choosing a content type is accompanied by a small representational graphic and descriptive text to help the author understand the choices available to them.
Dovetailed products: designing two products simultaneously
A central challenge of designing a CMS from scratch is that essentially two products are being designed simultaneously - the CMS interface which allows authors to enter content, but also understanding and controlling the output and design that interface produces which provides the resident experience. Additionally, balancing the needs of authors without degrading the resident experience was tricky.
As a team, we had as a North star to first provide parity with the existing Drupal tool. We designed and developed these templates: service pages, info pages, forms, department pages, events, locations, official documents, contact information, and guides as well as topic collection and topic pages which controlled IA and navigational structure. Each of these types underwent a design process which included research and collaboration across disciplines.
This effort required a lot of source-of-truth tracking, for which we primarily used google docs. They included:
Content model doc, which included the elements used for each template, any character limits, and which fields were required for publishing
Style guide - this rendered in the UI, and needed to be updated for each new content type or changes in the functionality of the page
Joplin microcopy document: this document held all the microcopy (field labels, help text, etc) within the joplin UI, and was helpful to make sure the microcopy was consistent across elements and templates
Translations: our goal was to provide mostly human translated content in four languages, but we started with English/Spanish. Some labels were statically rendered, so also needed to be translated.
Permissions model: this document tracked which roles were allowed to access what functionality. This evolved over time, and initially was mostly about the ability to create new IA nodes (topic collections), or set "top" services, which was an editiorial function that regulated visually how certain content displayed on the resident-facing website (Janis).