Not just a new episode, but maybe the LAST episode, at least of this first “season,” in which we have successfully interviewed friends and web luminaries about 24 different stages and phases of the web project process. From determining what it is, to keeping it alive after it’s launched, this podcast series has been a lot of fun.

We’ve called in a lot of favors, and this last episode had been penciled in for a while: David Hobbs joined us to discuss the move from project to product — from something you’re building, to something you’re OWNING.

From our interview:

Corey:

Tell us what you mean when you say after launch that a website has moved into becoming a product. What do you mean by product in that sense?

David:

Broadly speaking, when I’m thinking about a digital presence needing to be treated like a product, I’m thinking about maintaining it for high quality over time. And a lot of what that ends up meaning is when you’re making changes to be business first, so prioritizing based on what the business needs and to think broadly and long-term.

And a lot of where the rubber hits the road is actually in features because that’s an amplifier. And when you spend money on your site by implementing a feature, especially in the publishing process or maybe in the front end. It’s this amplifier. It’s not just you’re paying for the one thing.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

I recently used a weird metaphor when talking about the web process: a site launch is, essentially, a kind of birth. A lot of work and planning and personal maintenance go into making sure birth is a smooth process, that everyone is safe and healthy and ready to thrive. But you don’t stop there. You don’t have a kid and then say, “Cool, everything’s great!” and move on.

Instead, the bulk of the work is in the ongoing “maintenance” of that kid. The raising, the teaching, and the safety of that kid. Birth was a starting point, just like a web launch.

The metaphor falls apart after a while — websites eventually need to be rebuilt and redesigned, and you can’t really do that to a kid — but the sentiment is there: you can’t just set and forget a kid, just like you can’t set and forget a website.

This month, we chatted with our friend Meghan Casey about content and web governance, specifically about how launch isn’t a freezing point for content — on the contrary, it’s the starting point.

From our interview:

Deane:

How do we reorient our clients towards what I would call incrementalism? We’re so obsessed with launch, but we’re also obsessed with Big Bang cycles. Launch, do nothing for three years, and then redesign the entire website.

I always thought the greatest web operations strategy would be one that maintained and did routine maintenance so you didn’t have to fight these fires all the time, and I don’t know how to get clients to totally understand that.

Meghan:

I think a lot of it is just doing it with them.

If you can get through at least one round of “we’re going to take a look at the content quarterly” and “we’re going to figure out what might need to change” from different types of content. Having some proofs of concept.

Again, I don’t always get the budget to do this kind of thing, but I think a lot of it is just doing it and then seeing how it works, and seeing how it actually makes life easier. Like, “Oh, what if we did look at this every year, instead of every five years being like, ‘Oh, shit, look at all of this content that nobody cares about.'”

I think it’s a lot about showing the effects of it. I think money talks — time talks — so if we can really demonstrate the effects … I don’t have all the solutions, but I think a lot of it is demonstration versus just saying, “This is important.”

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

I started in this business as a QA practice manager. It was a weirdly perfect transition into the world of web strategy because it was a weirdly satisfying immersion into what made a website work. Like how UI and UX decisions “butterfly effect” their way to the development environment, or how content modeling decisions require a consistent line from ideation through to launch.

The few weeks before a site launch feel like a frantic swarm to the finish, but there should be no surprises at this point. Easy enough to say — even though we’ve made a plan for migration, testing, and launch preparation, this is also the closest the site has been to the “real world.” This means it’s the first time most people get a chance to envision the reality of the new site.

So what do we do to make the process smoother?

This month on the podcast, we talk to Blend’s Director of Development, Bob Davidson, about what happens over those last few weeks — and throughout the project — to ensure the site is as ready as possible.

From our interview:

Corey:

It’s interesting because I think there’s a philosophical difference between web QA and software QA. And this is what was a struggle to me when I started — that there isn’t any really good documentation on how to do web QA. It’s always very focused on software QA.

And I think a lot of that has to do with the fact that software is a little bit more locked down than a website, which literally you can do anything you want with it. Automation is nearly impossible because you change the title of a page and suddenly it looks wrong.
It’s not so much a question but a comment. But why don’t people write about web QA?

Bob:

I think because it’s hard, to be blunt. And I think the web is so chaotic.

There’s basically an infinite number of device sizes in a browser because you can scale the browser however size you want. And so many of the issues we find are very distinct. It’s not so much that this block doesn’t work, it’s that this block didn’t work on this browser in this location. So it can be very hard to find those kinds of things through automation.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

