About Face: How About.com Changed its Design Process and became Dotdash

This was written for UI22, last year’s UI Conference. If you want to attend this year’s UI Conference. Check out the presenters for UI23.

According to Heraclitus, the only thing that remains constant is change. The internet itself has evolved exponentially over a relatively short amount of time. Few relics from the early days of the web remain, and those that have, have been forced to change.

Adam McClean is the SVP of Product at Dotdash. Dotdash was once About.com. The very same About.com that has been around for 21 years. Adam and his team were increasingly aware that the landscape around them was changing, and that they needed to evolve. They made the switch to a new brand, Dotdash, and a new process, to keep up with technological and market changes.

Dan Mall, who runs SuperFriendly out of Philadelphia, joins the podcast to share his views on the evolution of dotDash’s process in support of their new brand. Dan will also be teaching one of the daylong workshops at UI22 this November 13–15 in Boston, MA. He’ll show how to develop workflows for the multi-device world we live in.

Full Transcript

Jared Spool:This is the UIE Podcast. I’m Jared Spool.

At night, when you peer into a telescope and look out into the solar system, you are in essence traveling back in time across light years. You are observing a distant past, even though it might feel like the present.

Imagine, if you will, that you could travel back in time to 1999. You might not believe it’s possible, but Billboard’s hottest song of the year is Cher’s Believe. You’re a kind person. You’ve just rewound a few VHS tapes that you need to return to the video store. You’ve printed out some MapQuest directions for an upcoming trip. The news is going crazy over this Y2k thing, like it’s one of Nostradamus’ lesser-known prophecies of doom. You’ve pulled up Netscape and searched About.com for a guide on the history of nutty doomsday prophecies.

The Internet was still a baby in the late 1990’s, or maybe more of an inquisitive toddler. In the age of web portals, About.com was king. It was the perfect model for its time, offering informational guides and articles on all sorts of subjects. But like all things, the site grew older, and bigger, and so did the Internet. And now our time portal is getting shaky and collapsing.

We’ve returned to 2017, and portals are a thing of the past. The Internet is in its snarky, know-it-all 20s now. The only constant we have is change, and for change to take place, we need to believe it’s possible.

Change is what About.com needed. The site had millions of pages of content, an outdated technical infrastructure, and still millions of daily visitors. But it hadn’t grown up. It needed to evolve.

Adam McClean:We took a hard look in the mirror and said, “What do users really want? The brand is 21 years old. It is older than Google. Everyone has experienced it in some fashion when it was a portal and heavily monetized with text ads. That is the perception regardless of what we did now. That is perception that is going to carry through.

We were all desktop oriented because we are on desktops at work, and so the designs would start there. Our competitive analysis would start there. Despite user research and then analytic showing that the majority of our users are on mobile. I just knew in my gut something had to change.

I am Adam McClean.

I’m the Senior Vice President of Product at Dotdash.

Jared:After updating the technical infrastructure, investing in people and skills, and doing all of the typical market and user research, About.com realized it needed to break its brand into six, unique theme-based sites with content from lifestyle to travel. These six sites live within a new parent company, called Dotdash.

Adam:We killed over half of our content, redirected millions of documents to the right corpus for each vertical and then went through this product development methodology change and built the brands in 12 to 16 weeks and launched them in the market and we’re seeing phenomenal growth.

Jared:Building and launching a brand in 12 to 16 weeks sounds challenging to say the least. But for Dotdash, it was the culmination of a process they’d been working toward for years.

This process prepared the business to adopt a product methodology for rapid development. But it took time to get there. They started out like a lot of companies that want to embrace change.

Adam:We thought of ourselves as very traditional, agile oriented. We did two week sprints, we did the agile manifesto, we did scrum and stand ups. We still do all of those things. When it came to executing something where visual design was a component, it was a handoff. It was also a handoff between product managers and the engineering teams which is also a small mini waterfall where we gathered every requirement possible and then handed it off into small bite size stories.

