fbpx

Dare to be different – cultivating a design culture at Ripjar

dare_to_be_different_3x4

ARTICLE SUMMARY

Sarah joined Ripjar, as the third woman on the engineering team, and one of the first UX Designers. Find out how daring to be different, voicing an alternative view, and standing up for herself has improved the way Ripjar approaches things, and how it has helped them build better products!

When I started at Ripjar I was the third woman to join the engineering team and only one of a handful of females in the entire company at the time. But being a woman isn’t what made me different.

 I also joined Ripjar as one of its first UX Designers, and with that, I brought a different way of looking at things. 

My first challenge was to change people’s perceptions of UX design. A common misconception in the industry is that design is just about what a product looks like and that hiring someone to produce UI designs will magically fix your user experience. The reality is that UX design is a process that, in my opinion, is as much a science as it is an art.  

Understanding the problem 

That process starts with understanding the problem, asking “why” and then “why” again a few more times until you truly get to the root of the issue. Armed with this understanding you can start to experiment with different ideas of how you might go about solving that problem, before testing those ideas, validating your hypotheses, and converging on the best solution. 

In my first week at Ripjar, our CTO tasked me with designing a screen based on what he thought it should have on it. I asked him “why”. This wasn’t the response he was expecting. I explained that good UX design doesn’t start with what you’re trying to build – it starts with understanding the problem.  

This initial conversation was the start of a constructive relationship between CTO and UX Designer, where I was often being called upon to help articulate our understanding of a problem to facilitate customer engagements. I noticed his interactions with customers start to change too. He was asking “why” much more frequently, shifting focus in these meetings more towards the “what” and “why” of the new features we were working on and leaving us more empowered as a business to figure out the “how” later. 

My next challenge was getting our engineers to build things as I’d designed them. At first, there seemed to a be a perception that the designs were – to quote Pirate Captain Barbossa – “more of what you’d call guidelines.” If a design was too difficult, or too time-consuming to build, then its implementation was open to some more creative interpretation. But my designs weren’t random shapes thrown on a page just to look aesthetically pleasing; they were a result of careful decision-making based on an analysis of the user problem that had been refined via user testing. 

Collaborative conversations

I worked with our engineers to explain why I’d designed things the way I had, encouraged collaborative conversations around things that were tricky to implement and came up with new ways we could solve the problem together. Now our UI engineers constructively push back on my designs, call me up on where I might have been inconsistent, and suggest ways we could better meet the user need. Together we are continually improving the quality of our products. 

 When I attended my first Ripjar Christmas party (a somewhat legendary event), I was greeted by some of my London colleagues I’d never met before.  My reputation was proceeding me, and they were eager to congratulate me on what a difference I’d made to some of our core products.  

 Since then, another feature for which I led the design has, on more than one occasion, been met by spontaneous rounds of applause when demonstrated to our customers. This was the result of a few iterations of experimentation and testing and a lot of asking “why”. Our solution anticipated needs they didn’t know they had. Their delight was palpable.  

 Now, three years on, I’m no longer in the minority when I say we should be understanding our users’ problems instead of working through a laundry list of features. Our engineers strive to build high-quality user interfaces that invoke trust and behave as our users expect based on an understanding of their needs, validated wherever possible by testing our solutions. 

 Daring to be different, to voice an alternative view, to stand up for myself, has improved the way we do things at Ripjar and has helped us on the path to build better products. Not only are we growing the design team at Ripjar, but there is a growing appreciation of design across the business. Many others, not just designers, are asking those same “why” questions and looking to upskill themselves in certain elements of the design process. 

One voice can make a difference, and if you’re not sure where to start: I’d suggest maybe trying by starting with “why”. 

To find out more about Ripjar – check-out their Company Profile for more information about their culture, team, and working life.

RELATED ARTICLES

Elena Koryakina, SVP of Engineering at Parallels (part of Alludo), shares her journey into the tech industry, what she's learnt along the way and the...
Ever felt like your voice isn't heard at work? Feel like you need to be more assertive, but don't know where to start? SheCanCode's resident...
Sabina Molka, Director of People Engagement & Development at DocuWare, shares her insights on navigating the path to leadership for women.
Attending networking events can feel daunting, but don't let this put you off! Sarah Lawrence, CEO & Founder of 10 Out Of 10, shares her...

This website stores cookies on your computer. These cookies are used to improve your website and provide more personalized services to you, both on this website and through other media. To find out more about the cookies we use, see our Privacy Policy.