See all Insights

Does Prototyping Still Matter?

https://soundcloud.com/newfangled-agency-marketing-matters/season-2-episode-13-does-prototyping-still-matter/s-er288

Transcript

Chris Butler: Welcome to the Agency Marketing Matters Podcast. I’m Chris Butler.

Lauren Clarke: And I’m Lauren Clarke.

Chris Butler: This is Lauren Clarke’s debut on the podcast. Big day.

Lauren Clarke: I am both excited and terrified to be here.

Chris Butler: Lauren, maybe you could give the audience who doesn’t know you an idea of what you do here at Newfangled.

Lauren Clarke: Sure. I am the user experience designer here at Newfangled. I work with our clients to plan the information architecture and user experiences of their websites. During the prototyping process, typically we work together to figure out all of the logistics of their sites and how information will be organized in designs.

Chris Butler: Cool.

Lauren Clarke: To get them the outcomes they’re looking for.

Chris Butler: That sounded very rehearsed and professional.

Lauren Clarke: Thank you.

Chris Butler: Lauren and I are here somewhat early in the morning to squeeze in this recording. If you do hear the coffee grinder or anything like that, that’s just because the Newfangled crew are early riser folks. There’s a lot of people who come in and down a lot of coffee before we get going. That could happen.

Lauren, I know that you are the Newfangled Agency Marketing Matters Podcast biggest fan and you listen to all the episodes.

Lauren Clarke: I do.

Chris Butler: And you’re familiar with our format.

Lauren Clarke: Exactly.

Chris Butler: Actually, we do see Lauren’s face pressed up against the glass when we’re recording.

Lauren Clarke: That’s not true. That does not happen.

Chris Butler: That’s actually not true. We do have glass, though, that you could press your face up against.

Lauren Clarke: If I felt so inclined.

Chris Butler: We like to start off the podcast with talking a little bit about something we’re interested in right now or excited about or relevant. Something like that. I’m going to let you go first.

Lauren Clarke: Okay. I’m excited this morning, at this early hour. I have two different things on my mind. The first thing I’m excited about is I have a meeting later this afternoon with Dave Mello, friend of the podcast and Director of Technology.

Chris Butler: Friend of the pod, as I say.

Lauren Clarke: Essentially, any time I’m working on a prototype and there’s this problem that I want to solve or something that I want to represent but I’m not able to do it on my own, I force Dave to sit down with me for a couple minutes and show me how to get the result that I’m looking for, really. It’s fun to be able to nerd out for a little bit and learn some new code. I’m excited about that this afternoon.

The other thing that I’m excited about right now is toast.

Chris Butler: The thing you eat?

Lauren Clarke: Yes.

Chris Butler: Okay, because I had a zine in high school called Toast.

Lauren Clarke: Really?

Chris Butler: I did.

Lauren Clarke: No. The actual bread and things on top of that.

Chris Butler: You don’t have it.

Lauren Clarke: I don’t. I don’t have it in front of me, but I did eat it earlier. Toast is changing my life lately.

Chris Butler: That’s cool. Why?

Lauren Clarke: I think for a large portion of my life I had an irrational fear of bread, and I don’t really know where it came from.

Chris Butler: That’s really weird.

Lauren Clarke: But I found a bakery by my house that has delicious bread, and I’ll get some and put almond butter and bananas and chia seeds and delicious things on it. It’s a new love affair.

Chris Butler: What is this bakery? Because we live somewhat close to one another.

Lauren Clarke: It is Loaf.

Chris Butler: Oh yeah, Loaf.

Lauren Clarke: Loaf in Durham.

Chris Butler: They’re a good place. They’re also right next door to where the biggest skyscraper in Durham is going to be shortly that’s underway.

Lauren Clarke: It’s very exciting.

Chris Butler: It’s pretty exciting. I’m offended that you’re not excited about the vegan cookie that’s sitting in front of you.

Lauren Clarke: I am also excited about that. Sorry about that.

Chris Butler: For those of you who don’t know, that’s a huge part of Lauren’s identity. She is vegan. We talk about it all the time.

