Interview

"From a design look and feel, it should all operate the same. It should be familiar."

How does Product Perfect approach software product design in general for its clients?

Jeff Sherwood:

It's important to just zoom out on your product suite, look at things holistically and understand what the full suite means to the customers, what problems it's solving. It really should be seen as a broader picture of the entire suite. It's important to identify the goal and what it is and communicate that. That storytelling and that cohesiveness is pretty critical to the product's success.

How does approach that play-out among the client's teams and key internal resources? 

Jeff Sherwood:

Specifically the product ownership and how the product is managed really shouldn't be delegated, in my view, down to PMs. There should be a product owner on each one of these software suites or software products, that rolls up into a product leader. And then that product leader is basically discerning and delegating the goals, the broader goals of the company and what they're trying to accomplish with these products. But down to the designer level - or not down to the designer level, designers are very important - but I would say you have a similar structure. You have someone who's more of a framework approach to the more holistic look and feel and brand of the company. And then down into a head designer for each one of those products that is carrying on that message and that broader vision down to his teams.

How do you pair-up with a product owner on the client side?

Jeff Sherwood:

A solid designer is, in large part, in lock-step with a product leader or even has that skillset themselves; they understand product. It's not about just how it looks and it feels; it's about creating creative solutions to complex problems. And a solid, very good designer carries its weight in gold in producing solutions for that. An experienced, seasoned, solid designer is many tiers beyond that conversation. It's really more about building a tremendous product and they understand how their product is built, the process from their sketch work flow or their Figma, and on to a development team, working with the product leaders, working with engineers, that is very valuable.

What sort of mentality is at work when working together on a software product user experience?

Jeff Sherwood:

The larger entities, bigger companies, they have a harder time, they're more risk averse. Also, their product development strategies are very defined and cut and boundaried, whereas I think a lot of these up-and-comers and smaller firms and agencies and startups are able to be disruptive because there is an appetite for risk. There's also the ability to brainstorm and creativity is encouraged and to really come up with new ideas and solve problems in a way that's unique. You design your idea, you get the feedback, and you come back to the design, and you can just do this over and over again. It's very important to continue to talk to your end-user as often as possible, get as much feedback on every step of the way. At the end of the day, we're trying to solve a problem.

How does the vision or goal of a software product materialize in the design work?

Jeff Sherwood:

The hierarchy is pretty critical. What is that software for? Who does it serve? What is its purpose? Having some sort of tie-in with a broader brand vision, it's a resource, a central resource that everybody on all the team leads can point back to and say, "This is, in most part, how things are expected to be," whether it be an interaction, a design, a workflow, a brand continuity, a strategy, these central resources should be available to everybody, and they should exist. In a lot of companies, you'd be quite surprised, they don't even have a basic style guide. Someone's really got to evangelize for this. This is an important role. And then that person needs the freedom to be able to evangelize. That voice needs to continue on throughout any kind of product discussion and brand discussion or a company culture discussion, that there's continuity and that everything aligns with the broader vision of the product.

Their identity in that ecosystem should transfer to all the products. It should be a very familiar experience. From a technical point, yes. From a design look and feel, it should all operate the same. It should be familiar. I should have some expectation of what to do, if I want to execute a certain action within this suite of software. It should all be hit pretty similarly.

Can you speak to the critical nature of software product design as it relates to complex business processes?

Jeff Sherwood:

Certainly. I think it’s absolutely intrinsic to the nature of software development that software products follow a comprehensive and well established series of professional development practices in order to even have a chance at honing-in on a good design for a software product. Most of what you see today in these larger organizations is a combination of many years of evolving software products and conflicting business requirements that eventually will inflict a heavy burden on the user experience. The UI just gets buried in nonsensical features. Software user experiences are usually overly complex. And yes, the business processes are absolutely complex, no doubt… But the software that tries to address these complex issues doesn’t have to be so difficult or weirdly framed. It can still be simple and clear and crisp. But it really takes a combination of leadership and disciplines. You have to have both. You have to have a team that rallies around the right processes and methodologies for systematically going in and evaluating every screen or every major business category that is addressed within the software, and turning it into something that’s really easy to use and easy to understand. But ya, it’s absolutely important to not forget about investing in the design phase of a software development project with full attention to experiential concepts, user interface elements, negative space, all of these sort of heuristics, that we’ve seen in consumer products and well-known brand names that we’ve come to know, and love, but perhaps not in our business software applications so much. 

