Published in


Framework-Centred Design: 3 Design Techniques to Create Technical Products

Hamza Oza, Designer, QuantumBlack and Visiting Tutor at the Royal College of Art and Imperial College London

For most people, digital product design means usually one of two things: websites or mobile apps.

At QuantumBlack, we work on another type of digital product — code frameworks. An example of this is Kedro, an open-source Python framework developed by QuantumBlack Labs. It borrows concepts from software engineering best-practice and applies them to machine-learning code. Our previous articles cover why we developed Kedro and the benefits this brings to our teams and clients, as well as to the hundreds of projects it has been used on since launch in 2019.

You may naturally wonder why a developer-oriented product would need design input — isn’t it a tech problem after all? Design insight is crucial in developing products that people actively choose to use and all aspects of the design process, from user research and journey mapping to creating prototypes for user testing, can be leveraged to create a more user-centric framework. In this article we will explore three ways you can leverage design principles to help develop technical products without user interfaces, and outline the various ways these steps have proved useful in Kedro’s continued development.

1. Understanding your users

It should go without saying that understanding your users remains critical to the success of any product. However, Kedro has a wide spread of user profiles both in terms of archetypes and experience levels.

Let’s consider our Data Science (DS) profile. Depending on their exposure to Kedro, the DS might be a beginner, intermediate or advanced user of Kedro. At QuantumBlack we always collaborate in multidisciplinary teams of data scientists, data engineers and designers across our projects, so multiply this by two, three or even more profiles. Suddenly the pool of user types grows very quickly.

Matrix of user archetypes and their experience levels

With this in mind, we constantly ask ourselves how a beginner user may react upon encountering Kedro for the very first time. How accessible is it and what learning journey will they have to embark on to use the product features?

Even when developing new features aimed at experienced users, we always ensure that we engage with beginner and intermediate users as part of our research and testing to source a range of feedback and opinions. This helps us to create a project codebase that will always remain accessible to inexperienced users.

2. Understanding the framework journey

Understanding the end-to-end journey of a potential Kedro project helps us to successfully support our users at all stages, from developing within Kedro to productionising their solution at scale. Let’s consider an oversimplified journey of an advanced analytics project with three phases: project setup, development and deployment.

Simplified journey of an advanced analytics project

It’s easy to argue that data scientists and data engineers fit neatly into the second phase. The setup and deployment stages are typically handled by a different user archetype, depending on the nature of the project. For example, on one project an organisation may be using their own in-house team to lead on infrastructure setup while utilising external machine learning engineers to handle deployment, or vice versa. In other circumstances, external consultants may own the entire end-to-end process.

Crucially, we focus on understanding the journey of the broader Kedro project, rather than an individual user’s journey.

Think of it as framework-centred design instead of human-centred design.

Taking the time to consider the various states your framework will be in, the drivers behind them and the various transition points will help you create a seamless handover experience — increasing the likelihood that the framework will make it into a production environment.

3. Creating prototypes

Prototypes can be useful beyond UI based applications, although we certainly use this approach for Kedro-Viz. For example, you can prototype code using pseudo-code to gather more concrete insights from your users. The key here is to understand what you are looking to prototype. Is it implementing a new feature, or coming up with a new syntax? You may be gauging the impact of introducing breaking changes that could affect how a user will interact with your framework.

Allowing users to interact with the proposed solutions makes the discussion more tangible and enables them to receive a more realistic view of the potential impact that changes might have day-to-day.

Pseudo-code generator to test ideas with users

We were recently attempting to understand how users interact with configuration. For the data catalog, we created a pseudo-code generator to bring our ideas to life. This provided our users with a direct side-by-side comparison, but it also provided benefits to our team. We were able to rapidly identify the core strengths of the data catalog, understand no-go areas for changes and prioritise the areas of improvement that would create a meaningful impact on daily workflows. This was all possible before we even touched a single line of code in the core framework.

Technical product development can be complex, but the ultimate aim should be similar to developing any product — you want to build a tool that goes beyond initial interest to one that adds tangible value to the end-user. Bringing design expertise into Kedro’s development from an early stage has been a crucial factor in the product’s continued popularity with our users and our team has utilised each of these three techniques as we continue to iterate our first open-source tool.

At the same time, we appreciate that these three steps barely scratch the surface of how design thinking can be leveraged when building non-UI based products and code frameworks. We’d love to hear other techniques that you have leveraged in your own product builds — please do contribute your thoughts to the discussion below.

Are you interested in applying these techniques to solve real-world problems? Want to rapidly launch and iterate products across a vast array of industries — or even join us in refining the next version of Kedro? At QuantumBlack we’re expanding our team of Technical Product Designers, check out our Careers page for more information.




QuantumBlack, a McKinsey company, helps companies use data to drive decisions. We combine business experience, expertise in large-scale data analysis and visualisation, and advanced software engineering know-how to deliver results.

Recommended from Medium

How Foxtel’s service design lead uses insight

10 Awesome Lorem Ipsum Alternatives

How can design thinking help small and startup businesses?

Microsoft Office Fabric UI kit: for code-free design

Don’t Go Hungry: A UX Case Study on Cart Abandonment and the Lunch Order

Measuring user happiness

Oraichain Ambassadors Program

The Beginning of my UX Journey

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
QuantumBlack, a McKinsey company

QuantumBlack, a McKinsey company

An advanced analytics firm operating at the intersection of strategy, technology and design. www.quantumblack.com @quantumblack

More from Medium

Mindful Experimentation: Evaluate Recommendation System Performance using A/B Testing at Headspace

The Experimentation Gap

Why It Matters Where You Randomize Users in A/B Experiments

An user flow chart. At the beginning is is a user signup box, and then two paths branch from it. 1st path: user browses for pencils then user buys. 2nd path: user browses for crayons, then user buys. An arrow pointing to the user browses for crayons box, calling out that we’re A/B testing a buy-now button for crayon users only. Finally, there’s thinking-aloud clouds that asks the reader, “do i randomize where user signs up?” or “randomize where user browses for crayons?”

Experimentation-driven development