Lauren Clarke: That’s actually what I’m here to talk about on the podcast.

Chris Butler: Veganism.

Lauren Clarke: Exactly.

Chris Butler: And how it relates to agencies.

Lauren Clarke: Yes.

Chris Butler: I bet there are some agencies out there who are positioned to help vegan brands.

Lauren Clarke: I would think so. Give me a call. Give me a call, guys.

Chris Butler: That’d be a really tight, narrow focus. Speaking of which, the thing that I’m excited about is what I have here in my hands right now, which is David Baker’s latest book, the David Baker, David C. Baker, of ReCourses. His latest book is called The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact and Wealth, which is pretty cool. David is a really generous guy. We’ve had the honor of working with David for a long time. He sent us all copies of this book, which is really cool. I read a bit of it. I was excited about this book because I was getting previews of it in his podcast with Blair Enns, called 2Bobs.

It’s a great read. I think maybe so far … I’ve read a couple of David’s books before this. I think this is going to be my favorite one of his. It really sums up what has always been his perspective on positioning, which is, the tighter the focus, the narrower the focus, the higher quality the expertise, and the easier it is to actually make a business out of that. I’m excited about this book. I’m excited that most people at Newfangled are going to read it.

But actually, it echoes something that I’ve been finding myself saying over and over again to agencies that I’m working with in design audits. We don’t consult on positioning, but we ended up talking about it quite a bit because we talk about how positioning is articulated from a marketing perspective. There are a lot of agencies that we work with that are really focused. What they do is really specific. The audience that they work with, the who, is really specific as well. They’ve got that horizontal and vertical positioning really worked out. Like anyone, they’re so close to it that they struggle with articulating it in a way that I think is going to be the most compelling.

I think what has struck me recently in having these conversations over and over again is that there’s really no such thing as objective expertise. What I mean by that is that all expertise is subjective, meaning that it requires focusing on one thing that you choose to focus on, and not another, and being one person, and not another. That means that point of view is really an essential component of positioning, and especially how you articulate it. The easier it is to articulate what you do and for whom, the tighter your focus. The more recognizable that is, I think the greater the need to further differentiate by stating a true and unique perspective on why you do what you do and why the world needs it.

That’s something that David talks a lot about in his work, but I think it’s becoming much more relevant as we push our agency partners to take his advice, and then to actually coalesce it into the right words. That’s something I’m excited about. I would recommend this book. Again, it’s called The Business of Expertise by David C. Baker. You can find it online on ReCourses.com. You can also find it on a website that he created specifically for this book called Expertise.is or Expertise.is. The podcast, I’ve reference before on this podcast, is 2Bobs, which you can just find at the number two Bobs.com

Lauren Clarke: Cool. I’m excited about that too, but you already called it as your thing, so I had to go with toast instead.

Chris Butler: I think David Baker will be profoundly honored to have been referenced along with toast, which is a significant part of human civilization. The Business of Expertise is an interesting segue to thinking about why you’re here. You have been at Newfangled for a long time. You’ve done numerous things here. Over the years, you have really narrowed the focus of your role I think pretty considerably. It continues to be narrowed. At this point, you are the user experience designer at Newfangled. The one. We don’t have another. Your focus is quite unique. There are other roles here for which many people sit in those seats.

I think you’ve been able to really focus in on something that I think you do uniquely well that is still really important to our clientele, regardless of whether or not we are building something, which we used to do a whole lot more than we do now. But you still deliver your expertise in a variety of different forms. Talk to me a little bit about that evolution, why … I don’t know. Why have you focused on user experience design? Just, for the record, you started as a project manager here at Newfangled, a digital project manager.

Lauren Clarke: It’s true that I have done lots of different things here and have focused in on this more and more the longer I’ve been here. I think that, as I was working as a project manager, and at the time that I was a project manager, that job continued to entail the leading our clients through the website development process from start to finish. A component of that was prototyping. That was still something that I did, but I think the more that I was working with clients and leading them through web projects, that was the point at which … I don’t know what it was about it, but I think that that’s just where I always felt the most drawn.

