The Clearleft Podcast

This is the Clearleft podcast.

We were mocking up the inside of a transatlantic airplane.

Whoa. Wait a minute. Wait a minute. Before we get into transatlantic airliners, let’s consider where airplanes came from.

Orville and Wilbur Wright are generally credited with inventing, building and flying the world’s first motor-operated airplane at Kitty Hawk, North Carolina. The Wright Flyer flew for just under a minute. The plane had a wingspan of 40 feet. You might’ve seen it in the Air and Space Museum in Washington, DC.

But the Wright brothers didn’t start by building a 40 foot airplane. They started by building much smaller models to test in their miniature wind tunnel. In other words, they started by making a prototype.

My name is Benjamin Parry. I’m a design researcher and I work for Clearleft.

We were mocking up the inside of a transatlantic airplane.

Okay, this is where we came in.

I’ve put four chairs and a massive touch screen television.

There was a product. There was a digital interface. There were headphones. We were testing out the implications of putting a social interactive product in a social space. And we were trying to uncover what social anxieties that would create in that space.

The client that we were working with had a proper internal mock-up of an airplane but we didn’t want to do that because part of that expectation of an experience was about brand. And if we’d taken them to a certain place tha twas very heavily branded, then we were worried about that expectation of that brand experience sort of interfering in that insight gathering.

It was in a testing lab. And we were testing a social space and we were getting them to fill in the blanks. So we had two sort of CCTV cameras pointing at some people. And interestingly, we tested solo in a couple of tests, but we also tested with two strangers turning up into a test lab and then sitting in a confined space, testing out this touchscreen TV. And like going through all these different combinations of seating arrangement, and now you’re using it and now you want to use it and yeah, it was fascinating.

If you asked a plane spotter to name the most beautiful plane to ever fly, you might get a few different answers. The 747. The Concorde. But somebody is bound to mention the SR 71 Blackbird.

The Blackbird was built by Lockheed Martin, but it didn’t go through the usual design and production process. Lockheed Martin created a separate development program called skunkworks free of the usual day-to-day bureaucracies.

At Clearleft we’ve run our own little skunkworks projects in the past. Except we call them hack farms. We documented some of it in a video on hackfarm.org.

Andy Budd: Every year around November, December, we hire a cottage or a house in the country and take the whole Clearleft team away for a week to work on a project together. Typically when we’re working on client projects, weo nly work to do two or three or four in a team. So we never really get the opportunity to work together on a single idea.

So the concept behind hack farm comes out of other hack events, hack weekends, hackathons, where you get a group of people together to work on a passion project. So we come to the farm full of ideas, but with nothing set and throughout the process of the week, try to create a new idea, to design it and sometimes even build it.

I always think of a prototype as a prop. It’s something to look at, something to prod. And ideally you’re trying to work out what works and what doesn’t. Then you can iterate, you can improvise and you can try and push things further forward.

When you think of things like a design sprint, you’ve got a hypothesis, you’re testing it out. It shows that there’s value in that hypothesis then really, sometimes you just need to prove that hypothesis is valid and then throw the whole thing away and actually just rebuild it or redesign it.

But what about the fidelity of a prototype? How polished should it be?

It has to be usable, right? It needs to feel like the participant can navigate through it so that you can suspend disbelief enough to think this feels like a legitimate thing. Because people get hung up on things like content a lot that can really stifle the experience or breaks that sense of suspending disbelief. But really, I don’t really mind the tool that it’s made in.

What has been funny in times when we’ve tested a live website and they’ve said, this is just the prototype, right? And that’s really opened up the eyes of clients when their actual website has been considered a prototype.

I’d like you to meet another colleague of mine.

Lorenzo Ferronato, a UX designer at Clearleft.

Lorenzo made something recently that’s kind of like a working prototype ...for content creators.

We are currently redesigning the prospectus for one of the leading UK university, and a part of that consisted of redesigning the description page for each course. So we spent a fair amount of months working on the new layout and indeed the new design.

