Toggle navigation

The Process Behind Creating a New Digital Product

We recently had the chance to chat with Justin Mitchell, Founder and CEO of SoFriendly and YAC. We talk about design process, the importance of understanding requirements and how to use that to take an idea and make it real.

What's your career background?

My background is startups. I've been working at startups since I was 16. I got hired in high school, kind of had that unique life as a high school student of having a History exam in the morning, but shipping product to a customer at 2:00 AM the night before.

Not a lot of my friends really had to deal with that, but it was something that I got introduced to very early on. I did UI, UX design. I dabbled a little bit in development. I learned a lot about embedded IoT (Internet of Things). We were building an in-dash car stereo system for an electric car. Before Tesla was really, Tesla, it was another company out in California. I learned a lot while I was there. It was a startup, so you learn on the job and everybody wears many hats. I was a designer, also a developer, and I was also a product designer and a manager and all those things.

I worked at a couple startups in college. And then I had an idea for my own product and I pitched it to the old CEO from that very first company and he thought it was a cool idea. So we pitched it to another guy and formed a little startup and raised a couple million dollars. We actually took that company public about 5 years later. We IPO’d. There's stock on the stock market and all that jazz, but I learned a lot while I was at that company about user experience design, product market fit, product design in general, and the importance of talking to your customers.

I spun out of that company, created a design agency called SoFriendly, and that's where I met my cofounders for YAC. I brought them in very early to SoFriendly and we built a lot of products and SaaS products for other companies. Mobile apps, we did everything from branding all the way up to full development design. Now, we're just kind of turning that around and focusing on our own product with all the principles that we were pushing on our customers.

What's your design process?

I think one of the first things from a design process perspective is requirements. Asking, what's the scope of this? Even if it's coming from an agency background, we look at client scope, whether that's an entire mobile app or a set of features that they want to add to the mobile app. You kind of approach it with the same perspective, which is, let's break it down to what the requirements are. And the way we do that is actually starting with wireframing. Whether that's simply just doing it on a whiteboard very quickly, just start drawing something on a whiteboard and throwing stuff together.

You wouldn't believe the number of times that we'll go to add a feature to YAC and we'll start whiteboarding it really quickly and realize, “Oh my gosh, this totally breaks a million different things. Trying to implement this feature is going to break UI elements or it's going to cause a flow that is going to break another flow that we had created.”

You're always thinking 2 steps ahead. We've got a couple sprints that are being worked on right now. What is this feature going to do that might break things that aren't even live currently? So, yeah, we typically start with just sketching stuff out on a whiteboard. Putting it in front of the team, making sure that we're all on the same page when it comes to how the things are going to be built out from there.

A lot of times we'll dive into wireframes. However, we may skip wireframes if it's something for YAC and we already have all of our visual design built out in a sketch file or something. For clients, we always did wireframes as a first step, low-fidelity, black and white. One of the main things that we learned early on was no matter how many times you tell a client that they are wireframes, they will think that the app is going to be in black and white. It's going to have this weird, sketchy look to it… We started doing really low-fidelity ones that were just boxes and squares and circles, with simple buttons just to give it to them and say, all right, does this cover all the bases? Are all the features that you asked us to get in, here? You see them accounted for, right? Don't pay attention to necessarily even where they are, but just make sure that you can get to feature A, B, and C from this, and this screen.

And then from a process perspective, we typically dive into mood boards, or go straight to individual design and mockups. Whatever we think is the central screen for whatever we're working on. If it's a website, maybe it's the homepage. If it's a mobile app, maybe it's the tab that that feature lives on. What is that going to look like? And that gives us a base to start the rest of the design process.

I think clients in general typically communicate best with, “I saw this thing that I liked here. Could you make it look like this?” And a lot of times it's when they pick it, you're like, I don't know what you like about this. This is so far away from what you've explained to me that you need, is it the colors? Is it the style? Is it the UI controls? You're not being specific.

And so if we can take a jump on that and be the ones that create the mood board and explain ahead of time, what do you think of these colors? And just have a color mood board. That way they don't get distracted by everything else.

And what do you think of this list view? And have a mood board of all the different types of ways to show lists. Then when you present it to them, you have the power and you get to control what they're seeing versus a lot of times it's, “show me something you like,” and then they send you something and you're like, this isn't going to work at all. This isn't even in the same realm of functionality. What do you even like about this?

Mood boards are a good step for us because it gives us back the power… We picked the stuff ourselves and we're excited to build whatever they pick out of it. It prevents them from picking something that just isn't gonna work.