It almost just happened naturally, I think. The more that we have focused our positioning around what we do, as well, I think it’s made it easier for there to be a position that can really focus in on that, because the nature of what we’re advising clients, often when we’re doing web projects with them, is it doesn’t tend to vary a lot. It’s given us the ability to really have a role that focuses in on I guess just having more expertise around that as opposed to trying to … almost trying to figure out how to solve a unique problem time and time again. It’s like we’re talking about similar things, for the most part, and it’s allowed me to really … I don’t know, I guess hone in on being able to develop a lot of expertise around that and guide clients through that process.

Chris Butler: Right, because what you’re talking about is the structure that coalesces around what we tend to advise clients to do, whether it comes from, like I said, the articulation of their positioning, so their marketing message, their content strategy, what they’re doing in terms of outbound and marketing automation type things, the structure of their marketing and sales data in the CRM. All that stuff tends to coalesce and manifest visually and structurally in their website. Regardless of whether or not we’re building it, we still play a significant role, you play a significant role, in helping clients understand how to document that. You mentioned the word prototype a couple of times. It might be helpful … I think we take for granted at this point that people understand what we mean by that.

Lauren Clarke: What that means.

Chris Butler: Newfangled being in prototyping in the year 2000, when really no one else was doing that. That has now become pretty much an industry standard, although some people have moved past prototyping at this point. Could you just give the audience a sense of what you mean by that?

Lauren Clarke: A prototype is essentially a visual representation of the structure, content, and functionality of a website. When we’re working with clients on web projects, we go through a prototyping phase, which is typically around six to eight weeks. We’ll meet and review the prototype together and we’ll basically … we use that document to have conversations about information architecture and how content is organized and structured on the site, what types of templates are going to be included in the website, what types of content relationships exist, and the logic that drives those relationships.

It’s essentially working together in an early stage to put together a blueprint of what we’re going to build. Anything that ends up on the site is represented in the prototype in a way that allows them to interact with that before we build the actual site.

Chris Butler: It looks like a wire frame. It’s a lot of boxes and arrows and that kind of thing.

Lauren Clarke: A lot of gray.

Chris Butler: A lot of gray, but it’s interactive. You can actually use it. You can click it. We used to have a way of saying this over and over again, that we would build the site before we built the site. That was the idea that this wire frame was more than just representative, in the sense that often a wire frame will have six or seven pages to it, and this would be much more complex than that. But, additionally, you also build in a decent amount of interaction into the prototype such that you’re actually using a decent amount of JavaScript to produce things, like filters that actually work or search tools that work or div overlays that actually show information in different ways. That kind of thing. Tabbed interface. Whatever.

The prototype, as you pointed out, is really good at documenting that kind of complexity. If someone was building just a brochure website, then probably a printed wire frame on paper, the way it used to be done, and the way that some people still do it, might be adequate. But when it comes to documenting both the visual effects of an interaction as well as all the detail that comes with it, a prototype is pretty good. I’ve seen, in the ones that you’ve created and over your tenure here, you fill it out with an extra layer of notes. You’ll have developer notes distributed through the prototype that actually indicate maybe how data is being passed back and forth, what’s happening behind the scenes, indications of how the content management system might be structured and working. That kind of thing. There’s a lot of detail to capture. We’ve just found that the prototype is a pretty good way of doing that.

I’m curious, though, prototyping … I noticed that when responsive design started to become practiced, people stopped prototyping, because I think they found that maybe the most efficient way for some projects was just to start building the thing right away and work out design issues and interaction issues and that complexity just in the browser as you went. You might identify your scope and then plug away in a hyper-waterfall or an iterative way, but just by building the site. We still don’t do that. I’m curious, what is a prototype good for and what is a prototype not good for?

