“Good Designers Are Good Users”

 

Andy> The world’s most successful digital products have dedicated product teams that deliver value through endless rounds of UX research, experimentation and design. Their work is never done. They're able to build on learnings over time and become experts in what the business and its users really need. They adapt to new information all the time, and refocus priorities without fear of disrupting a fixed plan. Free Association’s aim is to build on what has proven to work well there and offer the bonus of outside perspective as an agency partner. Our team loves this model too because they get the best of two worlds—the variety, pace and inspiration you’d expect of an agency experience, along with the depth of understanding and rewarding view of ROI that’s typically only found working on the brand/client side. 

Bren> I’ll add that while our partnerships are long-lasting, that doesn’t necessarily mean individual initiatives are on that same timeline. Often we’re focused on something quite immediate, but it’s about building long-term expertise without becoming too insular, which the agency models allows us to do. We can constantly match the right team members with the right initiatives, while staying consistent in our approach and building on previous learnings. 

Andy> With a product focus we get to spend more time uncovering opportunities and problem solving through design, which is simply where we’re at our best. Our team is more compatible with the processes that come with evolving products, vs. something like creating a one-off digital campaign experience. We value evidence-driven design and find that our partners who have product at the core of their business strategy do too. They're willing to invest in ways to inform and validate thinking as we go, because they understand the potential of design-driven growth is massive. Also we love branding, and through our product work, have been invited in to help many leading companies evolve and expand their brands through product design systems and related efforts.

 

Bren> We’re not so focused on differentiating ourselves through purely aesthetic outcomes. Instead, we care about business outcomes, like how many more customers were we able to activate through this new feature? Outcomes like that naturally take us away from what we might call “design choices” and instead make us think about “product decisions”. Often these have much more to do with how something behaves or interacts with users in a given context, as opposed to a subjective visual choice. 

Andy > Design is represented at the heart of the executive leadership team, who works to create a culture where design decisions, particularly around customer experience, are on par with any major business strategy decisions. They recognise the value and efficiencies that come with company-wide brand systems and tools, and the executional guidelines that follow, such as a digital product design system. They avoid fixed-scope specs and requirements, focusing instead on user needs, and running constant experimentation to advance experiences. 

Bren> Another great way to gauge it is to look for the signs of the design process or the things that come along with it - like being customer led, reducing bias, integrating user research - and see how much those ways of thinking have permeated the company at large. 

Andy> We're going on nine years teaming up with Google, and I think the crux of why we work together so well is that we share core values. Like Google, we believe that being great at something is just a starting point—that there's always more to learn and improve, and we can never stop paying attention to users. We've been involved as a UX growth team focused on the Google Store for a few years now. That e-commerce experience was mature and successful by many measures before we even got started—nonetheless, our job has been to design, validate and launch multiple experiments per month to further improve usability and increase conversion. 

We’ve been able to create new value through this work consistently, and the ROI on Google's investment in us has been exponential. For example, our recent experiments brought double-digit millions in incremental revenue, and we think we can continue to build on that. It's amazing as designers to understand our impact in that way, and as agency partners, to validate the ongoing work of our team. Another interesting result is that as our Google partners move on to other career chapters over time, they've been calling us back in. The success of our collaboration and the trust we’ve been able to build has gone a long way, and led directly to other amazing partnerships like Facebook, Waze, Toyota, and PayPal. 

Bren> I think good designers are good users. We always look for ways to become more efficient or make things more useful. The closer we are to the things we’re building, often the better the outcome. So for truly futuristic projects, the ability to slot yourself in as the user is so key. It’s not really a subject matter thing - it’s about how well you can imagine yourself in a different environment, and how your perspective might change if the conditions change. For example, we’ve worked on innovative urban planning concepts like Toyota’s Woven City, https://www.woven-city.global/ which is a living laboratory to test what a “digital operating system” might look like for future connected cities. We’ve also worked on digital interfaces for autonomous vehicles, to the point where we built a prototype in our office to simulate different driving modalities and test various levels of situational awareness. Our company does not specialise in any one of these industries in particular, but our designers are all really skilled in applying the right heuristics and tactics to approach that kind of ‘imagineering’ work. 

Bren> With these projects, we find that stakeholders are often drawn to the biggest bet – what some far-off future state might look like versus today. And in some ways it’s easy to place those bets, or focus on those extremes, because you’re just extrapolating big trends in a more or less linear way. First this happens, then this happens, and so on and so forth. But to borrow on a cliche, often it’s the journey and not the destination which really excites us. It’s almost impossible to predict what’s going to happen between now and some future state, so the best we can do is design a process that’s going to help us fail fast and reach those critical inflection points sooner. Once you get a taste of this, see what it feels like to piece together the clues and unlock key learnings, the more the process itself begins to excite you. You’re less concerned with the “predicted” outcome, because you intuitively know it won’t play out as you expected. 

Bren> The trend for some time in technology has been abstraction - making it easier to build things by turning common development workflows into self-service tools that don’t require as much technical knowhow to use, hence “no-code”. But most no-code platforms are quite use-case specific, and it’s impacted some industries more than others. Almost every e-commerce site today is built with a no-code platform like Shopify, for example, but very few complex business applications are built using these platforms. The holy grail is a platform that abstracts every use case imaginable and is truly industry-agnostic, but that’s quite hard to do, so we’ve ended up with lots of “low-code” platforms, which still require you to learn a very specific kind of syntax, just not a programming language like Javascript or Python. Until now, these low-code platforms have been what businesses use to create truly custom applications. But the next generation of platforms such as Unqork, one of current partners, are building visual abstraction tools that don’t rely as much on complicated language constructs or syntax. The advancement of UX and UI design has allowed platforms like Unqork to create visual tools that span the entire development lifecycle, and empower creators to focus on what their application does for customers, as opposed to how the application needs to work. 

Bren> You need to design for parity across the different product disciplines. The components in your code libraries should match the components in your design libraries. That way, your documentation doesn't have to focus on translating between disciplines. Instead, it can actually help orient everyone around the intent of the design or the rationale for certain design decisions, as opposed to basic alignment on the functional thing. This higher order thinking - UX intent - is where cross-disciplinary collaboration really makes an impact on product outcomes.

Andy> Yes to that, and I’ll add that many of our partners also invest heavily in higher-level brand system platforms that connect channel-specific material (like the digital product design system, social media guidelines, etc.) to business strategy, core brand positioning, resources, brand tools and more. They understand that all of these things are connected, and they’re relevant to anyone involved in brand execution. So they build a single source of truth, complete with ways for teams to give feedback or ask questions directly and improve the system over time. Having all of this well organised, easily accessible and on display company-wide increases accountability for all authors, driving up quality, accuracy and most importantly, speed in decision-making. Teams stop drowning in a sea of one-off slide decks which are easy to lose track of, often contradict each other, and can add confusion with multiple versions floating around—instead, they build on everyone’s latest and greatest, together in one place. 

Bren> To deal with the complex, you need to embrace the simple. The more you try to turn everything into a pattern, the less flexible and unifying it becomes because inevitably people break the patterns. That’s why we focus on building really composable design systems that don’t make too many assumptions about the thing you’re building, or what you need the building blocks for. Then, we often allow individual teams to extend the system to become more application or product-specific, which we sometimes call the “local” level. This way, the complexity of each unique product space is captured at that local level, where it can be properly understood, instead of the “global” level where things need to be as unified as possible.