Learn my process behind taking a product that existed only as an idea into a live customer environment along with an accompanying product landing page and a design system that included a component library, style library, and visualisation library.
The candidate results
Research and Discovery
When I first started at Magnetic Rock, our product (Potential) was an idea. It was the idea that we could deliver a range of assessments that candidates could complete, and the results would reveal their hidden potential, which cyber administrators throughout the US and UK could use to find a suitable role or profession within the cyber security domain.
Potential would have two distinct user personas: candidates and assessor administrators. For candidates, our product would offer various assessments that they could take, and each assessment would offer different benefits. For instance, our role-finder assessment could identify the most suitable role for an individual within cyber security based on their skills. Our potential finder assessment, on the other hand, would be able to identify aptitude and skill scores, which would inform the administrators of a candidate’s hidden talent and skills that may have been missed or gone unnoticed.
Understanding academy administrator requirements
In order to discover customer requirements, I had several conversations with the Product Owner, our Lead UX Researcher, and our Chief Creative Officer as he was also an investor in the company and product and therefore had market and industry knowledge. I was also part of the customer workshop sessions that we had with SANS and their academy administrators, who would be our primary users of the insights portal and candidate dashboard. In these sessions, I asked the appropriate questions in order to understand their goals and requirements, but more importantly, their "why" in order for me to begin to create user personas and user need statements.
Understanding candidate requirements
In order to learn more about candidates and their expectations and interactions with our assessments, we ran a series of paid user trials using a subset of questions from one of our cyber security assessments. These trials offered small cash incentives to the applicants, and this enabled us to analyse their journey through the product so we could monitor various stats that we could use to inform improvements moving forward.
I liaised with our Product Manager to discern her thoughts on key product features and to understand existing stories that existed within Jira. I began to learn the key features that we needed for our first release and started to understand long-term requirements from those that were most pressing. I discovered that no design system or component library existed, and this was made part of my design strategy to create one. As we also had no front-end developer within our team, I put forward a small set of requirements for the role specification to ensure that a candidate with experience in creating and collaborating on design systems was brought into the team. Due to my previous experience using Storybook and Chromatic, I asked if an individual with these skills and experience could be hired.
Once I had gathered a solid understanding of the product we were looking to build for our first release and the customer and business goals that it would set out to solve, I had to define a design strategy and some design values. Based on our user personas and the intentions behind the product, I created the following principles:
🧦 Intuitive and familiar
📎 Beautiful in simplicity
♿ Inclusive to all
❤️ Consistent and honest
☝️ Make thoughtful design a priority
Potentials' Design Principles
In addition to these principles, a prioritisation of features was also required. Prior to starting, our product manager had gathered a plethora of product features in Jira; however, these were largely undefined and not prioritised, so I ran several sessions to understand the needs behind each feature, which enabled me to focus on those required for version one and those that could be developed in the future. In addition to these features, I wanted to ensure that the user was at the centre of all design work and that the entire team would be aware of what user goal each feature would be solving. I, therefore, created a template within Jira that each new user story would use. Within this template, I added a User Need Statement that also included the user scenario. For each new story that I created, I ensured that this was complete and I would communicate this statement to the engineering team ahead of presenting low-fi mockup work in our sprint refinement sessions. This enabled the entire team to understand the context of use, but more importantly, it offered them the chance to offer design suggestions or alternative solutions that may be a better resolution to the goal.
An example of a completed User Needs Statement within each Jira Template
I also defined that a design system was required as part of our version 1 release. Due to the time pressures of the release and the potential backlog of work, if the design system was far down its development path before a front-end individual was brought into the team, I wanted to ensure we only built the components and states we used. For example, we would require a button component; however, early on in the design phase, there were no indications that a button would need to exist in multiple sizes or multiple states (destructive, secondary, tertiary, etc.), and so I only built those that were actually used. This was a more efficient process, and it reduced the number of components that would need to be developed once we had the individuals in the team to do so.
I also made the decision to adopt the Atomic Design System principles for our design system. This would also help with efficiency as atomic components such as buttons and input fields would be reused in molecules and larger components such as form patterns.
The first stage in my discovery process was to identify the aforementioned product goals and features and to begin mapping out user flows. These would all be low-fidelity mock-ups, as I would want to include our Lead UX researcher to ensure the flows would be suited to our user research findings.
The creation of these flows was an iterative process in which I included our Chief Creative Office to ensure they aligned with our business goals. At this stage in the process, the focus was on creating and understanding the user flow, so I opted for flow-based diagrams as opposed to low-fidelity screen mock-ups. This was intentional, as at this stage, I wanted to ensure the optimal high-level journey was correct so I could concentrate on the call to action and finer interaction styles further in the process.
I also had regular discussions with our Lead UX Researcher in order for him to analyse and compare these flows against his own customer research to ensure they would meet the customer's needs. I would take the leading role in iterating these flows, and once I had created both the customer’s happy and unhappy paths for all flows in our version 1 release, I moved on to creating our low-fidelity screen mockups in Whimsical.
At this stage, I also introduced a new way of working in regards to discussing the flows between myself and the team. I asked our Lead UX Researcher, Product Manager, and Front-End Developer to all create a Whimsical account in order for us to utilise the comments feature of Whimsical. Comments were used as a means of collaboration and communication on specific features, as we could target specific areas of a flow to discuss any concerns or unanswered questions. By integrating this into our team slack channel, we were also notified once new comments were left or once the discussion was closed.
Within Whimsical, I also introduced a visual key for annotations. This key would communicate the different annotation styles in order for the different requirements to be visually understood. The key I introduced was fairly simple and consisted of the following:
Yellow annotations were to indicate post-v1 features. This was useful as it allowed the engineers to be aware of what may be required in the future in order to consider scalability.
Pink annotations were specifically for the attention of engineers. These may describe functional intentions or promote specific discussions around interaction.
Blue annotations were general thoughts and comments on design and user flow.
Red annotations were used to indicate unanswered questions, which could be specific to design, UX, or engineering.
Different annotation colours are introduced for specific discussion and awareness
From low-fidelity to high-fidelity design
Once all Whimsical journeys were created and the same collaborative process between myself and our Lead UX Researcher had taken place, I commenced the high-fidelity design phase in Fimga. Alongside this, I also created designs for components that would need to form part of our design system.
As the Potential product is a responsive web application, designs were created for both mobile and larger devices and resolutions. Initially, I adopted the use of a specific set of pre-defined breakpoints that were largely based on the most common and popular screen resolutions. However, as our Front-End Developer and I researched more into CSS container queries, the more we felt these offered advantages over a more traditional approach. Using CSS container queries, we could ensure each component was adapted to suit its content and not determined by an existing breakpoint. This aligned more closely with my “content-out” way of working, which promotes content over the container, and the more the project moved forward, the more this became a project-wide rule.
High-fidelity design of Potential
High-fidelity design of Potential at smaller breakpoints
Design to development
One of my goals is to always work closely with the development team. I like to ensure that the Whimsical user flows, Figma high-fidelity designs, all supporting user journey information, user need statements, and acceptance criteria exist within the story, feature, or ticket, and these have been discussed with the team ahead of them starting the work. Usually, this is discussed in sprint refinement and sprint planning ahead of the sprint starting to allow any changes to be completed before the task is commenced.
As part of my design work, I always aim to build a design system or continue the development of an existing design system that supports and underpins the product. A design system offers a plethora of internal advantages, product advantages, and end-user advantages, so I always try to ensure that product designs use components from our design system. As part of the development of a design system created in Figma, I try to ensure that a working version of the design system also exists. For the Potential product, we created a developed version of the product using Storybook and Chromatic and integrated these with Slack to notify me when new builds were ready for review.