Lauren Clarke: Oh gosh. That’s such a big question. I’ve seen, time and time again, that the prototype definitely has limitations. It’s not … although it is interactive and there are a lot of different pieces of functionality that we represent, there’s a lot in there that we can’t fully achieve, nor is it probably worth the time to invest in making that do exactly what it will do on the website. I think particularly for responsive design as well … it’s interesting that you brought that up before asking the question, because that’s something that for me has been a significant … I don’t know if limitation is the right word, but a place at which I’ve found that the prototype isn’t necessarily the best place to work all of that out.

What we tend to do is essentially mock up a couple key templates, because the prototype tool itself is not responsive. If you were to drag your window closed, it’s not actually going to adjust on the fly like a typical website would. But I think that it is … I have found it helpful even to at least mock up a couple key templates so we can be thinking about how content will scale, because in the absence of doing that, I’ve found that, when you get into building it, there are all kinds of things that, had you taken the time to consider that before starting to build, you probably would have structured the page in a different way or done those types of things. Where, once you’re in there, it can often end up being more work to go back and try and redo it.

One of the other things that the prototype has always or has never meant to represent is an actual design. While we do suggest layout and arrangement in certain places and make a point of explaining where those recommendations should be taken more literally, there’s a lot of leverage when it comes to actual page layout and design that I think has consistently been somewhat of a point of confusion, how literally do we need to interpret that. The prototype isn’t meant to be prescriptive when it comes to showing the actual end content in terms of specific text that is going to be in places or saying these items are definitely going to be displayed in a list as opposed to a grid. Those kinds of things I think are best left to work out in design and copywriting and those types of things, and not necessarily as part of that process.

Chris Butler: I think that’s a really good distinction that you’re drawing when it comes to the continued relevance of the prototype, which is that information design, or information architecture, which are two different things, but both of those disciplines still stand outside of developing a visual language. What I think is unfortunately referred to in our industry too often as visual design, that’s really … what’s being talked about there is the development of a visual language.

Some years ago, we started to fork these paths in our process, where the prototype would be the place where you’d first start talking about how this thing needs to come together, the information architecture of it, what information is this website going to contain and how is it related to each other? What’s the priority? That is something that can take shape in a navigation system, in the structure of pages, and then in pages individually, how information is laid out there. Then, that starts to delve more down into information design. They might actually take on some visual characteristics, and those are instructive to a designer who’s picking it up later, in terms of how do you use visual references to indicate priority?

It’s not just what comes first on a page, but what might have larger type or stronger type. You might actually use typographical cues in the prototype to indicate priority. Then, things like buttons or boxes around things, what’s highlighted and what’s not. Those types of visual cues are a part of the prototyping language, but they’re not a part of the, what I would call the visual language of the site itself. That has to do with colors, textures, the actual end typography, the art direction, all that stuff that plays a significant role. That was where you were talking, there’s a huge amount of latitude.

The problem is, is for the designer to interpret where the lines of latitude really are. I think what we’ve tended to recommend to agencies for a number of years now is to have the prototyping, so the information architecture and information design, in parallel with developing the visual language. So, building a visual inventory first, building a element collage second. The visual inventory is a way of looking at the surrounding environment in which this organization or company for which we’re doing design exists, and figuring out what visual language is being used now? Does it work? How does it compare to competitors’ or other people in that space? How does it actually achieve the brand goals?

Exploring that in just an inductive survey kind of way. Then, from there, going into an element collage, where you’re actually exploring how a new visual language might take shape. That’s through any number of different design details in a website, but not the website. Just how might type look in this context? How might a pull quote or a bio or some other kind of interaction detail, a form? You can do all that stuff independent of making decisions about the page layout. Then, that gives you time to work out the information design, and then merge those two processes together.

It sounds like what you’re saying is that the prototype is still relevant because it’s important to narrow in and focus in on information architecture and information design, and force what is unfortunately called visual design into a specific process of developing visual language so that they can actually work in partnership and not step on each other’s toes.

That being said, there are probably still plenty of times where you’ve made a design decision in a prototype in terms of how you’re dealing with the information design of a page or a template. That could get reinterpreted in the visual language stage, where the visual language is being applied to the structure of the prototype, and that might have positive or negative repercussions. Can you think of some examples of that?