We’ve done our research. We’ve created a number of wireframes that we then turned into a more refined final design, and this design has been tested with current university students and prospective students.

So it felt like we were done, but we started to look into how does this new design fit into the university content design process?

We had a number of reviews with the team of the university and we got a good amount of verbal confirmation that yes, this design is good, we can populate the design with content. But still we felt there was a gap between what the university aspired to and what they currently had. So we devised a way to test how our design could be populated with content from the university in the future .

We wanted to make sure our new design could be actually used by the university and the content for this design could be created easily.

Well, that sounds like the job of a content management system.

As you can imagine, building a CMS is not the easiest of things and it’s not immediate. The creation of the Content Management System will be a completely different project that we will be undertaking. But at the moment, we needed to understand a number of things about this new future ideal CMS, and at the same time, test our design.

We obviously couldn’t build a CMS and even using a ready-made headless CMS to integrate with the live design was just out of the conversation. We just didn’t have the time. We needed something that was much quicker. We needed a quick solution to test a number of assumptions and to test the design. Is this new design going to make the content creators life a nightmare?

We were using Figma and Figma has a good amount of plugins that can help populate a design. The problem is the content creators are not designers. They’re not UI designers and they probably don’t have any experience with design tools.

We needed something that was more familiar, something that was a bit easier, something that was a bit more comfortable, something that people know how to use, and something that can recreate the actual experience of using a CMS to populate the design with content.

What exists out there that is familiar, is similar to a CMS and it can be integrated with the other tools we’reusing?

And then I realized that Google Form was exactly that. Google Form presents a number of fields, you fill in the fields, you submit the form pretty much like you would do with a CMS. And the plus is that you can export all of the responses in the Google form into a Google Sheet. And we already have a really clever plug-in to connect Google Sheets and Figma.

Okay. So this sounds like the digital equivalent of a Heath Robinson device with content from Google Forms going into Google Sheets which then goes into Figma. But it worked.

And so there it was, we had our solution. We would create a CMS looking Google Form with a number of fields that represents the different content on our page. Once the content creator have filled in all of the fields, all of these responses would populate a Google Sheet and the Google Sheet would be synced to Figma. And the great thing is that the content creator would just have to look at Google Form and then the Figma preview without even looking at what was happening behind the curtains.

Content creators would submit their form with all of the content, I would click sync and the design would just come to life in front of my eyes and in front of their eyes.

It becomes interesting when you start to play with technology a bit. Even if it’s an exercise that is as simple as this, it really forces you to learn the tool. It just changes your approach with technology.

It opens up interesting opportunities and, in the long-term, if you do it long enough, it really helps you think about tools, not for only what you’ve been told they can do, but what they can actually do: what is the potential there?

You’ve met Benjamin. You’ve met Lorenzo. Now meet Trys.

My name is Trys Mudford and I’m a front-end developer at Clearleft.

Trys has a story about a skunkworks project ...for a library.

We carried out a project with Suffolk Libraries in 2020, and that was redeveloping their whole site. And part of that was porting a lot of content over into the new site. And one of those things included mobile libraries.

Now that was previously represented as a HTML table with 800 rows in it, plus all of the stops where a mobile library van would drive to and stop, and it included the place name, a little description and then the time and the day that it runs.

And this wasn’t an ideal way of browsing that. You have to search the entire list. There was an A-Z clicker where you could jump down to the point in the table with your town name, but not ideal.

So we were wanting to improve the experience on that. And the natural final conclusion was a interactive map of some sorts where you could type in your own location and it would bring up all of the mobile library stops centered around you and you can see which is closest and when it arrives.

But to get that information, we’d need to get latitude and longitude information for 800 of those stops, which is no mean feat. You don’t really want to be moving around on Google maps and finding that information. It’s a big admin task, and really it’s a task that only the drivers of the mobile libraries could do accurately. A lot of these places were based on local knowledge rather than distinguishable factors that a computer could search on.

