A new perspective can sometimes be as valuable as a new product

There are many motivations that go into the product roadmap mix, like client requests, bug fixes, or market expansion. But the releases with the biggest impact are most often those that simply make life easier for users.

Our Action Builder has long been a potential game-changer for content creators, letting them automate elements in an assessment to make navigation easier for learners. But it’s long been something of a hidden gem, lost beneath a mountain of options.

One reason for its relative obscurity is that, until now, customers could only access it through our Author Site (our out-of-the-box authoring platform) rather than directly through their product via our integrated Author API.

It was only after we’d committed to a longer-term project to redesign the Author Site that we looked at adding some of its features to the Author API. Doing so meant we could increase feature parity between the two, which had several advantages. Namely, it would:

• Give customers using the Author API direct access to features previously only available in the Author Site
• Make developing and maintaining features in the Author API easier for our teams than in the Author Site
• Help simplify the Author Site
• Allow us to revisit certain features, like the Action Builder, and improve them

Understanding the challenge ahead

Because the Action Builder preceded my time at Learnosity, the first step in developing an understanding of how I could improve it was to gather as much information about it as possible.

This was easier said than done, at least initially. 

As a long-standing feature at a fast-moving company, some of the people initially involved in the Action Builder’s development were no longer with Learnosity; and few on the current team knew much about it. It felt a bit like a shiny household appliance someone once bought then stowed away until they forgot they had it.

Thankfully, some of its original developers were still with us and on hand to fill in the gaps. So I sat for a bunch of informal one-on-one conversations with them to learn about the purpose of the feature, its implementation, and gauge how much work I faced in porting it to our Author API.

The origins and purpose of the Action Builder

For context, here are the Cliff Notes of what I learned about the feature’s purpose and implementation: 

The Action Builder (originally called the Workflow Builder) was designed to let authors define and script certain behaviors within an Item during assessments.

A fairly typical action-building step for a content author involved selecting an event from a list within an Item (or any of its features), and mapping that event to the action they wanted to perform on the Item. A basic example would be a video that autoplays (the “action”) within an Item as soon as a test taker navigates to the Item (the “event”).

Unclear UI can obscure important features

While this offered several useful applications for content authors, the initial JSON solution our team used had its limitations. For instance, authors often needed extra support from us in order to use the feature properly.

Additionally, the UI was somewhat buried in the advanced settings. Even when users did discover it, the UI didn’t make it easy to explore the Action Builder’s true capabilities. 

Putting a spotlight on the Action

Having gained a clear understanding of the feature’s purpose – along with its shortcomings – I knew that the real project wasn’t simply porting the Action Builder to the Author API but rather unlocking its potential for customers. 

This meant reconfiguring the UX. Normally, that’d be where we’d turn to our design team to lead the way, but work on the Action Builder happened to coincide with other major projects they had on at the time.

Instead of seeing this as a hindrance, I took the opportunity to shape the look and feel of the user experience – something I always wanted to do as part of my development as a front-end engineer. 

I enjoyed the autonomy but found that communication was still crucial in keeping everyone up to speed on how things were panning out. As a result, the design team could continuously test my work, offer advice, and help validate the user experience; while our assessment engineers provided guidance on the best way to integrate our Author and Assess APIs. 

In fact, one of my key takeaways from the entire process was that opening lines of communication between teams and keeping them open is integral to successful delivery.

Stay focused on the user

The other key takeaway was to always put the user at the heart of your efforts. It’s an obvious statement to make, but it’s also a principle that can get lost all too easily in the heat of the development fray.

So to bring the Action Builder to life, I put myself in the shoes of a content author trying to define event-to-action mappings.

One of the first things I noticed with the existing Action Builder was the number of clicks it took to choose events and actions. I noticed that the steps weren’t particularly clear, which complicated the user experience unnecessarily.

This is how the existing user flow worked: authors had to first choose an Item event or a feature event. If selecting the latter, they would then need to choose a value from a dropdown field called “reference”, which identified the feature. Once done, the event dropdown underneath became clickable and the author could finally choose an event name.

Given that time-poor authors might need to define dozens of event-to-action mappings, such a user journey was likely to turn a rapid-fire task into a slow-burner.

Making content authors’ lives easier

Testing the interaction some more revealed the most pressing areas for improvement. We needed to:

• Make navigational copy clearer
• Streamline the UI for event-action mapping

The UI copy changes I made were pretty small but allowed me to remove superfluous dropdown menus or merge buttons to simplify the user experience.

With the design team’s support, I also worked on rearranging elements of the UI to make it possible to select a single event or action in just two interactions within a single row. The number of rows for describing event-action mappings was also reduced by more than half – down from seven in the Author Site to just three in the Author API.

This removed friction for authors and made multiple mappings far quicker and more user-friendly.

For event selection, authors could now simply choose an “Event origin” (the entity the event came from) and an “Event name” (the actual name of the event). For action selection, they just selected an “Action target” (the entity on which the action would be executed) and the “Action name”. 

Before

After 

In for a penny, in for a pound

These improvements alone were enough to ensure a much better user experience for authors, but the user journey didn’t stop with event-action mapping. Authors also needed to preview their work to see how the assessment flows they created worked for their actual end-users – learners.

The Action Builder on the Author site had a preview function, but using it opened a new tab that rendered a temporary activity containing only the Item they were working on.

This meant that authors couldn’t verify that certain actions (such as transitioning to the next Item) were working properly without needing to take a series of elaborate next steps, which resulted in a disjointed user experience.

To fine-tune the preview function’s performance, we added a “Reload preview” function so that authors could view their work without having to reload their browsers and risk losing unsaved changes to their Items.

Since the Author API is embeddable, previews had to open within the Author API itself rather than in a separate tab. Technically, this meant that the Author API needed to embed the Assess API in order to preview the Item and the author’s event-action mapping.

So, with the help of the Assessment team, previews rendered as full-screen takeovers. Whenever an author defined a “Next Item” action in response to a particular event in the Item, the preview screen injected a dummy second Item so that the transition could be tested and verified.

To fine-tune the preview function’s performance, we added a “Reload preview” function so that authors could view their work without having to reload their browsers and risk losing unsaved changes to their Items.

Zero waste means greater efficiency

Learnosity ships in the region of 200 product enhancements per year, which is a good indicator of our commitment to setting a new standard for educational technology. But when teams are moving full throttle toward the next big innovation or tackling high-priority fixes, great features can sometimes momentarily slip off the radar.

Taking the time to review and repurpose them is like adopting a zero-waste approach to work to make things more efficient, effective, and sustainable.

Porting the Action Builder from the Author Site to the Author API gave us a chance to revisit a diamond in the rough and give it some polish. The net outcome of all that work is that both content authors and learners get the benefit of a superior feature.