Why was it being made?
As there will be increased demand for automated testing throughout the company products, internal stakeholderds and management decided to upgrade and enhance the UI. I volunteered for the task to learn and further develop my UI skills. RAF as a software provides meets the current demand but as a result of the complicated nature of the design, it is hard for employees to navigate and use easily.

How did you go about solving the problem?
I initially noticed that there would be a lot of scope to improve upon the current UI of RAF and discussed with my team lead about making room in the sprints. We decided that I would begin by making mock ups, and aim to achieve a working prototype as part of our company innovation week. We established a team, developed the designs and reviewed the requirements with internal stakeholders. As this was an upgrade project, the attention was less on gathering functional requirements, but focusing primarily on considering alternative designs and using the cases we created.

Current Version:
Pain Points/Solution
Due to the RAF already having a working version, the foundations of its 
functionality was already there for us to consider when thinking about the re-
design. We discussed in meetings the pain points that users face on a day to day 
basis with the product and considered this when planning the re-design
UI Layout

The UI is current comprised of 10 various sized screens. A number of these screens are only needed upon setup or for specific use cases. Due to this there is a lot of screens that are constantly on the screen that is not needed and is distracting to users workflows.
Create a UI that is simplified to a smaller amount of constant screens. Toggle on and off screens that are needed as an when to set up a specific environment or special use case. This pain point is one of the main motivations for re-design as it is the users highest criticism.

Dated UI

Dated UI. The current UI is a harsh product to look at for 8 hours a day, in which some employees have to endure this due to the nature of a QA’s role. This software is vital for them in a day to day basis.
Create a new UI that looks fresh and aesthetically pleasing on the eye, there has to be consideration of colour choices, button design, typeface choice etc.

I created low fidelity wireframes to map out ideas on how the layout should look followed by creating more high fidelity wireframes to create a closer look to what we could consider a finalised UI layout.
This was a key process for us to really understand what we wanted from the designs especially due to the timescale of the project. We found that quick sketches helped us achieve our overall goal in reducing the complexity of RAF’s design.
During the development of low fidelity wireframes. I played around with the idea of buttons for toggle but then came to the conclusion that tabs would offer a much cleaner and more efficient function in the design. Tabs work extremely well in condensing screens and offered us even more functionality, which will be described further below.
As you can see below, this is the more finalised design with the condensed screens, button design and tab layouts. The tabs allowed us to implement the functionality of creating multiple workflows. This is something that would enhance a users capabilities swell as provide a much cleaner way of working. The tabs also allowed us to separate the necessary screens from the unnecessary ones. Tabs are such a common feature in software/web design now that I think the design helps the user quite quickly figure out how to navigate and use the product.
The one below is the wireframe we decided to go with due to the larger workspace provided for script work in the middle.
Colour and Typography
The colour scheme design choices really came from taken similar schemes from the current UI and freshening them up a bit along with make the colours more cohesive and obvious in terms of what the colours mean for the functionality of the product. So when you are on a tab and are not, button colour and toggle button’s.
The typeface was strictly decided upon its readability and scalability. Source Sans Pro was the cleanest for the product and was after looking at it for hours a day realised this was perfect for what use we needed it for.

We used the google icon UI kit for the icons of the product due to their quite readability and accessibility. We wanted icons that were close enough to what was currently being used but fresh enough that it enhanced the UI
Final Designs
These are the final designs below
Dark Mode
Dark mode was something that we really wanted to push. This is off the back of one of our pain points from the QA’s of having to look at a white screen for 8 hours a day. The white eventually strains the testers eyes and we wanted to offer a solution to that. By have the option for dark mode, testers can have the ability to toggle between these two themes. This was a key selling point when presenting to stakeholders