Redgate is celebrating its 20th anniversary this year. That’s 20 years of designing and building awesome products that our customers love! Unlike many software companies with Redgate’s heritage, user experience and design has been integral since inception; not merely a nice-to-have or something that is layered on as an afterthought.
I’m proud to work for a company that ‘gets’ design, has been willing to invest and experiment over the years and is somewhere that sees, now more than ever, design as a core part of how we develop new, innovative and engaging products. Solving real problems for real people and tackling some of the world’s thorniest database issues.
In this article, I’m going to take a very quick look back through some of what I would consider, during my time, to be some of the seminal moments from a design perspective.
Design org Design
On the subject of experimentation, over the years Redgate has explored various configurations of the organisation of the design team, in an attempt to model and optimise the setup in accordance with the needs of the division. As skills, resourcing and the portfolio itself has changed, expectations from design and how design should integrate with the wider teams have also needed to change.
This has seen us explore various models for how to organise the design team and with that biasing towards a set of behaviours and interactions that meet the expectations of the business at a given moment in time.
The design team, at one point in time, were co-located, operating as a single, central group established to serve the needs of the division and in some cases, other parts of the business. As a centralised team, they could ensure the right blend of skills and support was available to service the highest priority asks of the then division. As a service, however, more akin to an agency set up, they were a step removed from product and engineering; detached from the day-to-day and less able to influence fundamental product decisions.
Thereafter, we saw the design team moved to a decentralised model, with a notional allocation of some amount of design resource attached to one or more product teams. As a decentralised team, we were more reliant on folks with generalist skills who could single-handedly service the needs of a given product, over an extended period. Being on the periphery created more time for their involvement in wider initiatives and design collaboration, but still left a gap in terms of a designer’s ability to inform and influence the product.
Fully Embedded Model
Over the last few years, the design team has operated as a fully decentralised and embedded team; each working as a core member of one of our cross-functional product team; acting as a peer alongside Product Management and Technical Leadership. Whilst the virtues of fully embedded far outweighs centralised, in my opinion, it does have the negative side-effect of research and design becoming increasingly siloed. There is also less room for collaboration, with individuals relentlessly focused on individual product goals versus the bigger picture.
Design Groups (hybrid model)
Recognising that not all designers are created equal, the needs of a product over time can be vast and varied and the siloed nature of research and design, more recently we’ve experimented with the concept of Design Groups as a hybrid model. This arrangement sees a mixed group of designers with a blend of skills (design strategy, interaction/UI design and user research) attached to a group of related products (or product groups). We believe this model could bring many of the benefits of an embedded model, whilst also tackling the issues of collaboration and product silos.
As you’ll see, there are various pros and cons to any organisation model and there is no real right or wrong; only what’s right for your organization at a given time. You’ll have to accept this means making trade-offs as you’ll bias towards something that might be better optimised for your current situation.
For more on organisational design and cultural implications see our post on Maintaining a design culture in an embedded team model.
Usability Engineers to Product Designers
Way back when designers at Redgate went by the name of ‘Usability Engineers’. This was probably reflective of the industry and job market at the time, and as the title suggests the focus of folks back then was squarely on usability. Either improving the usability of existing products or designing new products, with a relentless focus on simplicity and ease of use.
This approach shore up the foundations of what would later become a de facto approach to designing great products and with that, we welcomed the phrase “Ingeniously Simple”; which just so happens to be the name of this very publication. In practice, that sees for a fusion of engineering smarts and user-centred design to create simple, intuitive solutions to complex technical problems.
However, after many years usability, particularly in a B2B context, has started to become table stakes. Of course, your solution has to be usable, simple, intuitive right? As commercial software led the way, users in a business context were starting to expect that same quality of experience as they would get from familiar commercial products. Basic usability is increasingly becoming an expected hygiene factor, whereby the role and value of design has shifted, first towards designing a more holistic experience and more recently (and certainly in a digital product context) to Product Design.
To address this shift and realign we repositioned and redefined the responsibilities of designers at Redgate towards helping to define and shape the core value of the product itself. Being the conduit between a deep understanding of customers’ needs and the set of associated features and capabilities that would address these needs. UX Specialists become Product Designers and with that, an expectation that they would also play an integral part in defining the value proposition, as well as the resulting product experience.
You can read more about our journey to Product Design and what that means for Redgate in our recent article ‘What is Product Design?’.
Point tools to Solutions
One of the challenges in recent years that has changed the way we think about our customers is a focus on the enterprise. This has started to redefine the types of customers we’re trying to reach and the scale and scope of the problems we need to tackle. As we move more of effort towards serving the needs of larger, enterprise customers, we’re having to change and adapt how we go about understanding and designing for both the buyers and end-users of our software.
With that comes the reality that whilst individual tools or products may address the goals of individual users, tasked with solving specific functional problems, folks in these larger organisations have much larger, transformational goals for which they are looking to vendors like Redgate to assist them with. Value and progress are quite different through the lens of a huge organisation looking to redefine its processes and practices.
As a result, we’ve had to start shifting more of our research effort and employing a different set of tactics to reach, engage with and understand both the current and future challenges of these organisations; thinking about how we might design and integrate a range of products and capabilities to enable them to succeed. How do the goals and motivations of those who purchase and renew our software differ to those who use it day-to-day?
With this comes the need to not only the need to reach a different group of folks, but to also actively and intentionally practice different modes of research. Where our efforts were once very tactical, we now need to lean into more strategic (exploratory) methods and the skills, tools and techniques that go with that; such to widen our gaze and help the business discover and unlock new, channels of customer value.
Research has quickly become the backbone of our product effort and a key part of how we make good evidence-based product decisions; either tactically, within the bounds of a current set of problems we’re looking to solve, or strategically, by identifying new, valuable opportunities. Where an opportunity can be defined as “the gap between customer’s goals, the needs that arise as a result and the degree to which your product(s) address those needs; where the gap is likely to have positive commercial outcomes”.
For more on the subject of research maturity and designing for the need of buyers and end-users, see our post on Designing for the Enterprise and Why research is key to an organisation’s design maturity.
Usability to Design Thinking
One of the most notable changes over recent years was the introduction of a design framework and our efforts to operationalise and embed Design Thinking. At a time when we were frequently finding ourselves challenging the ‘why’ behind what often felt like technology-first decisions, laden with assumptions; often without evidence to support why a change was of value or how it might solve a real customer problem.
To ensure we were spending the team’s time solving not only the right problems, but that the problem, and surrounding context, was well understood, we placed a renewed emphasis on problem space work and the set of research and design methods necessary to enable teams to explore and empathise with our customers; framing and ideating around a better articulation of the problem to be solved.
This was an opportune moment to rethink our training programme and question whether what we were teaching the teams was still appropriate, given the tendency to jump too quickly to solutions to problems that were either poorly defined or lacking in evidence. To that end, we suspended our then UX training, which was predominantly usability focused, bringing in instead the excellent folks at Treehouse Innovation to help introduce and infuse Design Thinking.
It’s worthwhile noting that this wasn’t just training for designers. The framework, the training and even the playbook we later created were intended for a wider, cross-functional audience of designers, Software Engineers and Product Managers. We fundamentally believe (and still do) that research and design is a team sport, and to ensure we continue to create innovative, customer-centric products, we had to level up and change the mindset of the whole product team, not just the designers.
We’ve recently written about our experiences with introducing a design framework and what we’ve learnt about applying this in an agile software context in Double Diamonds are forever….
Design maturity is hotly discussed and debated topic with many facets and considerations, including scale/investment, org structure, industry and founder origins (e.g. technology, design, other). What’s always been clear though is that Design at Redgate has a great lineage! We’re building on a strong foundation, as opposed to fighting an uphill battle and having to challenge the fundamental values of a design agnostic organisation.
That said, we’ve taken huge strides to reposition and rebrand design and its role at Redgate over recent years and continue to learn, experiment, reinvent and adapt, based on the needs of a growing organisation and changing industry. In relative terms, we’re a modestly sized team (11 at last count), yet continue to push forward with our collective understanding of what it means to practice great design and develop awesome products.
We’re certainly not complacent, always up for the next challenge and continue to grow the team year on year, with a diverse and talented bunch of design folk. Who knows what the next 20 years have in store, but I’m personally excited to see where our ambition takes us and proud to have been part of that journey so far.
I’ve spoken in more detail about the maturing of our research and design practices over the years in my recent talk on Redgate’s Three Ages of Design Maturity.
If you’re thinking about your next career move or are looking for an exciting new opportunity in the field of design, take a look at our current Product Design vacancies on the Redgate careers page.