There is no questioning the usefulness of data in design. Data helps us understand our customers’ behavior, something that’s fundamental to good design. But the link between data and design can be a two-way street.
Our design principles underpin our approach to problem-solving and help us make sure we are designing the best solutions for our customers.
And although these principles were crafted with the design team in mind, we have started to see great value in applying them to problems right across the company. For the analytics team, those are data problems.
Here’s how I put three of them – designing from first principles; design in systems, not pages; and value reusage – to work on some recent analytics projects.
Design from first principles
One of the biggest challenges for an analytics team is democratizing data across a company; you want everyone in your organisation to easily access data, and for that data to be structured in a way that maps to their understanding of how the product works.
Being able to think in systems is not just important for designers, it’s crucial for anyone working on complex problems.
Initially, the way we described our product was very different to how our data was structured, making it confusing and difficult to understand for anyone who wasn’t on the analytics team. The easiest, quickest fix would have been to iterate on the data we already had. But “designing from first principles” meant exploring the idea that you should never iterate out from the middle of a problem. We advocate starting at the foundational level, building up the solution one clear piece at a time. This means you’re not constrained by the way things currently are.
Rather than patching up the most confusing aspects of our data model, I began by thinking deeply about the best way to structure it so it aligns to the way we talk about our product. I built upon work done by our research team to define a clear system model of how Intercom works. Having this clarity made it easier to begin transforming our current data, because there was no ambiguity as to what we were aiming for. The result? Getting a step closer to data that is democratic, and easier for everyone across the company to understand.
When time is tight, it can be tempting to hack together a quick fix to a problem that is either based on your current way of solving problems or the standard industry approach. But before long you will end up with a solution comprised of many quick fixes messily patched together. Whether the problem is rooted in design or data, it’s important to check that you aren’t simply defaulting to a known solution, but that you are thinking thoughtfully about the best possible solution.
Design systems, not pages
Systems thinking is an essential design skill. It means understanding how components interact with each other – designers at Intercom don’t design in a silo, they need to consider how their work connects our product together.
Anyone working to solve complex problems is in essence a designer.
But being able to think in systems is not just important for designers, it’s crucial for anyone working on complex problems. Thinking of – or better still, drawing – the system forces you to think holistically, to consider interdependencies and the impact even one change can have.
That “system” can be your product, your company, your codebase or even your physical workspace.
When we started overhauling our analytics database, we physically drew out our infrastructure system. This allowed us to understand the order of certain processes and how changes would affect different teams. We could clearly see dependencies early on in the project and be thoughtful about the best way to add new tasks and processes into our current system.
One of our guiding principles is about valuing consistency over change for change’s sake. This encourages you to work in a way that allows your teammates to recycle and adapt your work and it’s also why things like pattern libraries are so important.
Within our analytics team, we found the exact same principle applies. But instead of colours, fonts and UX components, the reusable objects are queries, metrics and data definitions. Data definitions happen once in the codebase, and further logic is built from these reusable building blocks. This makes the codebase both easy to maintain – if a definition needs to be updated it only needs to happen in one place – and unambiguous, as there is only one definition for each table, field or metric.
Design is not simply about how something looks, but a holistic approach to solving problems. Anyone working to solve complex problems is in essence a designer. Having a set of considered, guiding principles that reflect how you aspire to work can provide an invaluable framework not just in design or analytics but across the whole company.