We would iterate again and have feedback from a number of stakeholders and team leaders. We would be measuring things in weeks at this point. We would be at least a few weeks in. Then, we’d come up with the final design. It would most likely be desktop only and then we figure out what it should look like on mobile with another pass and then it would be specced out. Red lined, specced out, every color hex value, every pixel, font size, every piece of it, and then hand it off and estimated in engineering team who would then go and spend weeks executing it.

The time that it took to get to consensus for a design that had no code against it and was not actually evaluated in the real world, in the browser. The time and the amount of revisions that it took for us to get through those design reviews was painful when you actually look at it in a macro sense.

Dan Mall:In a lot of large companies, they are very siloed. Everybody has their jurisdiction, and they don’t realize how connected their experiences are supposed to be. They just think we can operate in our little silo. And more and more, digital experiences are connecting consumers and customers. And if I’m using the website, I might also be using the mobile app. And if I’m watching a commercial, that’s how consumers deal with brands, but brands don’t organize themselves in that way.

And I think the spoiler to this process is it’s got to be collaborative because people experience things holistically. People experience brands holistically even though brands aren’t setup that way.

My name is Dan Mall.

I run an agency in Philly called SuperFriendly.

At UI22, I’m teaching a full day workshop on Design Workflow for a Multi-Device World.

Jared:Dotdash hadn’t organized its teams to work in a holistic, collaborative manner. To get their teams on the same page, Adam started with a component audit. It’s a simple exercise that measures how consistent their visual design is across their sites.

Adam:Our engineers found eight versions of a Facebook button in code and eight different designs of it as well on one site that should be consistent. That was also another light bulb moment of wow. Both from a design system standpoint, we need the consistency and the code standpoint, why weren’t they able to reuse components? Why wasn’t the architecture actually setup to make things reusable as opposed to one off specific isolated incidences.

We had a couple of engineering teams that could develop on the site. We had a handful of designers that could design various projects and they were just assigned to the next thing on the roadmap. No one was taking ownership of a responsibility for the full design system. It was, I’m tasked with this job to be done or this persona for this product piece that I need to develop and you locally optimized for that. They were some branding and some colors and some global things that we always try to be consistent with. When you got down to the actual code, things were different. Things could be coded very differently locally and so it was up to the engineering group and the designer at that time. They didn’t have tools to see that the Facebook buttons were all different. No one was looking broadly. We didn’t have a pattern library developed. We didn’t have any of those tools to help us avoid some of those pitfalls.

Jared:That light bulb moment for Adam and his team was the lack of communication between groups, and the wasted effort of redesigning elements that should have been re-usable. They realized they needed to restructure and rethink how they worked together from the ground up.

Dan:With Agile, you can break down things into small chunks, but the problem is when you break things down into small chunks, people can work independently. And the thing that was really missing there was, and really part of the thing that we try to encourage more and more, is okay, let’s sit together and work this out. So rather than a designer breaking out a small chunk and doing that work and then a developer or an engineer breaking out that small chunk and doing that work, instead we were trying to encourage them to go, “Let’s sit together and do those small chunks of work together in front of a whiteboard, in front of a Sketch book, and talk about those things.”

Adam:That led us down this road of trying to implement some change in methodology that was closer and would use that component based design structures and systems. Then we were tasked with re-branding into Dotdash and we said, “Well, this is the best playbook that’s out there right now. Let’s give this a whirl.”

The whole team, product, design, engineering are working together collaboratively throughout the process. The amount of energy and time spent for each discipline changes from beginning to end but everyone is involved and everyone has input throughout. There isn’t a spec sheet or requirements list that literally gets handed to somebody to then go design or to go engineer.

Jared:That playbook that Adam and his team chose was a designing in the browser, Atomic design approach. They looked at their design elements to create a library of patterns and components they could re-use. They restructured teams around each new brand to work collaboratively and cross-functionally.