Why do you think businesses abandon the software product design expense, and choose to invest in development instead?

Jeff Sherwood:

I think that’s a really good question actually. I think it really comes down to education and understanding. A lot of IT managers and VP of software types. Just simply don’t come up through the ranks from entrepreneurial beginnings. They are grandfathered in from working with their former buddy, or horizontally just shifted into that position. And because of this, maybe many of them haven’t personally invoked their own creative juices upon a software product, and really felt it in their gut. When they were building something they would have seen and felt the need for a designer to help them out. That’s really important to remember, we are all so human in our thinking, and it extends into the product design and creation process. I also think that they have a tighter sense of spending when it comes to design as compared to development. For whatever reason, budgeting seems to constrain the design dollars and expand the development dollars. I think people just sort of minimize the impact or minimize the need for design. I remember reading an article about ‘Quora’, the large unicorn ‘ask any question’ type of text-heavy website. They were actually bragging that they didn’t have any designers on staff. They would just tell their developers to create stuff that looks good. What ended up happening is the developers would rally among themselves a little bit, and come up with their own sort of standardization approach to throwing together clean and crisp, simple, user experiences… They even built-out their own development framework called Webnode. And of course the developer audience that would use it as part of the early adopters didn’t have a problem with that. However, inevitably they’re gonna run into situations where they need a really thoughtful and carefully structured ui framework and tools and layouts and things that sort of predispose the developer into the right juxtaposition, so they really create the right user experience. So later I guess they moved over to React and invested in a design team, and rebranded, etc., so it all worked out in the end. But for many organizations, especially ones without VC funding or early modern tech savvy developer hires - they’d just be spinning in circles and lose tons of money in the process. This is again, in my opinion, a situation, where you’re not really giving the user the best possible experience. And sometimes it will really come back to haunt you.

What are the real differences between design driven organizations and development driven organizations?

Jeff Sherwood:

I think design-driven organizations really celebrate what is possible and are out in front of their own problems. There are two steps ahead, usually. This is typically and primarily because of the situations that they’ve already gotten themselves into that they seem to have learned the hard way. They’ve created products that might’ve failed and then taken two steps back to retrace and re-envisioned the future with a design centered approach instead. Quora was one example, but there are so many more out there. Quora was definitely a development-driven one. I think you could say that Apple is design-driven, and maybe dyson, IKEA, and a few others off the top of my head. They really lean-in to the founder or early drivers being the design leaders, and the early product offerings can set the pace and set the bar for the follower products to live up to. So when you ask what the difference is between these 2 styles, I think it comes down to The personal experiences of the founders or the core leadership team that’s driving the software development process. If the founders or leadership team is well-versed in the impact, the tremendous and far-reaching impact, of being a design driven company, then they’re going to promote and proliferate that mantra and that philosophy throughout the ranks, and really drive it home for all of the development teams. But if they’re not, then, it just simply won’t happen. And then the development processes will really be efficiency, centric and focus on tightening the belt and saving money and moving faster and getting rid of poor performers. All of these things, of course lead to cost savings, which is not bad, considering that most software development projects are more expensive and take longer than they should. But generally speaking, the art and science of software development requires A true appreciation for sophisticated, conceptual, design and complete holistic software, product design, in order to really get it right. It’s a world of difference when you get it right. It’s the difference between companies that went over customers the first time they touched the software, as compared to companies that can’t seem to convince a customer to use the software. 

Is there a breaking point for companies where they finally give-in to the design-first approach?

Jeff Sherwood:

Well, I think there is… It seems like companies will take a stab at looping in the designer later in the process than perhaps they should have. But inevitably they come back to the drawing board and realize they really do need a cohesive and thoughtful design to be at the center of the product lifecycle itself.  And that is, from my vantage point, one of the most important lessons to learn early on in a persons, technology, implementation career. That is, the central tenet of design, being defined as “how it works”, and not the “how it looks”.  But yes, I certainly think there’s a breaking point. Normally, some money wasted is involved, but it just depends on the customer and their threshold for time allotments, and their understanding of the overarching software product development process I think. But yes I think this comes with the territory of the real work involved of creating solid and well-funded software products. You’re gonna have a situation where people just don’t understand the centrality and the mandate for thoughtful user experience and user interface design pre-work that needs to be done pretty much an any software project out there.

‍

‍