Twitter.com is a pretty big deal with 300M+ visitors per month. Because of the impact of Twitter and how it is interwoven into the lives of people using the service, it was important to us to let their voices be heard as we developed the new site in order to create an experience that met their needs. Throughout the entirety of this massive endeavor, collecting feedback and making iterative progress have been woven into our processes, our goals, and our milestones.
From the onset of rebuilding the new twitter.com, we had an abundance of thoughtful feedback on what did and didn’t meet expectations from fellow Tweeps and from the people that were giving the site a try in its early stages. While a lot of the feedback was positive about the change or related to features that we hadn’t been able to ship just yet (like keyboard shortcuts and Tweet translations), there was also a theme that emerged around a certain set of expectations while using a laptop or PC. It should feel fast. It should feel like a rich experience. It should feel personalized. It should feel ready for whatever task you throw its way. It should adapt to its available space. It should feel “desktop-y”. Making sense of what exactly “desktop-y” meant was not going to be as straightforward as adding a missing feature but was an opportunity to explore and iterate.
In order to begin to parse and interpret the feedback, we collaborated with Research and Data Science to help synthesize the themes and to identify needs that the people using twitter.com had. With this clarity, we started exploring many different navigation and layout treatments that began to feel more adaptive to the available space on desktop than the treatment at the time had. These explorations were meant to expand the imagination of the team as to what were different ways of thinking about the product. While some of these ideas could have felt far-fetched and difficult to achieve based on where we currently were, the explorations tried to showcase a multi-stage approach of small but meaningful changes that led to the ideal state. Setting up this iterative process from the start helped get buy-in from the team and get everyone excited for the future.
Once we had a vision for the direction we wanted to move forward with, we decided to begin with building an engineer-led prototype. The purpose of this was to de-risk the project, lower the upfront engineering investment, and get feedback as quickly as possible. Even though we were excited about the design explorations, we wanted to feel confident with how the change would be received by people and if it addressed the core of the feedback. In this case, “prototype” did not mean using fake data or using a prototyping framework, but rather building the new design directly into the code on a separate branch, without worrying about making it production-ready.
Right from the start of using the prototype, while there was still lots of room for improvement, the experience instantly transformed into something that felt more dynamic and natural on a large screen. The navigation and side column responded to the size of the screen, feeling adaptive. The side navigation provided the opportunity to include features that were hidden before, like Bookmarks and Lists, as well as building the framework for additions in the future. To validate our reactions, we started by sharing this initial prototype with the core team to get first impressions and thoughts.
After compiling feedback from this small group and brainstorming improvements, we jumped right into making changes within the prototype based on the comments provided. We were able to iterate on the prototype quickly because it was in a separate branch of the codebase. Trying out new ideas would take less than an hour and often we updated the prototype multiple times a day. Once we felt confident with this set of revisions, we invited the company to try out the prototype in order to really gauge if this solution was addressing the core user problems. We included a visible prompt for those in the prototype to provide their thoughts and we continued to iterate based on feedback.
To validate if these changes met the expectations of people using the site, we again worked with our Research partners to run user testing sessions with actual people that use our website. The study included having people go through a series of tasks, which they ordinarily may do while using the site, with both the prototype and the beta version of the site in order to gauge ease of use and preference. Much to our delight, the side navigation experience was perceived as feeling more natural on a desktop experience, it felt clearer how to compose a Tweet, the exposed labels made the site feel easier to understand, and it presented content with a clearer hierarchy on the page.
Throughout all of this iteration, it was important for us to be transparent about what was working, what wasn’t, and what direction we were heading. We involved the rest of the team in brainstorms to consider problems and contribute solutions, as well as sent out frequent messages about changes and calls for additional feedback responses. Because Twitter is meant to be a place of public and transparent conversations, internally we want to work in a manner that also showcases this form of communication in order to build trust.
Once we decided to productionize the prototype, we needed to figure out how to fit this redesign into the larger rollout plan of the new website. While the employee feedback and user research results were both encouraging, it was still important to run an A/B experiment between the top navigation treatment and the side navigation treatment to both gather quantitative results and get a larger pool of qualitative feedback.
We launched two separate experiments with the new navigation, one in our Twitter for Windows app and another when we switched some people to the new twitter.com. Both experiments provided valuable quantitative data, that combined with the user feedback we were collecting, told us how people were using the new side navigation. Based on this new data we continued to iterate and improved the placement of navigation items, color contrast, added easy access to the profile, and more.
Our main takeaway from this aspect of the project is that iteration and a strong focus on feedback will truly lead to higher quality results for the people that use our products. Iterative design and development does not mean repetitive work or jamming everything into a two-week timeframe. It means you put something out there, you receive feedback, examine what worked and what didn’t, and you improve it. Again, and maybe again, until it solves the problem. It is both valuable and beneficial for an organization to be able to support this kind of process and for those on the team to be open to consistently revisit work and decisions made. We hope that you all enjoy the new site and expect to see us continuing to make it better.
Did someone say … cookies?