Lauren Clarke: Oh goodness. You think a lot of times … it’s interesting, because there tends to not be a ton of templates that are highly customized. A lot of it is … it ends up at the end of the day that how that page ends up looking is often largely driven by the different elements that the client chooses to put on the page as part of content entry.

It’s interesting, because I think that as we’ve simplified in a lot of ways our approach to web development and introduced tools like modular content and things like that, I’m finding that I have those experiences less and less. Although, there definitely are projects that I’ve worked on where we work with agencies that just are interested in pushing those boundaries in a good way. I think that, as they look at something simple in the prototype and try and imagine what that might end up looking like, they start to introduce new elements that we haven’t necessarily built before and are part of this library of things that we know we’ve done or new and interesting ways to interpret a form, and what that will look like, and new and interesting ways to even interpret something like a list of content on a page that just ends up looking very, very different from what we all looked at in the prototype.

But, once you see it, you’re like, “This isn’t necessarily a concern from a scope perspective, in terms of, while we can’t build it this way and remain within budget and schedule, but this ultimately is something that looks really, really interesting and exciting.” I feel like I’ve had those types of experiences a lot lately.

Chris Butler: As you described that, I’m thinking of a couple of examples. One is this agency, Big Duck, that we’re working with right now. We’ve worked with them for many years. They’re an agency for whom we’ve advised on the overall design of their new website in addition to content strategy, marketing automation, CRM, all that stuff, that they’re in the midst of that program now. But, we’re not building the site and we’re not actually doing the visual language, we’re not doing the design. An agency called Familiar is doing that. Familiar is doing incredible work. We provided some high-level IA documentation.

One interesting detail that Familiar added in, among many, they’ve really taken that recommendation and interpreted it in a pretty unique way, is something that we would never put in a prototype, which is this animated feature on their homepage where they’ve taken their positioning statement and they’ve taken one word in it and it sort of animates in and out and becomes other words. That allows them to have three statements in one. This happens as if you’re watching somebody type it out. That’s what the animation is. Actually, you showed me another example of that yesterday.

I thought that was really interesting, because it speaks to Big Duck’s collaborative, explorative approach and their vibe as an organization, and it does so in a way of actually consolidating text. But we would never put that in a prototype.

Lauren Clarke: It is interesting, because, hearing you give that example, I think the times that those things come up do tend to be more around user interaction type of elements that we would just never prescribe that level of specificity in a prototype. But, agencies that are interested in doing something new and interesting, I think that those tend to be the ways that ideas come out of, “Well, what if when you click this element, this thing happened?” That, you’re right, isn’t ever really something that we would get that specific in the prototype in terms of a specific transition or animation or things like that.

It’s funny, because often those can be interesting and new and exciting, like the Big Duck example that you mentioned. Then, there are other times where we just get this list of animation requests and it’s like, “Oh goodness. Now we have to sort through this and figure out what is worth it, what is not,” and those types of things, because it’s definitely a fine line when it comes to those elements, what actually enhances the site and what is just visual clutter that doesn’t really help with the end goal we’re trying to achieve.

Chris Butler: Right. Actually, in our design audits, which we do for most of our clients these days, two of the major categories are practicality and aesthetics. On the practicality side, we talk a lot about from an implementation standpoint what makes the most sense, what makes the most use of the resources available at the time. But also, to your point, animation can be a really effective interaction design tool, but it can also draw upon resources in a way that causes a lot of headaches later. If you have six different animations running on a page, all JavaScript-driven, there can be conflicts in terms of load experience. Browsers can interpret them different ways. On a desktop in your office, it might perform great, but on your phone when you’re in a 3G zone or something it just might as well not even be there.