How could we capture latitudes and longitudes for a huge list of items without being in the area ourselves and without a huge amount of effort on anyone’s part.

And the idea we came up with was a progressive web app that the drivers of the mobile library vans could take out with them on their phones or on their laptop. And they could drive to their stop as they usually would, run their routes, and when they got there, they would press a button that would use the GPS on their phone to locate them, store the latitude and longitude on the device, and then a little later date, we upload those back into the system and we have filled out our entire catalog of latitudes and longitudes.

And we discussed this with the client and the initial reaction was, well, that sounds like an awful lot of work to do. I think in their mind, maybe they were thinking in terms of native apps rather than in terms of a web app and the amount of development time that is often associated with that. But in my mind, it didn’t seem like a huge task really. It’s not a million miles away from some things that I’ve done in the past of having a progressive web app that runs locally, that stores data on the device.

And I think this is what made it slightly harder to get the go ahead on the project, because we were effectively creating a thing to collect data once and then it would never get used again. And so for that reason, we didn’t put much in the way of design time. In fact, I just did it myself. But yeah, that does sound like a bit of a tough ask.

But when the choice is either someone needs to sit down in front of Google maps for a long number of days, or we can bolster our additional team with this web app. And they can collect it as they go. It sounded more appealing. Yeah, we got the go-ahead.

The beauty of this is that they didn’t have to go out and do additional collection of data. They could do it as they ran the mobile library. And through lockdown, they’ve changed some of the routes so they’ve been reintroducing the mobile libraries as they go. So they’re still collecting the data, but as far as I understand, we’re pretty close to getting a full dataset.

Okay. It sounds like it was made in a quick prototype fashion. But it was also a working web app. Is this technically a prototype?

This is more like a rapid build. So it was a very short amount of time, a very focused piece of work. And written not to be necessarily as resilient as a full production piece of code would be. But in knowing the medium where we were gonna be using this, we could reduce those variables. So I knew that it was only going to be run on mobile phones that had geolocation and local storage and could run this thing. So I didn’t need to worry too much abouts upporting internet Explorer. Or how would this work if JavaScript was turned off? Because there was such a limited number of devices I knew this site was going to work on.

So not a prototype then.

I think there’s a difference between like a rapid build and a prototype. A prototype, it’s a way to demonstrate a problem, to visualize it, to potentially get buy-in for more funding, or to break down a problem into smaller chunks so you can tackle it more successfully.

Prototypical code isn’t production code. It’s quick and it’s often a little bit dirty and it’s not really fit for purpose in that final deliverable. But it’s also there to be inspiring and to gather a team and show that something is possible. It shows that it can be done and that it can inject an awful lot of energy into a project.

And you can use them to get buy in to something bigger, but it also has a slight downside in that It’s easy to write prototypical code, show something, and people think, Oh, brilliant, we’re just 10% away from the final output and getting this live and actually, in a prototype sense, it all needs to be rewritten.

The first 90% of the code accounts for the first 90% of development time and the remaining 10% accounts for the other 90% of development time. And when you’re writing quickly and you’re showing someone something you’ve created quickly, that final 10% is all the nuance and the resilience that needs to be built into the thing to mean it can actually be used by people.

So there is a danger there of showing something too early to a client or to the rest of the team that they think, Oh, we’re nearly there.

Certainly potentially in the minds of stakeholders or a product management team, that the thing is nearly ready, can’t we just push it over the edge? And so I think you need to lay out that this is throw away code we’re writing. This is to prove the problem. And often therefore, it’s good to leave a level of design fidelity off the product so it intentionally doesn’t look finished so there isn’t any confusion as to whether this is the final thing.

But it still has a real power.

Trys, Benjamin and Lorenzo are using prototypes in the context of a design agency, Clearleft. But I wanted to know about how prototyping works in the product world. And I knew just the person to ask.

My name is Adekunle Oduye. I’m a UX engineer based out of Brooklyn, New York. Currently right now I am at MailChimp working on the design system.

Adekunle told me about how he uses low fidelity prototypes.

