If you’ve been hanging around the UserTesting blog over the last month, you may have noticed some big changes! In January, we launched a redesign that presented a bolder, more visual interface and a simplified navigation.
Our blog before (left) and after (right)
Before we started our design process, we knew we wanted user feedback to be at the heart of the new blog. We decided to test early and often: from concept development to prototyping to staging.
In this post, we’ll show you the different stages of our design process—and how user feedback fit into it.
Phase 1: Exploratory research and defining goals
Before we started to design solutions, we first wanted to identify the problems we actually needed to solve.
In the months before we started designing anything, I ran periodic user tests on the blog to find out how people interact with it naturally, discover content that’s interesting to them, and use search and navigation. I kept a running list of potential improvements from this feedback so we’d have a user-centered starting place when we began the design.
Our content marketing team started our own personal wish list of features and design elements. We spend a lot of time on the blog every day, so we already had ideas about what could be improved—as both readers and authors of the blog. We also kept a list of other blogs for inspiration. Along with each one, we added a short description of what we liked, whether it was the look and feel, a particular feature, or something else.
To kick off the project, the content marketing team met with our designer, Kiley, to share our ideas for improvements and talk about what we ultimately hoped to achieve. Together, we identified four major goals for the redesign:
- Present an updated brand and a more visually appealing interface across all devices
- Simplify categories so that it’s easier to find relevant content
- Make it super easy to sign up for our newsletter
- Declutter the screen so that it’s more enjoyable to read the content
Phase 2: Initial design and internal feedback
Kiley took our goals and the wish list of improvements and mocked up a few different wireframes in Illustrator.
Three of our early wireframes
Kiley shared the wireframes with our internal stakeholders: the content marketing team; Leah, our Website Marketing Manager; and Phil, our VP of Marketing. After all of the stakeholders had shared their initial thoughts, Kiley had enough information to refine her designs and make a more detailed set of wireframes.
At this point, we shared the wireframes with our developers and talked about the key functionality and scope of the project, but they didn’t start building anything yet.
Phase 3: Prototype testing and iterating
Of course, we all know that internal feedback alone isn’t enough to create a user-centered design. We wanted to test out our design hypotheses with real users to verify whether we were on the right track before moving into development, where it would be more difficult and expensive to make changes.
Kiley loaded her wireframes into InVision, our prototyping tool of choice. Leah conducted a few quick user research studies on the Invision prototypes to get users’ thoughts on the look and feel of the blog and find out their expectations for the functionality. We also wanted to get early feedback on some of the new design elements like the sticky header and the Subscribe button before committing development resources to them.
Our mobile wireframes in InVision
The first thing we learned was that our test participants thought the design looked clean, and they were able to find their way around quickly. Since our prototype was low-fidelity, we asked questions like, “Please show us what you would do to share an article on social media, and explain what you think would happen.” This helped us understand if our design met user expectations.
We also shared the prototypes with some other internal stakeholders on our Marketing team and our Executive team to get another set of fresh eyes. While several team members had strong (and very different) opinions about some of the design decisions, Kiley was able to align the team around the feedback from the end users.
We also learned a little more about setting clear expectations within the user test. We had used Bacon Ipsum as filler text in the wireframe, but we didn’t mention anything about it in the test instructions. That confused some users, who wondered why the content was a mix of Latin words and types of meat. Lesson learned: The next time we test a low-fidelity prototype, we’ll make sure test participants know that they’ll be looking at placeholder text, not the actual content!
After a couple more quick design revisions, it was time for our development team to get to work.
Phase 4: User testing during development
At this point, we felt confident that our design was on the right track, so we didn’t expect to have to make any major changes. Instead, we wanted to zero in on any usability problems or confusing interactions so we could smooth out the user experience.
Once the new blog was on the staging environment, we ran another round of user tests on desktop and mobile to watch people go through a few key workflows:
- Finding an interesting article
- Browsing through the most recent content
- Using the search bar
- Signing up for the newsletter
- Sharing an article on social media
- Exploring the blog as they naturally would
To do this, we used our newsletter to recruit a custom panel of people who read our blog regularly. We also recruited users on our own panel who matched our target demographics.
The feedback we got from watching people use the blog on a variety of different devices inspired us to refine our mobile navigation and category pages. Kiley reworked the mobile menu to make it more user-friendly—and to save a little space on the screen. She also changed the layout of the category pages for a more enjoyable browsing experience.
The evolution of our new blog’s mobile navigation, based on user feedback
Our development team made the changes, and we ran another study and got some rapid user feedback that confirmed the new mobile navigation flow was more intuitive. Then we moved on to QA and got ready to deploy.
Phase 5: Launching and listening
On the day we launched, we didn’t have to worry about whether our new blog was usable or whether users would be able to find what they were looking for. Since we had already confirmed what worked (and fixed what didn’t) during design and development, we were able to focus on ensuring a technically smooth deployment and getting the word out about the new blog.
Incorporating user feedback into our design process from the very beginning saved us from a lot of uncertainty, and it helped us align the whole team around user-centered design decisions. Instead of arguing back and forth about our own opinions, we could easily see what made sense to users (and what didn’t) so we could make changes and move on.