Adam’s teams would now sit together to design and build elements and get them into the browser as quickly as they could to view, test, and iterate. And they did it all without defining product requirements…

Dan:Almost every organization I work with has this where we have to spec it first. And we have to spec it perfectly. And then as soon as we spec it perfectly, everybody can do their jobs after that. And I think that is a common misconception in doing software work because people that are doing software work, engineers and designers, they all have great ideas that can contribute to the work. The whole idea of Agile is the idea that you can flex. You’re flexible. You’re not following a plan, but instead you’re responding to change. When you spec first, there’s no ability to respond to change because what you do is you destroyed the spec as soon as you flex off the spec you destroy it. And a lot of teams see that as detrimental.

Usually the person writing a spec is a product manager. And a product manager isn’t as intricately familiar with the engineering or with a design technique or with a way to build something or responsive images or whatever those things are. So if one person is responsible for the spec, they have to know everything about a project and about a product which is very unlikely. Instead if you’re using the smarts of the team rather than the smarts of one person, you get a lot more ideas. You get a lot more riffing, and you get a lot of people to go, “Oh, don’t worry about sketching that out. I can actually just do that in the build” or “Don’t worry about even building that. Let me just do a little prototype for you so you know what I mean.” It’s an opportunity to save other people work whereas if you’re writing a spec, you don’t have to talk and then you end up doing that rework all at once.

Jared:Old habits die hard, and teams like Adam’s are accustomed to working in a specific way. It requires a leap of faith to fundamentally change how you do something. Dotdash experimented with their new methodology by first running a test project.

Adam:We did a special cross-functional, atomic design approach project for something that was a very specific one-off product. We were building our new map product for our travel site. It worked effortlessly, flawlessly, everyone across the entire spectrum of the organization really liked all the pieces of the process and how everyone was energetic about it and final outputs of everything from the time to market. When it came to trying to tackle six vertical brand build outs in a year, we felt like we had tested a playbook that would work but we had to shift the entire product development organization into this world .

Dan:You’ve got to have at least some amount of risk tolerance to say, “It’s okay if this is a flop. It’s okay if this doesn’t work for us.” [So] I find it more difficult at organizations that aren’t willing … that are just so tightly held to their previous process that anything new is such a big deal. If they’re not ready to embrace the change, then this is probably not the right time for it. And I think timing is a big aspect of this kind of process. The organization has to be ready for it. The people that are going to be working this way have to be willing to do it, willing to try new things, willing to learn new things.

Jared:Time to market and risk mitigation were critical pieces for Adam and his team. They were on an aggressive timeline to launch the six new brands. Teams didn’t know what the final product would look like, but they had to start coding and designing. In a browser-first approach, rework happens throughout development. That was another thing the team had to get used to.

Adam:There was some resistance. At the end of the day, everyone really had positive feedback. The market liked it. The engineering and design and all the teams liked it. There is some resistance to this concept of feeling like there is rework. You code something up, you guys get it working, and then you see it, and you need to adjust it a little bit. That actually means everybody throughout the entire cross functional sec might need to make code changes to make that small change happen. That was a frustration point that we had to work through and talk about and deal with especially on the engineering side to get to a place where everyone understood that rework was possible, rework is going to have to happen. Instead of forcing all of the rework up front to the designers who were used to doing multiple revs, we spread it out and made time to market a priority.

A good part of it was being able to show everyone involved with the project how much better the end result was, and that instead of trying to make things perfect at every step you actually get something better faster if everyone is willing to be flexible and iterative in the moment. This was actually hard for our agile managers and scrum masters to fit into the traditional scrum model. We had to develop ways of basically time boxing some of this iteration. They always want to put points, they want to be able to track it, they want velocity, and that’s all really helpful. But what it doesn’t do is it doesn’t always give you the exact flexibility. You have to have some gray areas, some unknowns and be comfortable with that and know that your team can work through them in the time allotted.

