Autotune Redesign
Lead product design, visual design, user testing
In June 2015 the Editorial Products team launched Autotune, a centralized management system for interactive storytelling tools. At launch, we released 3 reusable project templates, called blueprints: a sortable table, an image comparison slider, and a headline randomizer. We’ve also added multiple chart types, a multiple-choice quiz, a flowchart, and many other blueprints.
Our first priority after launching Autotune was to create as many blueprints as possible to make it possible for editors to create embeddable graphics. It soon became clear, however, that the creation process was less than ideal, and we needed to re-evaluate the product.
Below is a case study of the entire product process.
Autotune was named a finalist in the 2016 Online Journalism Awards for technical innovation.
User Interviews
Goal
As a team, we needed to understand our users. We wanted to learn more about their current use of Autotune, as well as their ideas about what the tool would do in a perfect world. We also wanted to learn more about where the product fell short.
Logistics
We interviewed writers from our 8 brands. Between the engineers, the product manager, and myself, we interviewed 16 different Autotune users in order to identify — at a high level — how they used the product.
From there, we identified key users to walk us through exactly how they created, saved, and previewed projects within Autotune. Some questions we asked them to walk us through were:
What would you expect to happen when you make a change to your project?
How would you expect to preview your changes? How would you preview them across breakpoints?
How would you expect to save your progress?
Key takeaways
One of our biggest takeaways was that our users felt that Autotune didn’t predictably or reliably save their projects.
Divergent and Convergent Conversations
Goal
After user interviews, our divergent conversation allowed the entire team to share their ideas and to get those ideas written down. Then, as a team, we had to agree upon the scope and direction of the project.
Logistics
I led a divergent conversation where I shared key takeaways from the user interviews, posed a few open questions, and we had an hour-long conversation with a dedicated note-taker.
From there, I led a convergent conversation where we discussed the big ideas that came from our divergent conversation, the problems we needed to solve, and what was out of scope.
Key Takeaways
Based on our conversations, we identified some key areas we could focus on for this project. They included: leading the user through a clear set of steps to complete their task, ensuring the user didn’t lose work, and making the editing process more clear.
Product Brainstorm
Goal
After agreeing on scope and direction, the team came together to brainstorm as many solutions to our problem as possible. By gathering the entire team, everyone was able to provide their own insights to inform the product.
Logistics
I led engineers, product managers, and designers for a 2-hour sketching session. We did a combination of group activities, like white boarding; and individual activities, like sketching. After each round, we shared our results with the group.
KEY TAKEAWAYS
During our brainstorm, it was clear that we should implement some type of WYSIWYG editing experience, create a focused and simplified user flow, and explore some type of clearer saving mechanism.
Iteration 1 of the wireframes.
Wireframes
GOAL
I needed to test our sketches using basic content and assess whether the user flows we discussed made sense.
LOGISTICS
I collected the team’s sketches from the product brainstorm and began wireframing the experience of creating, editing, and publishing a project in Autotune. We conducted several rounds of revisions and design reviews in order to iterate on the wireframes.
Key Takeaways
Based on team design reviews, we streamlined the editing experience and combined the form and preview into one screen.
Low-fi clickable prototype created based on wireframes for user testing.
Prototypes and User Testing
Goal
After doing many revisions on the wireframes and conducting team reviews to refine the design, we needed to test the work on users to see if our designs were effective.
Logistics
The product manager and I worked together to create a script, identify users to test, and conduct the user tests. We recorded the sessions, and had a dedicated note-taker for each session.
Key Takeaways
The main thing we learned from sharing this prototype with users is that they felt it was a huge improvement on the current experience. Most of the feedback was focused on small details in the editing experience. Users didn’t feel that separating out advanced options was necessary in the editing sidebar, for example, and they’d rather see the full range of options.
Navigation iteration, designed while considering navigation across breakpoints.
Refinement and Iteration
After user testing, I worked closely with the lead engineer to continue refining the design based on takeaways from user testing and team design reviews. As the engineer worked on building out the changes, we identified issues with the design and iterated in code.
We also spent a small amount of time finalizing the visual design of Autotune. We borrowed the main visual design from another internal product and we had a solid baseline, and only had to make a few changes to make the design work for our needs. I tested all of our UI colors in order to ensure they had sufficient contrast.
After rolling these changes out to users, we made small tweaks to address bugs and any issues that came up, but are planning to keep Autotune largely as-is for now.
