Joshua Gross has been interested in the intersection of art and computers since he was nine years old -- and it shows. He's regularly brought into companies at incredibly high rates to improve their front-end design and user experience, and consult with management over ensuring their products connect with customers. This interview is key for startup founders, programmers, product managers, and people in venture capital: if you're needing to understand what makes a product good for an end user, Joshua Gross is illuminating.
Joshua is currently offering a GiveGetWin deal "Get User-Centric to Win" -- perfect for startup founders, investors, those working on UI/UX, and other front-end developers, product managers, and creatives.
Design Drives Everything, by Joshua Gross, as told to Sebastian Marshall
Design really is the fundamental way a product works and interacts with the end user, the person using the product. It's more than how something looks or how it feels. It's how it looks, feels, works, and you could even go as far as to say it's why it works the way it does.
A chair is designed to fit the human form, for instance. Imagine you didn't take people into consideration when designing a chair, and only took into account making it look good. It could be too skinny, or have a bad angle, or otherwise be wildly uncomfortable. It doesn't make sense to make a chair to look pretty, you do it for people to sit on.
Design means you have to consider who is using the product, and that will define how the product will ultimately look.
Part of design is the polish, but design is the entire process. In the end, there's still an aesthetic and how it looks and feels, and that's part of the design. But you can't start with wanting something to look Victorian. Victorian started because people had limited space, with small rooms and narrow staircases. The polish and prettiness can be artistic at times, but if it impedes the function of what you want it doesn't make sense. If you make things less usable for humans -- if you impeded the function -- you failed at the design.
By learning about design, you benefit. You benefit from learning how different products work instead of just looking at if they're pretty. You need to understand why people made the product to know why it looks a certain way.
When you go to buy anything and make a decision, you can go beyond just looks and think in terms of the purpose it's going to be used for.
If you're in business, better design will ultimately sell more things. If you're not taking the user actively into consideration, you're leaving money on the table, you're impeding them from reaching their goals, and not making things easy and functional enough, and thus making less sales.
People look at Craigslist and Google and they think they weren't really designed, but the form fit the function perfectly. That's good design.
The steps to good design are (1) define the problem, and (2) define the end user who will be using the product, (3) strive to understand their needs, (4) strive to understand the function of what you're creating is, and then (5) look to make them work harmoniously.
Find the problem, find who you're solving it for, and come up with a solution that fits together.
You build upon existing knowledge and discovering what the solution to the problem is. It's not so much about inventing a solution, but instead discovering what the solution is.
Most people neglect this, because they have a misunderstanding of what design is fundamentally. This completely warps things. If you think design is just polish at the end, you won't consider design explicitly at the root when you start. Design isn't just about art forms; it's a problem solving system.
The most important thing is to keep the user in mind. If you lose sight of who is using the product, then you're not solving things for people -- you're just making things up. When you make something for someone, you're always making it for someone. That could be yourself, your friend, or someone who you don't know -- but you do know they work in a particular field.
First, you must always define your user.
One way people do this is through "personas" -- coming up with a definition of who the user is. For instance, a 40 year old mother with two kids who drives the kids around a lot, and has limited time, so she'd use your product during her lunch that's only 20 minutes, and needs to move fast.
If you have no idea, you can interview your users and get their goals. You need to constantly be working with them and getting feedback when you define your product, build it, and throughout the whole process. You should understand the user at the beginning.
If you can't understand them at the beginning, then you can make assumptions. But after that, build the product and test those assumptions in front of real people you want using the product.
People don't do this partially because they are shy. People get scared to test their own ideas and assumptions, because they don't want to find out they're wrong. Or maybe it didn't cross their mind and they thought they understand who their user was, but were mistaken. But it's absolutely an essential part to do every time.
Once you have the user and understand who they are, what they're trying to do, and what their goals are, take that information that you've collected and build your products and solutions with them in mind through the entire process. What features they need, how they need to work, in what context they need it to work, that has a huge effect.
Are people using your product outdoor in the sun, or in a dark room? These have huge effects, and there's dozens more you could think of, and they'll all affect what you choose to do.
It's all about the context. When they use it, are they walking from one business meeting to another? Is it used during the gap time between things and they only have a couple minutes? Or is it something to be done leisurely when sitting on the couch with an unlimited amount of time? Or maybe the context is that they only have one hand free instead of two. Or alternatively, they're in a car and can't look at your product, or look at the screen if it's a web app.
There's hundreds of different contexts, and the more you understand how the user is going to be using your product, the more likely you're going to be able to engage with it how you expect, and they'll want to engage it. It's because it fits their context that they want to be engaging in.
After defining the user and context down, make sure you understand the user's goal. What are they trying to achieve? Are they browsing, window shopping? Are they doing something purposeful, trying to get to some place and know they want to get there? Are they exploring and want to keep going until they feel satisfied? The goal really depends on what your product is, and why users are using it.
If I'm building an online store, my goal is to have a user buy something. They want to find something useful for themselves. Or alternatively, the shopper might not know what they want, and instead want to browse through a category of things to see what's good.
Sometimes the user has a directed goal, and some time they have an exploratory goal. You can choose to support one goal or the other, or both. But you need to keep those goals in mind, and then design for the cases you want to include in your product. What you include and what you design for, will be what users use your product for in the majority of cases.
Now that you've defined user, context, and goal, you can get into the process of building the product. Now you know what your goal is, which helps you define what features you need and which you don't need, because you have this understanding if it's a mom that uses the product for 10 minutes at a time, or a professional using it 10 hours a day at work. That defines the features.
From there, you work on actually building out the visual/wireframes, the user flow from where they start to where they end in the process, and there may be several depending on the use cases you're supporting. It helps the user walk through the process, what information they see, the different things they can touch or poke around with, the actions that they're doing, and that amounts to building the basic general wireframes and the core of how the product is going to work and function.
Ultimately, features are about finding what the core things the user needs to do. You can come up with a long list of things the user might need or want to do, but once you come up with that list, you cut things that are not necessary for 80% or 90% of people, and eventually you'll get with a list you can't cut.
Once your list is things you can't cut without the product failing, you've got what you need to start building. You can always build later, but you want to start with what's needed in your feature set to make the product successful.
You have to build the product, and you need to be able to design X, Y, or Z features. You can then test subsets of those features or new features, but it's all about first finding out what they need by talking to them, watching them try to do the task, or looking at what they've done in the past.
If you have two potential different solutions, and you don't know which is the right one, that's a great thing to test different versions and see which users prefer.
Importantly, don't guess and throw things out there. Google for instance tests a lot of different things without any idea of what's the best thing, but this comes way later on. You need to wait until you're successful to test and experiment with smaller things that aren't the key features.
If you're dealing with minutia and optimizing too early, you dig yourself into a hole. It's called a local maximum -- don't build small stuff perfectly before you haven't worked on the big things.
The key question to keep asking is, "Can the user achieve their goal in the constraint they're working with?" Look on the feature set, and test it against different contexts and the goals your user wants to achieve. These are called "use cases" -- how the user will use the product. If you cut it too light, you might not support what people need and want.
The iPad, for instance, is a general use product but there's many use cases. Sometimes you're in front of the TV while also browsing the web: that time is light, not super engaged, browsing, maybe looking at pictures, and wanting to be amused and get the visual value.
Other times, you might be outside and -- let's say you're a realtor and need to get a signature from someone -- you can open your document and have them sign the iPad with their finger in front of the house. That use case is business, limited time, need to do something quickly. The former use case -- in front of the couch -- has unlimited time.
After you've defined this stuff, you need to think of the user flow. This is looking at what the person wants to achieve, and working the step-by-step. Say it's your ecommerce store. They open your store, search for the product, they see the product page, they can review the product description, click buy, go to checkout page, enter their credit card, and go to the confirmation of purchase page.
After you define that, you can add or subtract steps. Maybe something is missing, or maybe you can make it simpler. But you do want to break down what the individual steps are.
If you're early in product design and you've started by defining user flow and use cases, you can draw these visually in what's called a "wireframe." The most important thing about a wireframe is not the details -- it's not visual details like color, shape, or form. What you're looking is the rough outline of the layout. Where do the controls go? Where does the information go? What's the hierarchy of most important information to least important information? Where do you want them to look first, second, and third?
A wireframe is a simple layout. The best way to do this is to do several different wireframes -- different ideas of how it could go -- and think about which one would be the most successful.
Whoever is defining the product -- the layout -- works with the designer to do this. The product manager should have input here, and of course your programmer should be on hand to make sure it's feasible. You don't want to wireframe something that isn't possible or is too complicated
The hierarchy of information is defining what the most important information the user is looking for and what you want them to see. For an ecommerce store, that might be name of product, photo, price, and description. And you could label those 1, 2, 3, and 4.
Maybe lower in the hierarchy is an extended description, reviews, rating, and technical specs like what batteries the product would use.
You'll have calls-to-action mixed in. What can users do? Things like "Add to Cart" or "View Similar Products" also are important, go into the hierarchy, and you have to understand their importance and then present it in a way that the user understands. You don't want to put the title and the price at the bottom of the page unless there's a very good reason to do so.
There's two steps you can do next. You can either have a user walk through these wireframes and get a feel for if it makes sense with their mental model and if it helps them achieve their goals. Or if you don't want to jump back to the user yet, you can go to do the visual design and get the look and feel down.
The way it looks and functions is really dependent on who is using it, what's their level of expertise with the product in general (or computer expertise in general if it's on a computer), and what's the brand of what you're trying to achieve? Apple and Microsoft have different brands because they are trying to achieve different things. You can tell a product is Apple-like or Microsoft-like by seeing it even if you don't see the logo.
But remember, you must make sure the user achieves their goals, so don't add visual noise that gets in the way of that.
Next you could test it with the user again, or you could start building out a prototype. Once you're prototyping, you're building the product.
Now you have to start doing it, then definitely start testing. If you're building an ecommerce store, ask a user to buy a lighter from it. If it's too heavy to build all this right now -- if you don't want to build the whole backend framework right now -- you can build a dummy workflow and ask users to try to work through it.
Before you show this to the world, get friends and random people to try your prototype. If it takes five minutes to do something you thought would take 1 minute or less, they might not be acceptable, and you only find out by trying it out with real users. Bring a few people in to use it, clear up anything you forgot, show you if you made any wrong assumptions, and see what happens with real people.
At this point, you've find out what works, what doesn't work, and now you can go and finish the product. At that point, you can then launch it. If it fails to achieve the goal at this point and the user can't do what they want to do, you have to go back and revise. If your base assumptions are wrong, you may have to change the product.
AirBNB, for example, tested their idea by renting some airbeds themselves, putting up a basic website, and see if people rented it. They rented out apartment space and saw people were literally interested in renting a bed on the floor in an apartment confirmed their assumption, and they could keep building.
Most cultures don't execute the design process well because they don't understand how inherent design is to building a product. They misunderstand what design is for, or don't understand the value it holds. So they don't think to apply it from step one (or even step zero). But ultimately, the value of having a design-based culture at a company is that it will help you understand your users more, which ultimately in helps you connect with your users, which helps you make more money.
The more you help your users achieve what they want with your product, the more likely they are to buy it, to use it, and use it more.
Some companies with bad design culture have someone saying out of thin air, "Now, we should do X." I've seen this come up over and over again, random ideas that don't help the user. The person might "umm" and "ahh" and try to connect it back to the user, but it doesn't work. That's thinking user-last instead of user first.
Any time you start a new product or think of introducing a new feature, you have to think about this from a design perspective. Ask, "How does this help the user achieve their goal?" If you want the user to do something new, ask, "How do we help them get there?"
Go back to the assumptions. What contexts? How are they solving it now? Ask what isn't working now, or what could be better.
By being at a design-first company, you avoid arguing based on assumptions between a group of people. People like to think they have an understanding of the user without actually confirming the assumptions. People tend to use their own personal experiences too heavily, and not talk to actual people who would use the product. That leads to wrong assumptions and lots of debates.
Instead of that, just go talk to the user and have the information you get inform your decisions.
Politics is an interesting thing to navigate, because everyone has their assumptions, and some people hold them more strongly than others. I've found the best way to navigate these is two things -- first, make a clear decision on who gets to make the final decision on how the product works. With a new product, you'll typically have a designer, product manager, lead engineer, and the CEO. You discuss what the product is and what you're trying to achieve, but beyond rough outlines, you led the designer do the legwork, research, find out what the user wants and needs, and they'll bring this information back. Instead of going on assumptions, use this information to build out the product. From there, the product manager and engineer reign in exactly what it's going to do. The engineer defines what's feasible and executable in the timeframe you've got with your team, and you build it.
If you have a smaller team, say two engineers, then you still have to do the legwork to work up the designs, or bring somebody on to help build out the visuals. Don't nix any ideas or shoot any ideas down from the engineering standpoint before you flesh out the product.
You can always come back and change or remove something later that's not feasible from an engineering standpoint. But do this later, don't cut out solutions that the user would want for feasibility earlier. Don't eliminate from a company or engineering standpoint too early, because you might want to go down those roads and see where they lead.
Why should you start with testing? Just like many entrepreneurs, I started my career by building things that nobody wanted, and wasted a lot of time and money. Embrace design, start with the user's goals, test everything, and test those assumptions constantly, and you'll build something people actually want to use -- and make a lot more money.
If you're involved in product development, entrepreneurship, or investing in startups, you'd likely benefit tremendously from Joshua's GiveGetWin deal, "Get User-Centric to Win."