Once you have a new product idea in mind, how do you take the idea and move it to design?

I think the first step is prioritizing. There's a lot of ideas, especially in a company that's just filled with a bunch of creatives. We have ideas every day, but the first step is figuring out... where does that lie along the path of our priorities for the company? Or for the product? Where does it fit in the backlog of existing ideas? A lot of that has to do with just prioritizing it. After that, once you figured out, okay, this is something we need to move on, I'm assigning it to the right people. Again, we usually whiteboard it very quickly just to figure out if it's even gonna work. And then we'll try and do some sort of cost analysis on it. This is something that we're trying to get better at as a startup. If we've done our job correctly you can figure out if it fits into the scope, or it doesn't. You're burning your own money and you have to figure out, do we pay for this? Do we not pay for this? Who do we assign to this? I think one thing a lot of people know about us as a team is we're very focused, but at the same time, we love doing side projects.

I think we're getting better at it, but just trying to figure out the impact and cost has so many levels to it. It's not just monetary, right? It's time cost, it's effort, it's drain on the company or your brain even. So you have to figure out, like, this is a one week feature, or it's a 2 week feature. Is this a, everyone is going to have to work on this for a year to figure it out type of feature? I'm casually throwing ideas about how we could implement machine learning in YAC and there's a lot of cool stuff there. But then you have to temper it down and bring it back to reality and go, okay, if we did that, we would have to completely focus on that for a very long time and there's much higher priority things right now.

Do you have any tips for wireframing?

Wireframes are essential to the very first step, I do them a little bit differently than a lot of other companies do. If it's a very complex app, but there's only a couple core features to it, we will only do high-level wireframes. I don't do 75 screens of wireframes. A lot of times we'll do the home screen, feature one and feature 2. Maybe 5 wireframes total. And we'll say, Hey, how'd these look? What do you think about tab navigation? Or what do you think about hamburger menu navigation? Wireframes give you enough fidelity to see it and say, Oh, no, I want all the actions at the bottom of the screen with icons and words or, Yes, putting them into a hamburger menu is great. Or something as simple as, I love that Tinder swipe UI. That's perfect. Right? They get a high-level understanding of how we're going to accomplish this (through design).

If it's an app that is maybe even a two-sided marketplace, like we just did. It's Uber for maids. You can hire a maid and they'll come into your house and you have to say what services you want and they have to get an address and there's payment. I mean, it's pretty complex.

We did wireframes for almost every screen on that one, because there's 2 user types. You've got the maid type and you've got the actual customer. There's payment and money flowing between the two. We want to make sure we don't miss anything, so we did wireframes for everything. We'll present those typically in the tool that we build them in, like Balsamiq or Flinto or any of those other tools that we like to use.

Otherwise, we do an InVision board versus the actual InVision prototype. The reason why we use a board for very early stuff is because you can see all of the designs without having to hook up all the clickable prototype stuff… They get to see everything all at once. That's sort of our first step, making sure we accounted for everything.

But everyone makes some weird assumption that that's how it's going to look. And so one of the things I always note is like, no, no, no. We do this on purpose. It looks like that for a reason. And it is because we don't want you to go in with some bias on color or style. So we've made it in this kind of exaggerated style so that you can just focus on the pure UX or pure functionality side of things. Having that note upfront, it just saves you in the end. I can't tell you how many times we'll get comments on a design where they're like, “Yeah, I love this, but I didn't think that the app would be in black and white”. We’re like, Oh my God, I forgot to give them my note at the very beginning again.

What happens after you launch or finish a project?

You're never done. Never finished. Right? There's always something more you can do. So a couple things. One would be just the general statement of you never learn if you don't ship. This is something I'm guilty of, especially as a CEO, being overly perfectionist about my product. I come from a design background, so even if I'm not the one doing the actual designing, I look at whatever we put out as a reflection of my own work. So I want to make sure this thing is perfect. But you never learn from your users if you don't ship something. And that pertains to shipping a product in general. And it also pertains to a feature release.

What we've definitely learned, especially on the startup side of things, is to just get stuff out there, see how people react to it, and then react quickly. I think one of the superpowers that our team has is quick iteration cycles and that we throw something out there, we can get feedback and then we can very quickly put a new version out there based on that feedback.

You would never even get to that step if you were being overly picky about getting it launched. Shipping is a huge part of what you do when you're finished. Just get it out there, get that feedback.

Well that is it! I hope you all enjoyed learning from another talented product creator. Please reach out to us if you have any questions, and as always, Happy Designing.

By Billy Carlson
Got questions or feedback? Email