Crafting a responsive experience for a complex interface

In a recent interview, I had the opportunity to sit down with Paul Hebert, a talented Cloud Four senior designer and developer, to discuss a recent case study involving the creation of an interactive tool for exploring APIs for Cloudinary. Our conversation delved into the challenges faced, the process undertaken, and the valuable lessons learned throughout the project (interactive prototypes in the browser FTW!)

Megan Notarte:
Hey, Paul, thanks for making some time to talk to me today. I was really excited about the case study that you put out for the work that we did on the Cloudinary API Explorer. And I was hoping you could talk a little bit about the process. Um, it seemed like in this case, we had kind of a complicated user experience, um, that we had to make work on all screen sizes and also be embeddable in various places on their website, which seems like kind of a unique and complicated problem. So maybe you can give us a little bit of background and then talk about your approach.

Paul Hebert:
Hey, Megan. Yeah, of course. Yeah, this was a really interesting project. As you mentioned, there were some unique challenges and constraints that we had to work through. And I think we ended up with a really solid end result that I’m really happy with and proud of. Cloudinary was a really interesting client. They provide tools to manipulate images and videos. So you can do things like resize or optimize images. But you can also do some really advanced things, like automatically crop. a video to face in the video or automatically generate video previews with artificial intelligence. So they have a really wide and extensive range of features that they offer. And we were working with them to figure out a quick way for them to explain kind of the breadth of those features to potential customers. And as part of that, we needed to figure out what is the best way that we can quickly showcase not just the range of features, but some of the specific features that are really going to solve common use cases that people run into every day. And so our specific target audience was web developers. You can use these tools from code in your website or app. And we wanted to provide a way that a web developer could not just read about these different features, but be able to actually play with the features and explore and experiment and really quickly get an idea of, wow, this is really cool. And this can solve some real problems that I’m running into with my website or app. So taking a step back and thinking through the process, the first thing I think is really important in any design process is making sure you really understand the challenges you’re facing and the goals you’re trying to achieve, and asking a lot of questions, having a lot of open conversations about, what are the challenges here? What are our goals? How can we achieve those?

Megan Notarte:
There was also like a question about prioritization for the audience, right?

Paul Hebert:
Mm-hmm. Definitely

Paul Hebert:

Megan Notarte:
What, from, from both a marketing perspective, like what makes, what kind of features of the API do they want to promote, but also like, what does the audience, what would they want most to play with? So there was like content prioritization as well, right?

Paul Hebert:
Mm-hmm.

Paul Hebert:
Yeah, definitely. So we had to give a lot of thought to, as I mentioned, there’s this huge range of features we could show, but we had to prioritize what are gonna be most impactful and most effective. And so that was a big part of the process was thinking that through and making sure that we were prioritizing the right features.

Megan Notarte:
Yeah,

Paul Hebert:
And that was definitely

Megan Notarte:
from a…

Paul Hebert:
a very,

Megan Notarte:
No, go ahead.

Paul Hebert:
oh, go on. I was just gonna say that was a very collaborative process. It’s not something that we sat down and spent an hour thinking about and boom, we figured it out. There was a lot of back and forth and experimentation and prototyping and conversation that led us to the end result we landed on.

Megan Notarte:
Right. You mentioned prototyping and that’s something that I always find sort of as a project manager or business owner and whatever my role happens to be on the project. That to me is one of the most fun things to see come alive

Paul Hebert:
Mm-hmm.

Megan Notarte:
because we’ve now prioritized. We figure out sort of generally what we’re building. But then you actually start building small prototypes that we can see. I assume, and I think I remember, starting with small screens was the place where we started. Is that true, and what was the process like for you?

Paul Hebert:
Yeah, in general, I always want to start on smaller screens. You know, when you’re designing for the web, you never know where you’re going to meet your customers, whether they’re going to be on a phone or a tablet or computer. And in general, if you start with a large viewport or a widescreen and start sticking things everywhere in the layout and then try and figure out how to squeeze it down to a smaller size, it can be really tricky to figure out, like, OK, how do I take this big thing and fit it in this tiny box? Whereas going the other direction and starting on smaller screens and making sure you’re really nailing that experience, and making sure everything’s very clear and intuitive and well organized, from there It’s a lot easier to expand on those foundations and figure out wow, how can we take advantage of more screen real estate to you know make this even more impactful or you know make it so that we can fit more things on the screen at one time with those sorts of things.

