The t.ux Activity Wizard
Streamlining the internal processes of an edutech company
The Team
Product Design: me and Zoe B.
Product Manager: Aaron Neeley
*A team of engineers is currently building this project
My Role
In my role as Lead Product Designer I performed in the following roles:
Research Organization
Design Strategy Sessions
UX/UI Design
Interface Design
Content Strategy and Writing
Component Design and Implementation into the Design Library
Design Reviews with Engineers
The Client
t.ux - An Educational Platform For Teaching UX Design Concepts
t.ux (teach UX) is an educational product aimed at helping those who wish to learn User Experience (UX) Design concepts.
Within t.ux are learning modules we call Activities, which consist of learning content and questions (see examples below) which teach and assess a specific topic related to UX.
Think of them like a text book with multiple “checks for understanding” throughout each chapter.
Project Overview
Scaling the process of building Learning Activities for t.ux
UX designers at t.ux were building Activities, but it was taking 4x longer than expected. Once the Figma files were approved and frozen, Engineers were turning those files into code, but it was taking 6x longer than expected.
How could we solve this time-wasting problem — help both groups speed up the process of building an Activity, and free them up to focus on building content and unique features instead?
After interviewing our engineers, I learned they were responsible for managing the content — they were having to source and extract images and content — and creating unique instances for otherwise templated material. This was not scalable. Through my own experience and interviews with fellow designers, I was able to confirm that designers’ biggest time-waster was pushing pixels in Figma — worrying about margins and spacing and components — rather than creating and editing content (which is where our main focus should be if we want high quality learning content).
Consulting with the rest of my designers & engineers (whom I regularly checked-in with throughout the process), I designed a unified solution to help automate and speed up the internal process of creating activities in t.ux. By creating an Activity Wizard, we were able to give our UX design team the ability to build an Activity and publish it live on the t.ux site, without needing engineer involvement at all. Here’s what our content creators had to say about it:
12/12 designers said it would speed up their workflow and eliminate wasted time pushing pixels around in Figma
100% of designers said the Activity Wizard would be significantly easier to use than their current way of working
The Solution
Several ideas came and went, but the most well-received was that of a builder-style wizard that engineers could build once, then never have to touch another Activity again —unless of course it had a special or unique feature.
Building an Activity
Designers can now add pages 1-by-1 until a full activity is built
Our users start with a pre-selected “Introduction” page that must be built first (All Activities start with an Introduction)
Once a page has been built, they are given the ability to build the next page.
They can build a Question page or a Content page.
They can continue adding pages until they have a fully built Activity. At any time they have the freedom to:
Rename the page
Edit the contents of the page
Delete
Reorder the page (drag and drop)
Preview the Activity
How did we get to this solution?
Originally, I wanted the Builder Page to look like this:
I wanted the designer to be able to drag and drop different page templates onto a pre-built “flow” to make it look a lot like a user flow.
The problem is, when I showed it to designers, the first comment I got was “Woah this is a lot.”
The point of a wizard is to simplify and direct your user, to make it so easy a 5-year-old can do it. So I simplified it.
Designer reactions to the Activity Builder feature:
“This is SO MUCH BETTER!”
“I like that I don’t have to think at all. I have 2 choices, name my Activity, and start building a page. Easy”
Building Question & Content Pages
Integrating the Question and Content pages into the Wizard
As you saw in the first feature, you get 2 choices when you want to build a page:
Content
Question
The Content Wizard page is simple, it looks like this:
User puts the templated information in the designated areas
Page Preview: this is how this content page will look for our designer’s user
The Question Wizard is more complicated.
We have 5 Question types that had to be integrated into the Activity Wizard. For times sake, here’s an example of the Question Wizard with a 2 answer multiple choice Question:
Here’s the Question Page Wizard
Designers can preview the Question, as well as what happens when the user clicks the correct or incorrect answer
How did we get to this solution?
We knew we needed to make these pages as intuitive as possible, so we wanted to mimic what the designers already know: the actual pages they have been and will be building.
So first, we had to templatize those pages, not only so we could mimic them in the builder, but also so we could give the page specs to engineers.
This was my attempt at making sure we fully understood the page anatomy, so we could properly templatize and organize information in the wizard
The Original Idea, in all it’s glory.
This is my co-designer Zoe’s 1st version of the Multiple Choice 2 Answer Question Wizard page.
We changed a lot from this original idea to the final version. We had to update our input fields for accessibility and consistency reasons. I’ll fill you in on what happened with the input fields in a mini-case study. They had to be redesigned.
As for the rest of it, we realized from early feedback that this was not an intuitive way for our users to build a page.
We work with a lot of visual people. They needed to see the layout of the page they were building as they were building it, similar to Figma.
This also did not mesh well with the way the Activity Wizard was built, so Zoe and I tackled this together, created new components, and came up with the result you see
Did the Design work?
Yes and no. The Question page needs more iteration.
The Bad
Our users found that using a modal to choose the question type from a long list was quite tedious. This idea is currently being re-considered.
Our users did not like having to click “Add Justification” in order to get a text input box, we plan on making this text box readily available
The Good
Our users felt the new layout was significantly easier to understand
Our users navigated the new layout more quickly with significantly less questions
Next Steps
We Are Not Done, the Activity Wizard Needs More Consideration
A list of considerations that need to be made:
Adding a “Save as Draft” feature
Determining who has say over publishing content live to the website (and how to restrict and allow access)
Determining users and the user flows for each level of access
Determining the animation used for reordering pages in the Activity Builder Page
Considering alternative methods to modals for selecting the Question or Content pages
Updating the Question Wizard so that all text input boxes are visible at all times (rather than selecting “add justification”)
Testing the current Activity Wizard on our users to get more input
Determining whether we need to adjust the page min/max for an Activity
What I Learned
Collaborating with Zoe, my Co-Designer
During this project, Zoe and I delegated the work. However, we were both working on pieces of a larger pie, so we understood the need to collaborate more, because each step of the wizard needed to maintain consistency. We also knew we needed to figure out exactly how this full activity building wizard would work. We spent a lot of time together in these weeks, figuring things out and talking through problems that came up. And I think collaborating in this way (and with the others) made this one of the interface designs I am most proud of.
Collaborating with Product Management & Senior Designers
Not only was I able to collaborate with my fellow designer, Zoe, I was also able to utilize our Product Manager, Aaron, as well as one of my mentors, Alyssa. I went to Aaron early and often with different ideas and he was able to help me maintain my focus and direction.
Collaborating with Engineers
It was also extremely useful to discuss with our engineers the feasibility of some of the features we were considering. Here are some of the the things I learned after showing the engineers what we were proposing to create:
I learned that it’s easier for an engineer to build another page than create a pop-up (at least the engineers we have). However, it might be worth the trade-off for them to learn the skills.
I also learned that it was much more involved for them to build a drag-and-drop image uploader than just having the image upload button.
I learned that it would be easy to create a text editing tool, but it would take them a long time to style it to fit our aesthetic.
Feature Iterations Chart
If you’d like to deep dive into all the features and iterations that went into each feature, please feel free to check out the chart of the Activity Wizard Features and how they evolved over the process of it’s creation!