The Juniper Project
A bit about Juniper…
Juniper's goal was to create an all-in-one software system for primary and secondary schools for the UK market. They first did this by acquiring a number of smaller companies that solved various problems for schools. This ranges from HR, pupil assessment, school to parent communication…
During my time at Juniper, I was responsible for consolidating the different design languages used in various smaller products into a new aesthetically pleasing system for Juniper. To accomplish this, we created the Eldaberry design system from scratch. I was also involved in the process of designing new systems, where I oversaw the user experience.
Working at Juniper was a great challenge as the Edtech world is a complicated place. The software made in this industry is highly regulated and not prone to change. But from these challenges, I was forced to grow as a designer and I'm glad for it. Below I will explain my contraction to this system in more detail.
My Process
Whenever I am given a new project or have a problem to solve, I always start with paper first. Although everyone knows it, not everyone does it. I'm guilty of this too, there are times when I think that I know the right thing to do right off the bat but most of the time that’s not true.
Starting on paper helps me jump between ideas faster and is a more fluid form of ideation. Additionally, jumping into Figma immediately locks you into a single idea for longer, limiting your flexibility.
Once a have sketched out a number of possible ideas this is where I bring them into Figma where I wireframe out the most promising ones. Up to this point, I am mostly designing on my own but once I have the strongest ideas mocked up I start to consult with the wider team and relevant stakeholders.
This process repeats itself as the designs start to get higher res. At this stage, I am referring back to our design system and libraries to make sure I don't stray too far off track with the styling (as sometimes I do.)
Throughout this process, I’m constantly thinking about how the user people might feel when using this system. As although I love to make things visually appealing usability comes first.
Once I have gone through the process and all the stakeholders are happy with the designs, I create a “Spec”. This is the design doc that the devs will refer to when building. In this file, we add example user flows and annotations to give the devs as much info as possible on how we want the design to be built.
First Projects at Juniper
My first block of mouths at Juniper worked on the development of their new HR system. This started with designing forms and moved on to more complicated HR systems. When designing these I worked very closely with our HR product head. These systems are required to have very specific language and data, so the goal for these systems was to make them as clear as possible.
Another series of projects I worked on was for are MIS and Assessment system. These systems focused on the management of pupils and assessments. The challenge with these systems was trying to design a visually clean system as there was a lot of information and actions on single pages. We helped breck up this data by adding them to slide-overs and models.
Design System
We built the Elderberry side by side with the first products at Juniper and we learned a lot. Building a design system alongside live projects has its strengths and weaknesses. The main strength of doing it this way was that it allowed us to gain live feedback against the system we were designing alongside. This made our components and elements highly specialised to the tasks Juniper was trying to solve.
But the main problem we were running into was with consistency. We were finding better ways of designing the components week in and week out which is not ideal for our devs teams.
But we fixed this problem down the line with Elderberry 2.0. Where we built on the strengths of Elderberry 1.0 but fixed the problem with consistency by designing the majority if of the design system first before any development had taken place.
Elderberry 2.0 was a slightly more styled design system with gradients and tricky inner shadows. An overall cohesive and connected design system.
Dashboards
A project I worked closely with the front-end team was designing a blueprint for how our dashboards. This was an improvement project as dashboards are used in the majority of Juniper products so the work in this had a large impact on the company itself.
We wanted to design dashboards in a way where depending on the size of the screen the size of the widgets would not change. The reason for this was to ensure that the content within them such as charts and informative data would not be affected and would not stray far from how they were designed.
We landed on 6 widget sizes that would fit together so that there would be no large empty gaps vertically and horizontally. At one stage we had around 12 wigets sizes but that did not sit well with the dev team so we brought it down to only 6.
For the dashboard to work well on a larger screen we added a max width of three columns to the dashboards. Say a user has an ultra-wide monitor the dashboard would be centered with white spacing on each side. Then the widgets would stack for smaller screens.
Juniper 2.0
At Juniper, there was a change in the development of how the hole system would be built. At the start, the plan was to rebuild all the projects in Ruby on Rails. This development architecture was changed halfway through my time at Juniper to a more simple preach where all old products would rebine in the language they were originally built e.g. Java, C++… The goal of this was to speed up the development process.
Because of this, we were given the opportunity to update the style language. One challenge we ran into with this new system was the configuration of the nav. At Juniper, there are multiple apps that a user can navigate between. This caused problems as there are actions that you can take no matter what app you're in, but there is some at are only found in that app. Our solution to this was to have are left nav be the dynamic where depending on the app the actions displayed would change. Then on the other hand the top sticky nav to be are “globle nav bar”. This nav bar would be the same no matter what Juniper product the user is in.
This was an extremely enjoyable project as I was given full creative freedom of the design and aesthetic.
Collaboration and Communication
At Juniper, the whole design, dev, and product teams worked together remotely. What I’ve found when working remotely it's all about trust. You have to trust that your team members are doing their best in supporting you and they have to trust that you are staying focused and moving projects forward. If there is no trust in your team it falls apart. Also as you know communication is essential, so I had to make a continuous effect to interact with team members everyday. You can easily fall into the trap of hiding away and working on your own work alone, which is no good for anyone.
I would also work closely with the project managers when developing new processes. I found that the more information you can squeeze out of the project managers the better the outcome. As they have the spec knowledge and experience of the product we are trying to develop and then from that we can add our design magic.
We used tools like fig jam, loom, and (of course teams) to stay connected.
Passion and Creativity
When working at Juniper I always tried to be as creative as possible and to think outside the box.
Straying off-path could be challenging at times because of the complexity and regulation within the systems we were developing. However, this challenge prompted us to think more deeply about designing systems that always exuded flair—no dull designs allowed here!
Here are some designs that naver made it to dev but I feel still deserve to be shown.