What hit home for me and what I live by right now is making sure when I’m building something, I’m firstly building the right thing. Am I building a solution that’s solving users’ problems, but also benefits the business? And then build the thing right.

You want to make sure you’re building the right thing and then, then you can focus on the actual UI and making sure it’s cohesive with the design and brand.

And I think that’s problem when you’re doing like these high fidelity mock-up like, sometimes you’d be like, okay, I have to clean up this code and I think sometimes that draws away from what the prototype is actually meant for. It’s meant for it to iterate through solutions and making sure you have the right solution before you invest time to actually build it out.

I just want to make sure that this is a good workflow. This is like the actual problem we’re trying to solve. And as I understand the idea more and the solution starts to get more clear, that’s when I start to up the fidelity of the prototype.

In the beginning, I’m not really focusing on the aesthetics and sometimes not even thinking about what kind of content is going to be there. I sometimes use placeholders because I think the hard thing for me is like coming up with content that makes sense. And then this is where I can like work with other people. So I work with the content person. I’m like, "Hey, this is the copy I came up with. Do you think there’s a better way of communicating that?" And that’s where I kind of like the idea of prototyping, because it brings people from different disciplines together, focusing on one specific thing, which is the prototype, which is providing a solution for a problem.

But these prototypes don’t speak for themselves.

You have to prescribe what kind of feedback you want as you’re doing product design. Cause I think a lot of times what I was doing before, I was like, "Hey, here’s my design, what you think of it?" And I think in most cases, people give feedback that’s not very warranted.

So if I show like a wire frame, like, okay, so I’m looking for some feedback on the user flow and how does it solve the actual problem for the user and all this other stuff.

It’s a communication tool, but you still have to have someone that’s guiding that tool itself. Because when you’re going into meetings oftentimes if there’s no prototype present, people might not be aligned about the solution or the idea.

If you have a prototype in there, what ends up happening is like everyone could see like the solution you come up with, and then we can talk about it from that perspective. Like, Oh, is this the right solution? What’s not working, what is working and whatnot.

If you’re like building something and you’re not really sure if it’s a right solution, use the word prototype versus design, because I feel like when people say design, that’s like the end result. So I feel like if you say prototype is like, Oh, it’s a work in progress.

Whatever feedback you get, good or bad, is always going to make the solution better.

If it’s negative feedback, I would just consider it a lesson. I was like, all right. So what about it didn’t work? Is it we were focused on the wrong solution? Or maybe you don’t understand the problem.

If you feel like, okay, this is the right solution. Okay, cool. Let’s start doing a higher fidelity. Maybe you want to add more features or make some enhancements, whatnot.

Whatever the outcome is, you’re basically going to figure out what to do next.

I asked Adekunle about the issue that Trys mentioned when high fidelity prototypes might lead to a false sense of readiness.

One of the things I consistently see is if you have this high fidelity prototype, but like, “Oh, this looks like the application. Let’s just copy whatever you have here and paste it into production and it should work.” But obviously that’s not the case because there’s a lot of things that have to go in to like making sure that prototype is ready for production.

When you’re prototyping, not really thinking about clean code. You’re not really thinking about accessibility too much. You’re not thinking about doing unit testing and whatnot. So you have to do all those things prior to having the prototype into production.

Once you know you have the right solution, now you have to make sure that you build it right.

But when it comes to testing with end users, that’s when a high fidelity prototype can make all the difference.

A lot of times you get better feedback from interactive prototypes, because they’re closer to real things. And if you have the time, if let’s say the user is a current customer, you can plug in their data into the actual prototype and you could really see like what they feel about it. And maybe they can play around with it for like a week or two and then get feedback from there. And I think that’s a good way to kind of making sure that you’re building the right thing.

My thanks to Adekunle, Benjamin, Lorenzo and Trys.

And thank you for flying Clearleft. It’s been a pleasure having you on board today, and we wish you a pleasant and safe onward journey.

Thank you for listening.