Jared:Not only did the team have to become comfortable with the unknown, with those gray areas, team roles blur in this methodology. It can be a challenging adjustment, especially for designers and engineers.

Adam:In the old mini waterfall model, the designer as the last piece would be thinking through, “Well, when they click on this, what is the IA? What is the open? What is the hover? What is all those little pieces?” Now we just go straight to the browser and we do the … “This feels weird, why isn’t it reacting the way I want with my mouse? Oh I know! I can do a button hover state.” The engineer goes in says, “Yeah, I fixed that. It felt weird when I was building it so I just put it in for us to talk about.”

They are designers as well. They’re thinking through user interaction and hover states. Everyone is empowered but especially the engineers are empowered to ask, “Is this new or are we reusing something we already have because I can reuse something right now and then you tell me if it’s working or not.” We start from what can be reused, throw all of that on a page or the template, whatever it is first, and then try to figure out what’s not working and figure out what has to be net new.

We, now, because we call it designing in the browser, we think of everybody on the team as a designer in a different way. They all have ideas and thoughts and they’re all users of the web. They’re all users of our sites luckily enough that we’re so broad that everyone has a need for something that Dotdash can provide. The actual traditional designers, the ones that design tiles are coming up with concepts in sketch or in vision and they’re trying to use real data to actually make it feel as real as possible. They get about 60% done. Then they put it in code and the engineers have a chance to play with it, break it apart, and actually design some of the UI and the interactions that this 60% done probably hasn’t uncovered, hasn’t really thought through.

Dan:I think one of the first parts of a process like this is you’ve got to break that down at least a little bit. Because in designing in the browser, who does most of the design? The front end developer. And that’s often a new role for the developer because what a front end developer is used to is, “I get a comp and build what’s in the comp. I faithfully reflect pixel perfect what is in that comp.” Now all of a sudden you don’t have a comp. And so it’s a distribution of roles. It’s a distribution of the effort, and so it means moving a lot of the designer’s work to the developer.

And designers have a lot of fear of that, too. “Well, okay, if they’re doing all the work, if they’re doing all the design work, well what am I doing, too? Am I useless here? Am I redundant?” And what it means it’s actually moving some of the development work to the designer. So that could be something like managing a design tokens file or managing a JSON file. So that the developer can work on things, and the designer can tweak colors to their heart’s content. That’s a very different kind of work flow than they’re used to of “I’ll figure everything out in Sketch, and then I’ll figure everything out again in front end dev, and then I’ll figure everything out again in engineering.” So a lot of it almost requires breaking down these roles, and saying, “Even though your title is front end developer, you’re going to be doing a lot more design work. Even though your title is designer, you’re going to be in the code tweaking CSS values a lot.” So a lot of it is just getting familiar and comfortable with that idea.

Adam:For the engineers, I also think there was some challenges and some friction with encouraging to have ideas and input and not just thinking through execution but actually thinking through discovery and solutions and how what we were building matched to the brand promise and design principles. These things that are usually off for the designers to talk about or off for the product managers to think about with marketing, we involve as much as we could all of the engineers in developing our onliness statement. What is our competitive positioning for these new things? What is our manifesto going to be? How are solving problems for users so that they have that information when they go to make design decisions in the code? They were exposed to things that we never exposed engineers to before.

Dan:A lot of people’s identity is tied to their roles. They spend so much time at work, and one thing that’s great about this industry is people love what they do. So they tie their identity a lot to this role. And if that role disappears or if that role changes, does that mean your identity changes, too? If you are the senior designer at a company, and all of a sudden somebody else is doing more design work in the browser than you, are you less valuable? So there’s a lot of baggage that comes with that. And so I feel like any good consultant, a lot of your work is therapy. A lot of your work is getting people comfortable with this and making sure they’re okay with it, and making sure that they’re not losing themselves in their job or they’re able to separate those two things.

