Improving Channel Management
Table of Contents
Summary Return to table of contents
Creating channels for ExpressionEngine required domain expertise, intense documentation, use of multiple forms in different flows, duplication and forced dispersal of channels and their assets due to lack of asset sharing.
Outcomes after design and development:
- reduction of workflows from 5+ to 1.
- customer support requests decreased by 30%.
- install to publish time decreased from ~90 to ~15 minutes.
- special documentation to build channels was not required.
- on average fields were reduced to less than 20, from 100+.
What’d you do? Return to table of contents
I was the project lead, full-stack designer, and frontend developer 1.
Artifacts of note Return to table of contents
For the channel manager redesign I provided:
- customer research findings & testing results.
- UX workflows & proposals for improvement.
- UI design proposals & revisions.
- HTML, CSS, & Javascript frontend code.
- github documentation and implementation guides.
More detail Return to table of contents
After many years of straight-up sucking at making it easy to go from installation to publishing with ExpressionEngine an otherwise wonderful off the shelf CMS we decided to take another swing at our publishing setup flows.
Quick primer: Channels are buckets for content to be stored in and served from. i.e. Blog could be a channel that stores all your blog posts. Channels also have assets: statuses, fields (e.g. title, body, etc…), and categories. Each asset also has groups (folders) to organize those assets.
In version 3 we’d taken a preliminary step towards unifying our publishing experience, but missed the mark in substantial ways. Stopping short of full unification, however we’d centralized the different steps in the control panel which felt like a big step forward.
In hindsight this was a vital step in helping users reframe the content model.
However, this version still required extensive expertise, lots of back and forth to setup a channel, and you couldn’t share channel assets.
For version 4 we took this unification to it’s final form. An actual single flow that allowed a user to set up a channel and start publishing in under 15 minutes even without prior experience or understanding of the content model. A huge win!
The approach Return to table of contents
The work started with user research and testing to gauge our before metrics. Which led to some dramatic findings and some goal setting for the project.
- Reduce install to publishing average time.
- Reduce the learning curve for channel setup.
- Increase the flexibility of channels and their assets.
With my findings, results, and goals in hand I shopped some preliminary UI sketches around internally and with a small external dev group. Iterating from those meetings, we landed on a design proposal.
I created high fidelity prototypes and mock ups, getting feedback and sign off along the way as needed. Once we landed on an agreeable MVP, I got to work writing HTML/CSS and Javascript, opening a PR replete with documentation and implementation instructions for our backend dev team.
I should mention at ExpressionEngine we didn’t have a hard hand-off, so the design work always continued beyond initial design and frontend hand-off. I consistently worked closely with our developers to make sure that the shipped product always met dev specs and our quality bar.
I believe we met or exceeded our goals in really impressive ways.
- install to publish time decreased from ~90 to ~15 minutes.
- customer support requests decreased by 30%.
- on average fields were reduced to less than 20, from 100+.
I’m very proud of the outcomes for this feature, and I know it made ExpressionEngine better!
Looking back? Return to table of contents
We decoupled statuses from the channels to make them more portable and sharable across channels and sites. This caused some pretty major issues for third-party add-on developers that I had not identified in my research. I didn’t ask the right questions about this specific sub-feature.
This forced us to do a robust rewrite of our channel API, which was scope creep for this project and ultimately cost our team time we could have used on another feature or improvement.
This mistake taught me to:
- carefully consider how I plan my research sessions.
- be more robust in determining edge cases vs important cases.
Due to a misinformed decision to remove field groups from our content model, I inadvertently created a hostile UI to discourage their use until we could prioritize removing them, which made it more difficult to use field groups than intended.
This lead to design and code refactoring to allow field groups to be surfaced and used in the same way as any other channel asset.
This bad call taught me to:
- be more clear in cases where design deviates.
- default to the most accessible UI as a first pass.