Those are the kinds of things that we talk about. Is this really necessary and is it worth the cost that it’s going to have on you over time? Because, as soon as that JavaScript library you use for this one effect gets rewritten and updated and causes a bug in the other one, and then Chrome updates and starts interpreting those in different ways, then you have six bugs, and everyone’s pointing fingers at someone to figure out why, but actually it’s out of everyone’s power who built the thing. It just becomes a really costly venture. It’s like, “Well, why did we do this?” “Because it draws a line under that text, and that’s kind of neat.”

I agree with you. I think that can become really problematic. But, in some cases, those cues are really useful. I think it does require … actually, the prototype is a good context for talking those things through, because, and I know you do this as a matter of course, those reviews include the design team so that they can start thinking ahead about how they might interpret those details or add in details that the prototype would not include.

That covers something that I was going to mention, which is the prototype is a place where you might represent things that, from a consultative standpoint, we’re fairly dogmatic about, and then some things that we’re pretty liberal about. We describe that all the time, where the client might say, “What’s your recommendation here?” We might say, “Well, look. We actually don’t have one, because this isn’t that strategically important.” For instance, what you put on your bio page, we have opinions about that, but they’re not strong dogmatic recommendations like we might have for the way that you lay out your content marketing.

Lauren Clarke: Your homepage.

Chris Butler: Some landing page that we think is really critical. I think drawing the line between opinion and hard recommendation is important. One specific example I was going to mention that I know that you’ve dealt with many, many times, is the basic information design pros and cons of lists versus grids. That is an interpretation that happens all the time, where you might prototype something out as a list and the design comes back with it as a grid. It seems to the designer at that point like, “Well, what’s the difference? The information is all there.” I think there is a pretty big meaningful difference between the two, depending on the context. Maybe talk a little bit about that one.

Lauren Clarke: That tends to be a controversial topic, which is always surprising to me when we’re looking at a site. I think it comes down to what the specific page is trying to represent and what information is associated with list items and what we’re expecting users to do on that page to really drive whether or not a list or a grid makes sense.

I think that common places where we see something like a grid is on a leadership page, where it’s a list of team members, and it really doesn’t make sense, given the information that you want to show on that landing page or the amount of variation there could be, and really how you expect users to even browse the content on the page. In a lot of cases, it doesn’t make sense to have to list those out in a single column, one on top of each other, because it just doesn’t necessarily impact that much how a user is going to interact with that content.

But, on something like a content marketing landing page, this is a conversation we have all the time, where that page is relying on lots of different things. It’s aggregating a lot of content. We’re expecting users to be able to easily scan that and find information they’re looking for, and take cues from things like dates or potentially strap lines on what type of content is listed. Where, when those are in the same place as they scan down the page, it makes it much easier for a user to orient themselves and figure out what they’re looking at. Then, you get into things like filtering on those items, and just the variation of the length that a title could be.

When you start looking at a design that tries to box in that information when there are a lot of different variables, it immediately just places a higher cognitive load on that user to try and look at that page and figure out what it is they’re looking at and easily get to the information they’re looking at. We also see, when it comes to something like responsive, when you have so many different elements on the page, that starts to break down in the overall user experience when you get those items on a 320-pixel screen. It just becomes, even in that environment, much more difficult to scan through and get to what you’re looking for.

Chris Butler: You mentioned something that’s super important to me as a designer, is this idea of cognitive load.

Lauren Clarke: I know. I took that from you.

Chris Butler: I mentioned those audits that we’re doing. The aesthetic vector in those audits has nothing to do with beauty. It’s not about what a client feels is beautiful and what I feel is beautiful and the distance between those. It’s about the degree to which visual information has utility or not. When visual information doesn’t have utility, then it’s purely a drag on cognitive load. If you’re decorating the container, and a lot of containers are decorated because of brand visual language, then the user has to figure out what all that stuff means. Sometimes they do a lot of work to figure out what it all means and realizes it means nothing.

A grid is an interesting context for cognitive processing, because you have to figure out the logic of the grid, as you pointed out, and that takes a lot of work, whereas a list makes its logic very clear. Recency is paramount. As you mentioned, different metadata related to the items in the list are in the same place every time across one axis, the Y-axis, whereas on a grid it’s both. But then the other draw that you mentioned that I think is really important, and I’ve never even thought of it this way when I pre-advise clients on this is, that active boxing things in to keep the grid means that you start to squeeze things that shouldn’t be squeezed.