Adam:Some people were very excited and very happy about it and some of them had experienced it at previous work environments and craved it. Then there were other people who thought, “This isn’t the best use of my time. I should be coding right now. That’s just what I want. I want to be a heads down engineer.” But we have, I think, done a very good job of helping people see the value. Once they go through one of these, we did, everyone had to be a part of at least one if not two big vertical brand builds. By the end of it, everyone really understands the value and appreciates they’re involved.

Our designers are now actively managing the pattern library, which they are able to commit code changes to our pattern library product. Our engineering or architecture actually auto-generates the pattern library from the components that are in the code. Then there’s an orchestration and organizing structure on top of that that the design, everyone can, but mostly the designers take ownership over constructing and organizing the components in the pattern library.

Without this new working methodology, without the actual architecture that we helped to develop to make things, components and auto-generate pattern library and support this new design system, it’s not just the design system and methodology. It’s actually baked into our architecture and code now. Having all of that work allows us to launch some new verticals in weeks. We just launched liveabout.com which is our fashion, style, small, very seventh vertical, in three weeks start to finish.

Dan:I think one of the biggest things that they need is permission. I think sometimes you need someone to go, “You can do it. Give it a shot. And if it fails, it’s on me. I’ve got that.” And I think any good manager or any good consultant or boss, I think that’s part of the job is to be able to say, “I’ll give you a little bit of a safety net to try this.” And again going back to that test bed or that experiment time, it doesn’t have to be, “I’d like to try something for the next two years.” It could be, “I’d like to try a process or a technique for two weeks and see how that works.” And then if it doesn’t work, we adjust or we revert back. But sometimes just giving people the permission to go, “Yeah, you should do that. I think that’s good.” I think gives them enough of a confidence boost to be able to do it.

Jared:There is no measure that we can use to tell us what the future holds. If we swap out telescopes for Magic 8 Balls, we get a “Reply Hazy, Try Again” as often as we get an “Outlook good.” It’s hard to believe in the weight of those responses.

We try to predict future outcomes so we can control them, mitigate risk, and feel safe about the choices we make. We often interpret change as something scary, hard, and involving a level of risk. But if we aren’t willing to change, change will come to us, eventually.

Adam and his team learned to believe. They created a level of trust for designers and developers to work in this new model. They fundamentally changed their process, how their teams work, and their business. They got permission to experiment, and they controlled risk by seeing things right away, in the browser, and course correct throughout their work to guide them to a successful place.

This UIE podcast is brought to you by the UI22 conference that’s happening November 13–15 in Boston, MA.

I’m very excited about Dan Mall’s full-day workshop, Design Workflow for a Multi-Device World. He’ll spend an entire day sharing his proven approach to taking designs from concept, all they way through delivery, across multiple devices. It’s a great way to quickly get your applications delivered while delighting your audience with the functionality they’ll love.

To learn more about what you’ll learn at Dan’s workshop, visit Uiconf.com. That’s U I C O N F dot com. If you use the Promotion Code DANPODCAST17 (that’s all one word DANPODCAST 1 7), you’ll get $200 off your UI22 registration.

Now, if you haven’t been to U I E dot F M lately, then you may have missed our recently revived podcast show, the U I E Book Corner. In this show, Adam Churchill and I talk about new user experience books that should be high on every designer’s reading list.

In a recent episode, we looked at Brett Harned’s wonderful new book, Project Management for Everyone. At some point, every designer finds themselves managing a project. Adam and I talk about why this book contains the critical knowledge necessary to succeed. Visit U I E dot F M and click on Shows to listen to the U I E Book Corner episode about Brett’s book.

This UIE podcast was written by Kathleen Barrett and produced by Sean Carmichael. We’d like to give special thanks to Adam McClean and Dan Mall for appearing on this episode.

This podcast is part of the UIE Podcast Network. Thanks so much for listening and, as always, thanks for encouraging our behavior.