WebDev Chat: "We're Interface Builders"

As I shared with you not too long ago, I'm on a one-woman mission to learn more about web development, since it is one the areas of our business that -- from a skill-set perspective -- is completely foreign to me. Thankfully, our senior frontend developer Tim Ostheimer is willing to answer my endless questions to help bring clarity to what is often a mysterious role for many marketers. 

In this installment of my periodic "WebDev Chat" series, we discuss the differences between working with a web developer in an inbound marketing agency environment and one who is not, as well as what developers are looking for when they're working on website projects or website element builds. 

Me: Is there really a difference in working with a freelance developer or one you might find at a traditional web design agency vs. a web developer such as yourself, who is embedded in an inbound marketing agency?

Tim: To be fair, the only web development work I've done [outside of IMPACT] has been freelance, so I do not have a personal experience, really, I can use to draw a comparison. But I would definitely say that, in this environment, we're much more focused on results in a way you probably would not find elsewhere. Sales funnels, leads, everything. Basically anything that is related to marketing.

A normal web developer would probably not really even consider the things like call-to-action analytics, or form submissions analytics, or anything like that. They may be optimizing for performance and making sure that the design looks nice and is usable, and it's mobile friendly, and things like that. But I don't think that they're thinking too much about conversion optimization.

And the web developers here do that definitely more than a normal web developer would. Although it's still no entirely our responsibility alone -- it's more of a team effort. A lot of that comes back to the design, the content strategy, basically everything else that goes into it before it reaches us.

Me: I think this may come back to the disconnect between what marketers think web developers do and what you actually do. How do you even take things like conversion, or optimization, and forms, and submissions into account?

Tim: By the time an element or a page gets to us, what we're building has already been designed out the way that it should, so no changes are needed. So, most of the time, we would be catching those things when we're just reviewing the design before anything gets built.

We may leave our comments saying, "Hey, have you thought of this, maybe this might be a better solution, or when you click on this button it creates this awkward state where it makes it unclear whether or not the user should do this or this."

A lot of the value of feedback from developers is that we look at the functionality of what is being built and coded, and the actual interactions and how the user interacts with the page. So, at first glance, something mocked up in Photoshop may seem to make logical sense. But then when it actually comes to the technical side of how that things going to function, sometimes the web developers going to be the person who points out that it doesn't really make sense.

So, we'll share best practices and what we find, but often it's the designer and/or strategist who will need to find that alternate solution for us since they are the experts in what needs to be accomplished.

Me: Can you give me an example of that?

Tim: Let's say you have a video in the hero section of your website with a button underneath it to have them contact you, learn more, or whatever that call-to-action needs to be. But when someone clicks to watch the video, it opens up in a pop-up screen which then covers your call-to-action. So, in order to follow-through on the action you want a use to take, they would need to close the video and then click on the call-to-action.

While they may sound OK as you're mocking something up, that interaction is actually quite awkward. They're watching the video, not looking at a call-to-action or even recognizing that it's there. So, really, in that case, you're just crossing your fingers that once they're done with the video and the close it out that they see the button and still feel compelled to click on it. 

A more powerful option would be to have the call-to-action embedded at the end of the video itself or a call-to-action that displays below the video but within the viewer pop-up, so it's always top-of-mind. They don't need to click-away to get to that action you want them to take.

To be fair, there's a good chance a content strategist or designer will pick up on that kind of issue, using that example. But it's just from my experience that developers have a little bit of a better sense of the technical way in the way these interactions work, when you take something from paper to functional reality.

It basically comes down to the developer looking at a design and thinking, "Wait, but when I do this, then this happens." And then to everyone else, that's something they never considered.

That's really the situation that does happen somewhat often. Again, sometimes it's an easy change and we just make one minor adjustment, and sometimes it fundamentally changes the entire way the design is organized, and it does require pretty significant change.

Not always, but sometimes.

Me: So, really, while some might think web developers are just coders meant to bring someone else's vision to life, there's a lot more thinking that goes on behind the scenes. People should be looking for challenges like that from a web developer, as appropriate, because you're actually building an interface. Am I getting that right?

Tim: I mean that's essentially what we are. We are interface builders. We're building something that people interact with. We're not just encoding a design in HTML. Everything we do is something that someone will interact with, and we know that it's not just us, and we know that the content is potentially going to change over time. (Either for business reasons or sometimes site copy just needs an update.) 

We know that there are going to be different devices, different sizes, different levels of user intelligence. And when I say intelligence, I don't mean whether someone is smart or not. It's more that sometimes the "next step" they're supposed to take is clear to some, and to others it may not be.

So, some people are not going to understand the way the page looks, or a way a page functions by the way it looks. And other users will immediately understand that you have to scroll down to see more content.

We have actually had web design clients look at a page we've build and say, "This looks great... but where's the rest of it?" And it's because they didn't realize they actually had to scroll down to see more of the page.

Bottom line, you can never assume that your user knows how to use your product, you always have to assume that they're going to need as much help as you can possibly give them.