Designers always produce these perfect grids and it’s always the case that the headline is one line. It’s like, what if the headline’s three? Then, what if the abstract text is a little longer here? What we’ve encountered, I’ve been in meetings with you about this, people always say, “Well, we’ll just put a character limit on it.” What ends up happening is, “Would you be okay if the word gets broken mid-word?” They’re like, “Well, can’t we just have a word limit?” It’s like, “Well, yeah, but all words have different numbers of characters.”

Lauren Clarke: Right. Then, even when you get into … if you manage to come up with a set of rules where you’re like, “Okay. We think that this is consistently going to look great when we’re at the maximum width,” which is 1,200 pixels. As soon as you start scaling your browser down and maybe you shave off 100 pixels, there’s less room for words within that grid, and all of those types of things. We find time and time again that, when we’re advising clients against that and we get a lot of pushback, it’s almost inevitable that at some point once they see it they start to understand and don’t ultimately like the way that it’s working and how it’s scaling. It’s definitely a unique challenge, depending on the type of information.

Chris Butler: The prototype is a great context to start to explore issues like that. With the amount of experience you have, you can see that stuff coming so far ahead and bring it into the prototype, whereas I think a lot of design teams that don’t have that level of experience may not be able to see those things coming until they’ve been built and people are using them. Or, if someone’s entering the content, and all of a sudden it’s like, “Well, I entered a three-line headline and everything broke.” I think that’s fantastic to be able to bring those things into the prototype.

What I wanted to mention really quickly before we wrap up is that we have a homegrown prototype tool that’s based on a CMS that was created for Newfangled, a proprietary CMS. Now, when we do development, we’re working mostly in WordPress, but our prototype tool is still basically a CMS-driven website building tool that’s just catered towards prototyping. But there’s so many tools out there that are useful. I’ve seen design teams using a combination of Sketch and InVision, which are synced up for that purpose. You can do prototyping there. There’s ProtoShare. There’s UXPin. There’s so many tools out there.

I think, whether or not you have adopted a process that makes prototyping make sense, maybe you don’t do waterfall development, maybe you’re 100% iterative, you’re working in the browser all the time, I think a prototype is still a good idea because you can start to work out these issues without committing to a certain kind of production that takes longer and takes longer to revise. If you make a choice on a prototype that people realize they don’t like, you can just redraw that box. But, if you’re doing it in the browser, you might have already programed a bunch of JavaScript to get something to happen. You have to tear all that down and refactor it.

I think that there’s still, even in the age of responsive design and hyper-iterative workflows, that there’s still room for prototyping. There’s still a ton of room for that. As a result, you’ve done numerous engagements now where all you’re doing is a prototype. You’re handing that off to an agency’s design team, which is really a fun thing to do. Let’s wrap there.

One little thing I mentioned to you the other day that I wanted to just put out there, because I’m honestly experimenting with this language. I was driving home the other day, and I was listening to David Baker talking about his book. It was funny, because he mentions in the podcast about the book. Blair Enns asked him, “How will you know this book is successful?” I think they were talking five years from now, or something. He said something along the lines of, I’m paraphrasing here, that he hopes that the book catalyzes a lot of deeper thought among the people who read it about where their expertise truly lies.

Immediately, I thought about what our company does in the space that we’re talking about right now, and particularly what you’ve done. I started thinking about user experience. Part of that is also because David wrote a really kind note in the first page of my book about his appreciation for what we do in this space and what I’ve done in my career so far. But, I was thinking about user experience design, and I was thinking about how user experience design is the paramount. It’s about … I wrote this down, so I’m going to refer to my notes. It’s this discipline of using design to make it easy for users to do what they want to do. That’s correct. That’s the way it ought to be. That has applications in any number of industries, not just consumer, business-to-consumer industry, but also in ours, business-to-business.