Megan Notarte:
Was this a particularly challenging interface for small screen?

Paul Hebert:
You know it was because I knew that we wanted to showcase multiple distinct use cases. So we focused on image optimization, content to work cropping, automated video previews, as well as image editing and personalization. And so we had to figure out how can we include all those different features without just making the world’s longest web page. And so we had to think through sub-navigation through these interactive demos. And then we also had to, for each of the demos, to be able to show both the image or video before it’s been transferred by Cloudinary and after. And to make it really interactive, we had to make sure we were including different options and toggles and controls that a developer could play with. And so there was a lot to include in a fairly small amount of space. But I think by making sure that we weren’t losing content or sacrificing content in order to fit into a smaller space, we were able to still provide that full, really interactive, really immersive experience regardless of the device that the user was visiting on.

Megan Notarte:
Was there a place that you diverged from a typical responsive process for this?

Paul Hebert:
There was a little bit. When we started prototyping, we were still trying to nail down some of the specific features we wanted to focus on in some aspect of the design. And we originally were focusing on small screens and kind of building a more, I don’t know if simplified is the right word, but a more simplified, I guess, interface that was really just showing off a bunch of different things you can do with Cloudinary. So we were showing off like 20 different transformations or something you can do with Cloudinary. And we were having conversations with the stakeholders and trying to nail down what was and wasn’t working. And that’s when we started talking through both that we wanted to narrow down and focus more on some specific use cases that we thought were really impactful. But they also had some concerns about making it responsive and making sure that on large screens we’d be really taking advantage of that screen real estate and really making sure that it was, you know, a big impactful, impressive display on those larger screens. And so, like I said, normally I always want to start with small screens and kind of gradually scale up. But at that point, to make sure that we were building something that we’re going to be really happy with on that desktop experience, we kind of took a pause on that and started prototyping on large screens and thinking through that experience, while the whole time, you know, thinking in the back of our heads, we have to build something that can shrink down and kind of thinking about how that would work as well.

Megan Notarte:
Yeah, I think that that’s very interesting because it’s not like a dogmatic thing. Like we always, you know, you always as a matter of fact, I’m always going to only finish the small screen before I do anything bigger because sometimes like especially for some stakeholders, you get to a certain point in that and they do want to see like, I need this to be really splashy on big screens, I want to make sure everything is being featured. So like sometimes we’ll do a little divergent do some explorations around that too. That’s interesting.

Paul Hebert:
Yeah, definitely.

Megan Notarte:
Um, I love it. Uh, what was one sort of big takeaway, um, for you, you are interesting in your own, right? Because you are both a designer and a developer. Um, so that made handoff at least between design and development pretty, pretty straightforward. It was all handing to Paul. Um, but anyway, like what, um, you wrote an article, I think where you learned something about, uh, some, what is that called? the ch units, how do we say it?

Paul Hebert:
Yeah, like character units.

Megan Notarte:
character units. Okay.

Paul Hebert:
I guess that’s what I heard said, yeah.

Megan Notarte:
I like was thinking of that headline in my head and I was like, wait a second. But anyway, did you have like a sort of big takeaway from your work on this project?

Paul Hebert:
I think that this project really reinforced for me the value of an interactive prototype over a static mockup. I’ve worked with a lot of teams where their design process is really focused around getting into Figma, getting into Sketch, and creating these static mockups of, you know, this is what the interface is going to look like on a small screen, and a medium screen, and a large screen. And there’s advantages to that process, but I think there’s also a lot of disadvantages. And on this project, I think instead starting to prototype in code and in the browser, first off allowed us to really quickly get a sense of what it actually felt like. I think a lot of the time you look at one of these static mockups, you’re like, yeah, this looks great. And you hand it off to a developer and they build it out. And then people actually start interacting with it. And they’re like, oh, I didn’t think about this. So this feels a little off. And by starting with figure out those issues and figure out other ways to enhance it or other avenues to explore really quickly because we hit the ground running, you know, sharing a fully interactive prototype with stakeholders, with other team members that they could play with. And I think that allowed us to work quickly and avoid, you know, going down the wrong rabbit hole.

Megan Notarte:
Yeah. Great. Well, thanks for walking me through all of that. I really appreciate your time.

Paul Hebert:
Yeah, of course. It was my pleasure.