An interview with Joshua Porter

Joshua Porter is a man with lots of fresh ideas and opinions. In this interview we spoke about many design topics, ranging from the uselessness of design deliverables through to remote working and the role of metrics in design.

You can grab an MP3 of the file here, or there’s a full transcript below including imagery we created to visualise some of the concepts being discussed.

Des: Josh, could you introduce yourself to our readers and listeners?

Joshua: Sure. I’m a product and interface designer. I work at a company in Boston called HubSpot that acquired a company that I co-founded called Performable where we make software for professional marketers. I’ve been involved in design and the web for a long time; I’ve written a blog called Bokardo for 13 years. That’s how most people know me, they’ve read something that I’ve written there.

Wireframes are dead

Des: We’ve a few different topics we’d like to talk about. Maybe let’s just open up with a controversial one. Only about two weeks ago, you tweeted that “In case you didn’t get the memo, wireframing is dead and prototypes are the only way forward.” Obviously Twitter forces you to be concise, but even so, that’s pretty piercing. Can you expand on what your thinking is there?

Joshua: I want to be even more controversial. That statement is like 2 or 3 years late! Often I’ll just like throw out a statement on Twitter, to get first-blush kind of responses. So, there’s a little bit of that in there, but to get more specific, wireframes which are medium fidelity, grayscale, outline representations of an interface. I just don’t see the need for them in any real design workflow anymore.

The reason is twofold. One is that I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” Right? So, what are the nouns and verbs? And you can do that pretty darn well with a sketch, you know, white-boarding.

So I think that most of the things that people use wireframes for, in terms of visually laying stuff out and communicating pieces, can actually be done in sketches.

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable. That’s really how I see workflows going forward. Almost every person that I talk to, who I think is doing decent design work, is doing it that way. I think wireframes are mostly a communication tool that is unnecessary, except in “big work” really.

Des: If I was to flesh out what you were saying there, it seems that if you want to try different ideas for layouts, use a sketch, but if you’re testing interactions you need a prototype. Is it possible that the only remaining advantage of a wireframe is that it’s an acceptable, shareable form of a sketch in a professional relationship?

Joshua: Yes. I would say that that’s probably what they’re mostly used for, and in a lot of people’s work that’s perfectly acceptable. I personally would not pay for wireframes, as a deliverable—but, you know, I did consulting for many years. I made wireframes over and over again, as deliverables, and I handed them off and they were passed around and they came back with feedback and all that. I think there’s definitely a need for them in some workflows. But I would fight extremely hard to remove them from any new project that I am involved with. There are other ways to solve the problems that wireframes solved. You just pass around sketches. We create digital representations of sketches all the time at work. Just shoot them with your iPhone. We take pictures of whiteboards, like every day.

A colleague of mine, Dan Ritzenthaler wrote up a nice blog post about this. In it he made a really great point: if you need to create wireframes so that other people can talk, you’re not talking to the right people. You’re probably not talking to the right stakeholders and that’s actually a problem that you need to solve. You need to have direct contact with the stakeholders.

Des: You’ve hit the crux of where the perceived value is and why it could and probably should be replaced. I often feel that the most exciting stuff happens before and after the wireframe in that the wireframe is just like the shareable artefact of a really, really valuable design session and, ultimately, ends up in the bin, once it gets taken any further whatsoever.

Joshua: It’s very similar to the results of usability testing. When I worked at User Interface Engineering with Jared Spool and the gang there we were paid very good money to write these enormous reports, but the thing was, that’s just actually for posterity’s sake. The real job is communicating the results immediately to the design team. If we’re not doing that, then no report is ever going to create empathy. I heard wireframes and some other things called “bill-liverables” the other day. Deliverables that you bill for.

Des: So, tell me this then. In HubSpot I assume you guys don’t rock around with hundreds of wireframes or 300 page PDFs getting passed around the hierarchy. How does your design process work? Are there any deliverables along the way?

Joshua: Am I walking the walk? Totally fair question. Outside of sketches and workable prototypes we have no deliverables. We work with like seven or eight product teams, and each one of those product teams has a product manager. Our best work is done when a designer and product manager essentially are on the same page every day. The way that I’m kind of thinking about it these days is: People who sketch together, get along.

People who sketch together and do that ideation phase of sketching where you take these concepts in your head and you draw them together. That is this really powerful moment, because you can’t lie and you can’t deceive in sketching.

If two people are talking for a week or something, about a new product, they actually might have very different conceptions about that product, even though their language was kind of the same. But once you get down to that level of sketching together, then there’s very little deception that can occur. So, that’s my mantra lately. People who sketch together get along.

Remote Working for Design Teams

Des: That makes sense to me. Here’s a question: Where does this fit in terms of remote working? Can you sketch remotely?

Joshua: Geez. Can you sketch remotely? That’s a great question. I haven’t really tried it. Yes. I haven’t tried it. I would say that it’s possible but it probably won’t be as efficient. You know?

Des: That would be my guess. I think you can throw back and forth photos, but the bandwidth and timeliness is reduced.