I was thinking, how does that map to what we do? Because what we talk about at Newfangled is creating opportunity in a marketing context, and we’re looking at the prospect all the time, and we’re thinking about how do we design something in a way that makes it more likely for the right prospects, the right fit prospects, to take the right actions. I’ve found that in my consulting I’m leading people towards design choices that limit the prospect’s options so that they take certain actions that make the most sense for them.

I thought about, maybe that’s just a spin on user experience design. I was thinking about UX to PX, prospect experience design. The difference there is that prospect experience design is the discipline of using design to make it easy for prospects to do what you want them to do. I think if someone heard that just out of nowhere they’d bristle at it, because it sounds limiting or it sounds dogmatic or manipulative. But, it’s not. It’s just that, in this type of marketing, you want the right people to take certain actions. You don’t want the wrong people to take those actions. You need to make it very clear on any given page or piece of information what you want people to do next.

I had said in a previous podcast that the only things that really matter in this context are two rules: tell them what you do, that’s the position piece; and then tell them what to do, and that’s the user experience design, or in this case prospect experience design. I’m playing with that, and I think there’s something there, but I know that people are going to bristle at it because UX is really in the zeitgeist at the moment.

Lauren Clarke: You did. You mentioned that the other day, and I was thinking about that too after you talked about it. Not to open a can of worms at the end of our recording time, but you talk … you and all of us, I guess, talk a lot with our clients about the idea of purposeful user flows on their site. One of the things that we talk about related to that is the idea of allowing visitors on your site to start this process of prospect qualification. It really is … at the end of the day, if people are coming to your site and they have this ideal user experience from top to bottom and they’re just not the correct person for you to work with based on various different factors, then it almost it doesn’t feel as important as making sure that the correct people are on your site having a good experience and taking the actions that you would like them to take so they know whether or not they’re a good prospect and whether or not it would be a good working relationship.

Chris Butler: Absolutely. You heard it here first. PX is the new UX for marketing teams. We need to wrap up, and we like to wrap up by suggesting places or things that people can check out to get a little deeper into the subject. What do you have to recommend?

Lauren Clarke: I brought up at the last minute there the idea of purposeful user flows. As I was thinking about this podcast and a lot of what we do, I just found myself drawn to a series of articles that you posted around our key recommendations for a lot of different templates that I talk to clients about all the time throughout the prototyping process. The first article in that series is called “How the Right Design Will Turn Researchers into Buyers.” It’s from August 2016. If you start with that one, it leads you through that series, going over these key templates. Like I said, I find myself coming back to that over and over again. I think it’s a great read.

Chris Butler: Cool. Similarly, I chose something that you wrote. This is actually from long ago, 2010.

Lauren Clarke: It has to be. I haven’t written anything on our site in so long.

Chris Butler: But, 2010 you wrote an article called “How Specific Should a Prototype Be?” A lot of what you were talking about, that nuance of where the prototype is explicit and where it’s interpretable, is something you talk about in that article and you outline there. People can check that out. That’s from 2010. Just search for that on our site.

The only other thing that I was going to mention is another somewhat old article from 2011 that I wrote afterwards called “Prototyping For Designers.” It’s really meant to go in extraordinary detail through all these areas where a designer has interpretive power over the prototype and other areas where the prototype might need to have permanence over the way it’s interpreted later on. Check that stuff out. We’ve gone long, as I expected we would, because this is a subject where you could have a whole podcast just about this. Maybe someday we will. Who knows? I have a megalo-maniacal plan here to spinoff many podcasts from this one, and maybe someday we will, which will be cool. We could talk about this forever.

If any of you ever have any questions about prototyping who are listening, you should seek out Lauren. You can find her at lauren.clarke@newfangled2020.wpengine.com. She is our current authority on these matters. Seek her out, and join us next time. You can find us on iTunes. If you do, please rate the podcast. That helps it spread around. You can find Newfangled at Newfangled.com. We hope to see you next time. Thanks a lot. Thanks, Lauren, for joining us.

Lauren Clarke: Thanks for having me.