Design Your Success: Why Design is Critical at Every Stage of Product Development
Damian Gribben is our Design Lead at Ocula. Based in Belfast, he’s responsible for designing all aspects of Ocula’s products and is the voice of the user during the decision-making process.
Damian has a varied career spanning working in small boutique agencies up to global consultancies with staff of tens of thousands. Over this time, he has designed solutions for a magazine distribution company, various NHS and Government services, as well as a Scotch whisky distillery.
In this feature, he challenges some of the key assumptions on what “design” means for technology teams and reflects on the importance of design in creating meaningful, functional products.
There's a common belief that “design” just means creating something aesthetically pleasing. What are your thoughts on that?
There's a common misconception that design is “we've had this idea, now we need to create something that needs to be interacted with”. That's not all that there is to design.
It's not just the physical creation of an idea; it also goes into the understanding of that idea, why we're doing it, and who we're doing it for.
So, it’s not just visual design, but what does design mean for you?
I think design is as much about building the right thing, as it is about making sure we're not building the wrong thing. It's about not doing something just because we have an idea to build something, but also the validation of that idea.
It's about somebody coming and saying, “right, we're going to build X” and part of the design process is asking those (often very difficult) questions like “why?”, “for who?” and “what's the benefit of this?”. We should also be considering how this “new thing” will affect the experience of the product overall, will it affect affect others areas of the product, and if so, how?
It's not only looking at things with the blinkers of this piece of functionality, it's thinking about things from that holistic viewpoint.
We can always create new functionality - it's just a case of time and effort - but is it worthwhile for our users? Who are going to use it and what's the benefit of it?
How does this holistic approach help make better product decisions?
It’s important to think about the idea’s interactions with other parts of what you’re building. This can encompass things like “does this fit within the platform”, “does it fit within the module?” and “does it fit within the company vision?”.
So, it's keeping that idea of the North Star and being in a position to challenge suggestions (and support them!) in terms of product direction.
Then, of course, we also create the interface or the physical thing that the person is going to interact with.
How did you find joining Ocula to lead our design practice?
Ocula took me by surprise! I arrived and was expecting to have to fight the hard fight to talk to users to do research, to understand the “why” of what we're doing. What I found from the first day that I arrived was that everybody was already extremely passionate about design and research.
It kind of put me on the back foot a little bit, we’ve been doing really good research with the people that we had access to, and we’ve been methodical with recording the insights that had been used to guide decisions as well.
Since joining, how do you think we've been able to embed that design culture in Ocula and our approach?
One of the big things that I find in terms of embedding design and research in the company culture is the fact that everybody, from CEO down, is extremely open to research changing their minds. They have their own ideas and preconceptions, but as soon as there's any form of research or feedback that counteracts that, everybody that I've engaged with is fully open to moving forward using the research.
Sometimes there's a lot more discussion (or a lot more arguments!) in terms of trying to use the research to back up design decisions, but I've actually found that Ocula is incredibly open to that. I'm engaged with saying “we think this, but what are the users saying?”. Every time that we're speaking to users or customers we’re using it as an opportunity to learn from them, we’re recording those insights and using them as a basis for the products direction.
Can you think of an example where we’ve changed our product direction based on something we've heard from user research?
For example, we’ve been working with a key customer to revolutionise their eCommerce business using Ocula Boost. Their feedback on how we present insights in the front-end was great. We had presented it in the way that we thought was going to be useful, in terms of showing the insight and its severity of impact.
The feedback was that they didn’t just want to see issue areas, they wanted to see their opportunities.
I think that was a massive shift in terms of how we approached all of our communications with clients from that point onwards; it was very much “we're not talking about problems, we're talking about opportunities”.
It's one of those things that, as soon as it happens, everybody goes “yeah, of course!” but it's not until you get the feedback from the customer that you see that sense. Obviously, we are talking about problems that need to be fixed, but in reality, it’s highlighting an opportunity for the customer to make more money or an opportunity to do better by their customer.
Even that shift in phrasing has changed how we think about insights as well, which is the core deliverable of the Boost product.
Do you mean an opportunity for the customer to make more money or Ocula to make more money? I’d suggest the customer for the purposes of this article?
How can teams collaborate with a design-orientated focus?
We’ve spoken about the upfront bit of design of “what's the problem?”, identifying the problem statement and validating that problem statement by asking annoying questions. At the other end of that, I see design as being a team sport.
I've talked about research being a team sport, but I believe design is a team sport as well. It's not the position of this “rockstar” designer to be designing the whole thing and coming in with the “big reveal”. Everybody has input into it.
So, it's working with your teammates - your product owners, product managers, engineers and data scientists - to get all of their input on how best to solve the problems. This is massively important because you will never have all of the context.
Getting that team context is really important because everybody has their own information in their heads that will make a big difference to how we build the product in the end!
What are your recommendations for someone else who might be looking to improve how they approach design in their organization?
I think it's really important to bring the benefits to the decision-makers as early as possible. I'm a big proponent of co-design in terms of having the people be in that journey with you while you're doing it.
Going off by yourself and mapping it out to the best of your understanding and then getting people to input … while it can be very time effective, it doesn't bring the engagement with people that makes them feel like a part of the journey and become really supportive of the design process, because they see the benefit of it as it's happening.
The number of times I've got to the end of service blueprinting sessions or customer journey mapping sessions and suddenly everybody has a much better group understanding of what we're doing, why we're doing it and the pain points that we're trying to mitigate.
Rather than the designer come in and say “this is what I think we should do” and everybody just either going with it or critiquing it, going on that journey together means that everybody's part of creating the final solution.
Curious to see how Ocula Boost could work for your eCommerce business? Book your free, no-commitment 15 minute demo including personalised insights here today: Ocula Demo - You can book online!