Joshua: That’s actually an important difference that you made, Des, that when you have to send something back and forth, it becomes a synchronous, linear process. “I’m waiting for you. Now you’re waiting for me.”

Des: Yes. It’s like you’re passing a ball back and forth, rather than like playing side by side.

Synchronous and Asynchronous Design

Joshua: It’s a different interaction than if you’re doing it at the same time. This is relevant because of the Yahoo brouhaha where Marissa Meyer said no-one could work remotely. Technology is getting to the point where it will feel like you’re in the same room with someone, and you’ll have like super big LCDs where you can see in good fidelity the sketching someone else is doing on a panel, 1,000 miles away. That will definitely come. I think doing it at the same time is actually the most beneficial part and it’s more important than the fidelity of anything you can pass back and forth.

Des: Yes, but no software is going to solve the timezone problem. You’re in Boston. It’s 9am for you, it’s 3pm here in Dublin. Your day is starting, mine is ending. In the early days of problem-solving, you really need like everyone working together, in the same time, sort of preferably in the same sort of humour at the same time of the day.

Joshua: Even with our design team, when we share something, be it on HipChat, LayerVault, or Invision, the feedback is never that great. It tends to be like “Yes, okay, I see that” but they just weren’t in the moment. People can talk way faster than they can communicate electronically, and all of those extra variables that human interaction give us, like tone of voice, inflection and body posture, language and all that, you cannot discount any of that.

The thing with Yahoo! People are looking at it like: “Oh. Yahoo is saying remote is bad and, therefore, they’re condemning that practice for everyone.” I wouldn’t look at it like that. Being part of companies who would try to create cultures has actually taught me a lot about the value of culture and the difficulty of doing it right.

Yahoo is making this decision for their company at this moment in time. They’ve accrued a tremendous number of bad habits over the last decade. Everyone knows the company is in trouble. This is just one of the ways that they are making a hard stance and saying, “You know what? Our culture is going to be a culture of working together in the same space. That’s it.”

I don’t think it’s a general statement on working remotely. I think you can still work remotely and be fine and it depends on the individual. It depends on their lifestyle. It depends on a whole bunch of things. For Yahoo, I actually think it’s a good choice that Marissa made, to do this. In fact, I think it’s the right choice in their case, because they need a huge direction change.

Des: I think the magnitude of changes they need are never going to be comfortable changes. You can’t turn a company around as much as Yahoo! needs to be turned around, while keeping, not just all the Yahoo employees, but all of the onlooking tech bloggers happy.

Are you testing interface, or ideas?

Des: Let’s bring it back a bit. What about testing in Hubspot? Do you guys do much new testing in that regard? Do you test sketches or prototypes?

Joshua: Yes. We rarely test sketches. However, the vast majority of usability testing we do is actually remote usability testing on clickable mockups and working prototypes.

Des: When you say “working prototypes” do you mean HTML, CSS stuff, JavaScript?

Joshua: Yes. We’ll do clickable mockups, or coded prototypes. I have found, though, there is this difference between types of problems that you’re trying to solve. I have seen people test prototypes that were bad ideas to begin with, so we’ve wasted time there. We wasted time building out a bad idea. Nowadays the first thing that we try to figure out is “Are we testing the concept, or the interface?”

Usability testing works best when you know the idea is good and you’re just testing to see if this interface allows that idea to happen.

So, we’re doing a lot more testing early at the sketch phase. We’re doing super-fast interviews with people. Here’s an example: we had this marketplace where you could buy services. Redesign a website, help you do your marketing, write blog posts for you, that kind of thing. We were pushing hard in that space asking “What kinds of services can we offer?” People are always obsessing over subject lines of the emails, so we wondered would people pay for a service where someone writes subject lines for them.

So, we did these mockups and we spent time designing it out. We got people in and they said “I would never use this.” It was such a quick thing. So, what we realised is that we needed this earlier check to see like, “Is this the right type of concept? Is this concept a good one or not?” So, that type of thing is very easy to test, and all I have to do is just ask people, “When’s the last time you paid for someone to help you write your subject line?” It turns out that no one’s investing in that at all. No one’s paid money. So, that’s one of those examples of an existing activity is a pain point, and it’s frustrating for people and they’ll actually go find, you know, marketing materials that will help them write them better, but they will not invest in it.

Des: What’s interesting there is that you’re drawing a distinction between two types of testing. One is “Given that the person wants to do this, is this a good way to do it?”, another is “Would anyone actually want to do this?”

Joshua: Exactly. That’s a nice concise way to put it.

Des: That type of approach comes more naturally when working on your own product, as opposed to when you’ve been hired to test something. If you’re hired to do a usability test of a travel website, you’re just going to do what everyone else would do. Round up people who use travel websites and see if they can use this one. The site can score 100% in testing, but still flop on the motivation. A well designed product that no one wants to use.

Joshua: And they’ll tell you, “Hey, you know what would be awesome? You could add this and you could do this. If you do this, I might buy it.” Then, you finally ask them that core question and then you find out that you just wasted like the last hour asking that.

Des: Is this a fundamental shift? A lot of what we’ve been talking about here is how standard UX techniques don’t map to what you’re doing when you’re designing and building software outside of a consultancy setting. Are “UX designers” meant to be consultants, whereas “Product Designers” are ones who design in house?

