The Engineer, The Designer, The PM & Their App: Building the New Yammer App for iOS7
Ron Blandford, Jenny Mullins, and McLaren Stanley
Ron Blandford, Product Manager:
“What proof do you have that it’s a better experience for the end user?” Those words echoed in the back of my head. It’s something Otis (our Head Curmudgeon Who Also Happens to Lead Our Team of Analysts) would say to challenge a product manager who wants to ship something without the data to back up the feature. This is the conversation I wanted to avoid.
We all knew, we just KNEW, that we had to update our iPhone app, but at Yammer we don’t do projects just because everyone else is doing it. Every project attempts to address a real user problem; as such, before we undertake any project, we need to have real goals based around metrics that indicate true customer value.
Jenny Mullins, User Interaction Designer:
Our main company app needed some serious love and iOS7 had JUST been released. All sorts of major companies were releasing their brand spanking new revamped apps, and our app was falling behind market expectations. With a UI that conjured up images of early nineties webpages and a UX that was as heavy as it was confusing, we knew we needed to make a major pivot with our signature iPhone product.
However, as a company that’s heavily analytics-based, the question was not “When should we start,” but rather “WHAT are we really trying to accomplish here?” In fact, you could say Yammer is all about the analytics. As a company culture, we think in terms of running “experiments” over building features or improving design. This isn’t to say we’re not passionate about great user experience or having amazing features, we just need to validate our assumptions using cold, hard data.
McLaren Stanley, Software Engineer:
Much like Jenny I had been pushing for the redesign for a long time. In the past, projects that were specifically centered around redesigning some part of our app had a funny way of turning into nightmares. They would usually go longer than necessary and they would block other feature projects from starting or finishing because the app couldn’t be released until the redesign was finished. The end of those types of projects typically had a whole bunch of engineers that came over from other blocked projects working toward a late deadline with a compromised scope.
Jenny, the Designer:
As a designer, the idea of giving the data all the power can be quite challenging. Ideas that I might take for granted (like the need to adapt to iOS7) are often questioned. It’s a bit like saying, “Hey, the sky is definitely blue,” only to be challenged, “Are you sure about that? Is it REALLY?” But while challenging and occasionally frustrating, this attitude is nonetheless a healthy one. It’s lead me to many valuable debates with PMs and engineers and ultimately cultivated my ability to step back and explain just WHY design is important.
And in many cases, the things that make for a cleaner design, are not necessarily always the things that increase engagement. It’s easy to design something that looks pretty and feels slick, but much harder to design something that looks pretty, feels slick and ACTUALLY IS a better user experience. And to understand what a ‘better user experience’ really is, you need to have measurable data.
Ron, the PM:
So we had to resist the urge to do an iOS7 redesign purely for the sake of having an app that looks and feels like a native iOS7 app; instead, we had to focus on the value we’d deliver to customers. We hypothesized that moving to a tab bar navigation would make it easier for users to navigate the app and find information that was important to them. We also moved to a card view. Here we hypothesized that by chunking information more efficiently (using the full side-to-side space) users would see more stories and therefore engage more with those stories.
Jenny, the Designer:
In the beginning our feed interface was extremely cluttered. There was way too much competing visual information, creating a cognitive overload for the user. From a design perspective, my job was to “clean house” to some degree, stripping out information that didn’t need to be surfaced to allow for a more focused and clearly hierarchied consumption of information. The question is, however, what information do you surface and what information do you bury?
McLaren, the Engineer:
If our project was going to be successful enough to prove its worth we had to get away from the stop-everything-and-redesign model. So we tackled the problem head on. Before we began our redesign project we switched our iOS App to a weekly release cycle. That meant even while our redesign was in progress we had to submit a stable version App Store six times before it was actually completed. So we had to hide all of our new designs behind turned off feature tests so we wouldn’t interfere with other features being developed at the same time. This also allowed us to phase in features like profile editing, and small parts of the redesign as they became available so that our users could start getting value from them sooner than they would have otherwise.
The effect on our ability to deliver code quickly was astounding. We could keep most of our engineers focused on adding features; we only needed a small team focused on the redesign. It forced us to write better tests and have a more robust regression plan. Since we constantly shipped the code, it was well-tested before we turned on the production version for the majority of our users. The final project shipped in record time without having to drop any of the scope we set out to tackle, and we even extended the scope to add extra features that we gathered from testing feedback along the way.
Ron, the PM:
Overall engagement is up, but we did find that two engagement metrics were down: Likes and Replies. This gave us key information about our app. Something about the card layout was discouraging users from liking and replying to messages. Now the redesign is out the wild, enabled for 100% of our users, but we know we still need to iterate on our design. Had we given in to the impulse to just do it just because, we would have missed out on a really valuable bit of feedback from our users.
Jenny, the Designer:
In the first round we made these decisions largely based on logical assumptions, user testing and existing knowledge. Many of the decisions ended up being validated by our experiment: Overall, we had a huge jump in engagement after deploying the redesign. However, there were a few areas where the numbers didn’t support our assumptions. As it turned out, a couple of the elements we stripped out to create a more simplified design ended up being really important for engagement.
So while it was extremely tempting to jump right into the design and start moving things around, taking the time to measure results and validate our design assumptions turned out to be hugely important. In the end we didn’t just get a pretty face, we got a better design.
Ron Blandford is a Product Manager, Jenny Mullins is a UI Designer, and McLaren Stanley is an Engineer. They all work at Yammer. They’re a dreamteam.