The metaphor will always be there. A website is a house. Strategic design is the house architecture. Development and implementation are a team of contractors building out the blueprints. And getting the content in? That’s moving day.

The metaphor would be tired, if it didn’t perfectly capture every thing that could go wrong. Too much outdated content on the site? That’s when you are trying to move all of your junk even if you don’t want it. Mismatched content model? That’s when you’ve got more — or fewer! — rooms than you had before. Blocks causing trouble? That’s like trying to package and move all the shelves, drawers, and other collections.

This month on the podcast, we beat the metaphor to death in a way that’s both cathartic and reassuring. Content migration is everyone’s bugaboo, but it’s also a chance for renewal. For every project that struggles through the migration process, another is freshened up and made clean. We talk to Carrie Hane, author of Designing Connected Content, about how to prepare for a content migration.

From our interview:

Deane:

It’s like the first time you bought a house. You’ve been living in apartments as a 20-something. You buy a house, a lot of times you throw your crap away because it’s like terrible stuff that you had in your apartments and you buy new furniture for your house and then when you move house to house to house, you’re kind of moving these family heirlooms. I feel like that kind of corresponds to how migration goes now. Organizations are coming to us with a lot more content to move. Compared to the innocent days of yore, how have you seen it change?

Carrie:

Well, yeah, honestly it’s just more volume. I think organizations still often don’t know what to keep, what to get rid of. There’s a lot more hoarding happening than people realize until they go to move stuff and they’re like, “Oh my God, we have to move 100,000 pieces of content. Do we need to?” Maybe, maybe not. It’s really just scale. I don’t think it’s a whole lot different. For the people who in 2005 to 2010 and ’12 who had a website and were making a new one because they had learned something, if they were hoarding, it wasn’t a big deal because it was still tens or dozens of pages, not thousands or tens of thousands, but it wasn’t necessarily good.

That gets into an audit. How do you decide what to move is more in the content audit realm, but you also have to decide what transformation needs to happen. Can you just move it from here to here without really touching it? Do you need to do small little bits or do you need to completely rewrite, reformat everything? There’s some of that in every migration. It’s figuring out how much you need to do for each one based on budget, time, resources.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

I don’t know a lot about back-end development, and that’s on purpose. There are people who do it better, and I should let them do it. That’s how this stuff works, and it’s great: let the people who are good at things do the things they are good at.

But, there’s also a lot to understanding the process itself — I don’t know how to do it, but I should know how it’s done. Because people still make decisions.

In this month’s podcast, we talk to Optimizely’s David Knipe about that intersection: the code and development, and the people who do it — and approve it. David rightfully points out that development functionality and systems cannot exist on their own: they require a human connection.

From our interview:

Corey:

What do we need to carry over from (…) past discussions as we begin this building process? What is it that we learned during selection of a CMS and selection of implementation partner that actually helps us as we move into developing the site?

David:

…I think someone once said to me once that, particularly when you’re making a selection process, there’s often a pitching process. It can often be like therapy. You get your pains out. You get your problems out. You’re perhaps sitting actually in that room with people who’ve never sat in before. … I’ve been in scenarios where you walk in and about halfway through the kind of meeting you realize that these people have never met each other, never spoken to each other because they’re from different departments within the organization.

So I think being that sort of coherent team and the building a common set of objectives out from the result of that process is really important.

Because again, the question I always ask when I would speak to a customer is, “What’s your site for?” And if someone says, “To publish news articles.” I’ll say, “No, it’s not to publish news articles. You’re publishing news articles in order to be able to educate your customers about X, Y, or Z,” whatever it is. … I always think about the end objective as a team, what you’re trying to achieve. The CMS and the implementation and the selection that you’ve gone through is ultimately a tool to help you further your kind of endeavors as an organization or a company. It’s not there just to be a CMS implementation for the sake of it.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

If you work in web design, you know what responsive web design is. It’s a design that responds to the width of the device you’re currently using. No special mobile sites. No requests to view the page in Internet Explorer. It wasn’t just a revolutionary shift in how we treat the web, but a foundational rule in user experience design: we build sites to reach users where they are, not where we hope they’ll be.

This month, on the podcast, we talk with the person who coined the term “responsive web design:” Autogram’s Ethan Marcotte, a smart guy, a good friend, and a modest leader in all things responsive, accessible, and user-friendly.

From our interview:

Corey:

So Ethan, for those who might not necessarily be deeply versed in the details of web development, explain the concept of responsive web design.

