Paradime’s Design Process — an introduction
In the past year, with Paradime we embarked on a mission to help modern organizations solve their data collaboration problem — by being design-centric, focusing on our end user’s experience, and building a UI that people will love.
Data apps are notorious for bad UX, overcrowded/dense UI cobbled together with buttons that are not used 80% of the time.
I am sure if you have searched on Medium “design process” you probably ended up with a ton of content which explains very well, what design process means and the multiple school of thoughts on which framework to use and when.
But why not add one more 😄 — maybe less “frameworky” focused and more problem-solving focussed, to show you how we do it here @paradime.io.
💙 Empathy is not a step
We often read about empathy as the first step in the design process, in isolation, as if you need to go through that step, mark it as done and move on to the next phase.
For us empathy is not a step, it is constant throughout our design process.
⛈ The problem
We spend insane hours trying to understand the problem we are solving, why we are solving it, what are the annoying parts, what are the delight opportunities. This is probably the most critical part because this informs our design and product specs. Do we ask what challenges are our users facing with the tools they are using today? What will make them love our solution?
We do our research, speak to people, find blogs, articles, slack channels and understand what our users are experiencing day-to-day.
🌍 Explore what’s out there
We investigate design approaches based on our use case, find awesome UI/UX for inspiration, equally, we scour the internet for bad UX/UI designs we want to avoid at all costs.
I personally found the latter to be almost more important than the former. It helps set the bar for the no-goes in the UX/UI choices for our design phase.
During this phase, at Paradime we use reallygoodux.io powered by Appcues. This is a great starting point to explore some of the best UX, spanning from onboarding all the way to the use of modals and tooltips. Obviously, we also use Dribbble to get inspiration while building our design.
And this is our golden source of design de-inspiration with some solid bad UI/UX examples.
https://solutionsreview.com/data-management/the-best-data-catalog-tools-and-software/
💡 Come up with solutions
This is where the fun begins. It’s all about creating output in the form of sketches, wireframes, design, prototypes to find the best solution to the problem we are solving.
For our design, we used Setproduct for a solid base of pre-built components as our foundation for Paradime. Using the Setproduct UI-kit, we added our own primary colours, variations, and design. As a result, we moved from nothing to a fully functional UI-kit in a few weeks, which would have taken months.
We use Figma day in and day out and we love it 💙. Thanks to Figma variants we managed to re-organize our design library adding way more depth and variations to every single component while keeping our design assets contained.
We also widely adopted Figma Auto layout — which saved us countless hours not having to think about resizing elements. We joined the beta program for interactive components and it’s soo awesome to build all the micro-interactions in one place for prototypes, this prevents unnecessary noodle soup and allows us to iterate rapidly.
Importantly, during design we are in lockstep with our developers on ideas, solutions and what is “doable” — we are all running against a clock. Also, this helps us not designing a pipedream but designing our UX/UI to solve our users’ problems while optimized for execution velocity.
Yes we are a startup and we move fast, so the balance between great design and speed of execution is key here.
🛠 Build
Design handover is critical for developers to understand the design to the most granular level. This step requires as much attention and focus as building a great design.
We want to make sure that this process is as smooth as possible by reducing friction and ambiguity. Here, less is less, more is better — we add notes to our design, explicit component props values to make it as clean and clear as possible.
We implemented our own design handover system to help in this process to remove ambiguity around auto-layout parameters, design elements like shadows, colours, pixel heights etc. and anything that we think we should point out to our developers.
Credits to Michael Riddering from which we got inspired (Check his great work on Figma Academy).
As a designer, being engaged with developers during the build process, we are able to make compromises on the fly — optimized execution across design and development.
We use Storybook and Chromatic to build and test our UI components in isolation. This creates a collaboration layer, where the design feedback meets the development workflow.
🧮 Learn
Ideally once a design is built and deployed in production we always set time to see on screen-share how our users are responding to the UI, where they are struggling to find things, where they are looking confused and this feeds directly into our design improvements roadmap. At an early stage like ours, quantitative data is scarce but we complement that with qualitative information.
We are a small team that is looking to leapfrog the competition and the only way we can do that is to stay lean, organised and focused. Everything we do is about being efficient with our time and our design process is just the starting point.