Joshua: Good question. You know, I call this “the agency problem.” When you’re an agency, you’re hired to come in and build something. Then, it launches, and you’re done. Your project is done. I don’t think this is effective, because engagement and actual use has become the success metric. There is a longer-term shift toward engagements where the consultancies or agencies will go well beyond launch, through iterations and improvements.

The future of metrics & measurement

Des: That leads me onto the next point, which is, what is a good metric today? If we just obsess over short term quick reward metrics, like sign-up funnels, on one hand it’s great as agencies can immediately track improvements, but on the flipside they’re bad proxies for behaviour. Especially SaaS businesses these days where the idea is: get them signed up, get them on a free trial, get them engaged, get their teammates onboard, then at the end of all that talk to them about a price plan.

Do you think the world of web analytics and business metrics is changing a bit?

Joshua: Yes. I actually think that you and I are working at companies that are trying to push this idea forward. Every part of the user experience can be cut up into small funnels and you can optimize each one of those funnels to be better. That’s what design will become: “Hey, your job is to improve the on-boarding process. Your job is to, you know, re-engage lost customers.” You know, and that’s the problem that designers will be put on and then they just have to figure out everything around that experience, to get that metric better.

That’s the way I look at the world. You know, I’m pushing hard at HubSpot to build that through all our marketing materials and then our software. In terms of metrics, I think engagement is still huge. But to answer your question, I think the high-level metrics will be at the company level and we’ll have to build software that connects those metrics with the actual touch points of the entire customer experience.

Des: What you’re proposing would be that effectively global metrics are company-wide figures, but that any individual designer will be tasked with their own set to influence? So for example, if you’re redesigning the invites screen, the metric of success is the number of teammates invited here.

Joshua: Exactly. Do you see how that completely changes a lot of people’s notion of a designer?

Des: I do. A while back I wrote about three ways you can improve a product and how you have different goals, depending on what you’re doing. You’re always shooting for one of three, two of them are easily mapped to metrics:

1. Make more people use the feature.
2. Make those who use it, use it more often.
3. Give a better experience to those who use it.

Joshua: Yes. I actually like the way you described that, because it points to the very specific metric that you’re looking to improve. “Is it a ratio that I’m trying to improve?” which is, like, of the people who are sharing, can they share better? Or “Is it like a number that I’m trying to, you know, increase?” I like that. I like that framework. A few years ago, when I last went to South by Southwest, I gave a talk called “Metrics Driven Design” and one of the fascinating things when talking about metrics in design is that it actually scares the hell out of some designers. Like it really, really scares them. That some metric will be what they’re accountable for. What I found over time is that actually makes me feel way better about doing design work. Like, “Please, give me a metric. I will go, you know, toe-to-toe with that metric and figure it out.”

To me, that’s a much more clear-cut, approachable problem than “Oh, you have to just make it look good until people are happy and they don’t complain anymore” or whatever the alternative is.

Des: Exactly. I think that’s another great example of the sort of work that you can’t necessarily procure from a consultancy, because you actually need someone who’s going to be around for long enough to understand what a ratio is and where it can go or understand where the metric is and where it can get to.

Joshua: Yes. Exactly. I think that’s going to be a huge part of the changing role of designers, that it will be kind of like, “Hey, here’s a metric. Go tackle it. Just go climb that hill.” I think designers will actually love that. You know, designers love solving puzzles and that’s all metrics are.

Des: The part of metrics where everyone got offended was the whole “41 shades of blue” type assessment. However, if the challenge was: “Make sure everyone can quickly send and reply to as many emails as they want”, then metrics aren’t offensive. Everyone is on the same page.

Joshua: The 41 shades of blue is just the perfect kind of crystallisation of the problem.

Des: Yes. Exactly. Lastly, You’re writing a book or two at the moment. Can you just give us a quick overview of what they’re about. ?

Joshua: Sure. I’ve been writing one book for four years now. I was getting good traction on the book when I jumped into doing the start-up which essentially just killed any momentum I had. As you know, startups are life consuming. When I was writing this book I realized I kept coming back to this “usage lifecycle” that we spoke about earlier. So, I’m going to release a short book first which focuses purely on that.

The key idea is that if you have a product or service that you want to bring to the world, think about your customers in terms of the usage lifecycle. Before they are actual customers, they’re in learning mode and they’re in research mode. Your task—as a designer—is actually selling. It’s teaching. It’s letting people learn about your software. You know, you can do everything from giving them a free trial to show a screen cast of someone using it, to creating marketing materials, to tweeting about it, like all of those pieces. That’s what the book covers.

Des:It sounds like a great concise book to address a specific concept really well. Thanks so much for participating Joshua, lots of good ideas there for our readers and listeners to chew on.

Joshua: Oh. Thanks, Des. Yes. And keep up the great work. I’m a big fan of your blog and I’m honoured to be one of your interviewees.

More from Josh Porter

Josh’s book “Make them care” will be released this year. He can be found on Twitter as @bokardo, and on his personal site is at bokardo.com.