Ethan:

Yeah, thanks, Corey. We only have an hour, right?

No, I’ll try to do this at a high level. The web – for me, at least – has always been really interesting because it’s a completely flexible design medium. As soon as I create a web page, I have no control over how or where somebody’s going to be viewing that web page. That could relate to the device that they’re using. They could be using a laptop, computer, they could be on their phone, they could be on wifi, they could be on spotty 3G. And there’s just a tremendous lack of control that I have as a designer over the experience that I’ve built.

So responsive design was basically something that I coined to basically argue that we should be creating flexible device-agnostic experiences, that we could create something that doesn’t have an ideal width or height, but then we can use some technical pixie dust from the CSS specification to allow us to reshape our designs in intelligent ways so they can basically respond to the changing shape of a browser window or a device’s display, kind of like what Deane was doing with JavaScript back in the day. So that’s responsive design in a nutshell is kind of embracing the flexibility that’s at the heart of the web.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

• Subscribe on Spotify
• Subscribe on Apple Music
• Subscribe via RSS

So much of the initial web selection process is focused on technology. This makes sense — often, technology feels like the biggest sticking point, and it definitely represents a significant cost — but, the real relationship is with your implementation partner. Even the best tool can fail if it’s not implemented correctly.

This month, on the podcast, we talked with Real Story Group president Tony Byrne about how to select the people who will build your tool — the things you need to focus on, and the things you can maybe ignore.

From our interview:

Corey:

What do you think is the biggest mistake a first-timer might make?

Tony:

Don’t just fall for a pitch. Everybody’s good at pitching. Most service providers are good at pitching. Particularly if it’s more of a consulting firm and less of a systems integrator. And they all have case studies and they generally have references.

You really want to try before you buy. And a lot of people don’t even know that they can. Do a one-day simulation, do a one-week sprint, we love one-week sprints. You may have to pay a little bit for that, but you’ll learn a lot about yourself, about whether your requirements are realistic, about how much all this will cost. You have the time and the opportunity to take a more agile, empirical approach to this, whether it’s a software vendor or a service provider. And you should take that opportunity to test drive the car.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

• Subscribe on Spotify
• Subscribe on Apple Music
• Subscribe via RSS

I’m lucky. I never have to think about web hosting.

I’m lucky because I’ve really only built small sites that can rely on one-touch hosting — through a domain provider, or as a part of the overall service (like Squarespace). I’m also lucky because, in my real day job, we have people who figure that stuff out. People who understand on-prem vs. cloud. Who know the actual politics of “five nines.”

Thankfully, we also know people who can talk about those things — namely, my co-author Deane Barker and his colleague Elias Lundmark, product manager for cloud hosting over at Optimizely. Hosting is still a weird topic with its own language, but it’s also made a lot easier to understand thanks to this conversation.

From our interview:

Deane:

Hey, let’s talk about site uptime because I think it’s very sexy and glamorous to ask for an inordinate number of nines.

I wrote about this in the book: when I was at Blend, we would get RFPs all the time, and clearly the RFP had been passed around to all of the stakeholders in the organization and the CIS admin infrastructure person added, “Well, we’d like five nines uptime.” And so we would dutifully scope that out, what it would take to keep a website up for five nines.

And five nines would be 99.999% uptime, right? So this is something like 30 seconds of downtime a year, and whenever we’d price this out, I mean we would do it. But the numbers would just be stunning. I mean, to keep five nines of uptime, you have to have multiple redundancies across multiple different regions on different sites of the world.

When you talk to people about site uptime, do you think that there is too much lip service paid to things without being cognizant of how much this is all going to cost? It’s very sexy and glamorous to ask for crazy hardware, it’s also very expensive.

Elias:

Very much so.

I start to think back around the time I was studying computer engineering and just solving for something like storage and that sort of availability — because spinning hard disks tend to fail quite a bit. Just handling that, both redundancy and backup strategy, and the disaster recovery if something really goes wrong, is that you come into setups like active-active, which are really expensive to build on-premise.

Yeah, that’s definitely where the cost of something starts to escalate. And when you have that requirement of, “All right, I need five nines,” then it’s certainly going to get expensive, it really is.

But then it’s also why public cloud providers are so good at that — they have so much redundancy built in, just because of the sheer amount of hardware that they have. It’s really easy for public cloud providers to provide “five nines,” whereas if you’re building something that is tailor-made for a specific application and doing that on-premise, it’s going to be much more expensive.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

Everybody wants to sell you something. You’ll find this when you go to buy a car, or if are looking for a new gym, or if you accidentally mention any product out loud. Everybody will promise everything. Everybody will tell you they’re the best.

Which begs the question — how do you cut through the sales speak and understand the right tool?

We talk this month to Cathy McKnight, who makes a living cutting through the sales speak. As an analyst tasked with helping organizations find the right digital tools, her goal is to understand the real benefits behind the wall of promises — the reasons to buy, or ignore, one tool over another. And, when it comes down to it, she also understands that not every answer is right for every person.

We all have different goals, and we all have different paths. The answer to our questions — Which car? Which gym? — is often an indecisive one: “It depends.”

Cathy is brilliant, and this episode shows that. Check it out, and gain a little insight into both the world of content management systems and other digital tools, while also understanding the psychology of wanting to select the right thing the first time.

From our interview:

Deane:

Can you frame for our listeners, what is an analyst? Why does someone come to an analyst and what kind of service do you deliver?

Cathy:

Certainly. An industry analyst in this space — in this case MarTech, kind of marketing and communications technology — I meet regularly with a bunch of different vendors in the space. Some people focus on a single type of technology. I happen to cover a whole bunch of them. We learn what those vendors or builders of the content have to offer. We provide them with feedback. Often they are so far ahead of where any of their customers could possibly meet them. We give them that feedback. I am as an analyst, I also work on the consulting side, so I actually work with companies that implement, select and implement these solutions. I’m able to give that feedback to a vendor and say, “Hey, listen, this is what people are actually looking for.” Sometimes they listen, sometimes they don’t, but we influence their roadmap. We also work with those buying the technology.

If you go online and compare and insert three brand names here, I’m not going to put any brands so that I’m not giving anybody undue fair coverage, and you’ll come up with a really pretty list that has a whole bunch of attributes and functions along the left side. You’ve got the name of the vendor across the top and then dots. And sometimes they’re like, it’s the whole half dot, full dot, empty dot kind of. And you look at them and go, “Oh, there’s a comparison.” And it’s so not the same thing. Comparing something that you can buy and spend 10 grand a month on, or five grand a month on a subscription versus something that’s going to cost you millions of dollars from a licensing and implementation, they may look like they do the same thing, but they don’t. My job as an analyst is to help organizations choose the right fit technology that will meet their needs today, but also enable them to grow with it.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS

The web is a medium of ideas. Design, content, and the organization of all of it — it’s ideas. There’s no real physical representation: it’s just a bunch of concepts and dreams, kind of.

The closest we can get to manifestation is through code — through the implementation of ideas as visual and interactive pages on a website. So there’s a translation point — just as authors struggle to find words to explain emotions and actions, developers must decode design. Or, code design, I guess.

This is where the art of determining system requirements comes in. How do you create something in a way that’s sustainable? How do you balance development ease with the often contradictory editorial ease?

This month, we’re talking to Joe Kepley — founder at Blend Interactive and someone who often interprets and translates the work we do discovery and design and turns it into something than can be coded. Something real — or, at least, as “real” as a website can get.

From our interview:

Joe:

…I think it’s really common at the wireframing stage to just kind of draw a box and say, well, this box looks cool here, and it’s got this button in it because that feels right. But then I think a lot of folks will not have a plan of what that button does. Or just say things like, “Well, this is going to list our top trending topics on our website.” But then people don’t think through, okay, well how are we going to understand what the top trending topics are? Is that what people are searching? Is that what our editorial team wants to highlight?

So I think there’s a danger, particularly if you just start with the wireframe side and don’t have some of that framework of what are we really trying to accomplish, and you just start drawing pictures, you can draw some very nice looking pictures that, A, may be difficult to implement, and B, may be things that when you sit down and align with what your goals are don’t really make sense to implement. So you can spend a lot of time doing hard work that doesn’t benefit you.

Deane:

Tony Byrne called that seduction by wireframe.

Joe:

Yeah, yeah. And I think we used to talk about, Deane, software that demos well but doesn’t particularly work well, I think is really common. It’s very easy to make something look good in a sales demo because it does something cool. But what you really need to do is sit down and think about how your organization needs to use the software. And I think you guys will probably talk about that when you get to CMS selection.

You can listen below, but we’d love it even more if you would subscribe wherever you can find podcasts, or at the following easy links:

Subscribe on Spotify

Subscribe on Apple Music

Subscribe via RSS