HuLoop Test & Process Automation
AgreeYa Solutions - UI/UX Designer
Summary:
One of the products AgreeYa used to offer was a Test/Process Automation Software called BeatBlip. The product had a lot of powerful features but there were many usability issues that prevented users from utilizing all of its features.
The product is split into two parts:
The Orchestration layer (Web-based)
Where users can create projects (groups of processes), processes (groups of tasks), and tasks for the automation to carry out.
The Agent (Desktop Application).
Where users are able to run projects, assess the findings and/or debug any issues that the program may run into.
Introduction
During the introductory call for this project, it was apparent to me that we needed to be meticulous with the way we handled this project, as there were a lot of moving parts. Both the Orchestration & Agent layers were extremely technical and complicated to a point where I knew it would take me some time to be able to understand the intricacies of the software. The CEO also implied that there was a time crunch, as he wanted to start marketing the software at tradeshows. This meant that we would have to create two separate versions of the software. One that would have a majority of the big features, and another that would handle the intricacies of the software. Due to these complications, I made sure to start early on understanding the previous design.
Assessment of Previous Designs
At first, I had trouble accessing the existing system as the admin user was taking some time to approve access for my team. This meant that the only resource I had to start thinking about the redesign was a short introductory video that we had received on the existing system. I decided to take this video and break it into screenshots, detailing improvements we could make on each page. I also made sure to note down any general difficulties in the layout and design of the existing system. Based off of this initial assessment, I was able to come up with a general idea of what we should ask the stakeholders/previous developers in order to get a better understanding of what is needed in the redesign.
Requirements Gathering
As the learning curve for understanding the project was steep, it was clear that we would need to ask pointed questions in order to ensure that me and my whole team had a great understanding of the system before starting any designs. One of the reasons for the steep learning curve was the fact that the application was built for the wrong userbase. Instead of targeting the general public, the software was set up in a way that would be familiar to those in Computer Science or related fields. In fact, the desktop application was almost identical to an IDE, which I think we can all admit aren’t the most easy to use upon one glance.
I also made sure to make the expectations clear from every stakeholder to prevent any miscommunication. Since I had to balance both the Design and Business sides for this particular project, I wanted to make sure that I had everything in order. I took note of every stakeholder’s expectations, including the CEO, who was also attending most of the meetings.
Initial “Concept” Designs
I started creating the base layer designs that the entire application would revolve around. It involved taking task steps that were arranged in a table and laying them out in a more aesthetic way. It was immediately clear to me that a card-based interface would be best in this scenario, as each task was independent but also had its own place in a sequential order. Each task has a few fields: Type, Action, Screen, Element, and Parameters.
The other piece that was important to establish in this phase was to ensure that we had the project structure for the Orchestration (web) layer. Based off of the structure of the website, it seemed that there were three main layers needed: A Project Organization layer (called Project Streams below), A Project layer, and a Task layer.
Below are a few of the screens that were completed for this phase of the project, to show a basic idea of what we wanted to accomplish in the redesign.
Layout & Feature Review
After this initial phase, we made sure to speak with the stakeholders again in order to make sure we were all on the same page before moving ahead with designing the rest of the pages. We held a short meeting with the CEO as well as some of the developers, and based off the meeting they were interesting in proceeding in the direction that we were heading into.
Now it was time to ensure that we had all the resources we needed in order to proceed with the redesign. We had access to the website, knew the direction we needed to head in, but still needed to know additional information such as: the names & groupings of actions, as well as minimal brand guidelines, as the current colors and logos were pulled from the website.
One of the main findings from this stage of the design process was the fact that we were missing a step. There was a page in between the Project layer and the Test Steps layer where users would be able to arrange tasks into larger groups to run in a series. This would help break down the complexity of some projects, allowing users to do more with less clicks.
Mid-Fidelity Designs
From this point it was clear that we had the go-ahead to move onto mid-fidelity designs. Some keys points we had to take into mind were: maintain ease of use, create a larger flow, and ensure that designs do not conflict with web design coding standards.
This process took a few weeks, as we wanted to have a process that was as iterative as possible. We continuously went back and forth with the stakeholders, ensuring that they were happy & informed about what we were designing.
After this 5-6 week iterative process, we were finally able to produce designs that we were happy with (from a UX standpoint). Now it was time to send these UX designs over to the UI team in order to fully incorporate branding and consistency.
UI Review & Prototyping
The UI team worked with us in a 2 week timespan to apply branding, colors, as well as minor UI fixes. Throughout this process we made sure to have regular update meetings in order to ensure that they were working on the right tasks and headed in the right direction. That being said, the UI team was excellent and didn't need too much guidance.
After the UI team completed their work, the ball was back in my court. It was time to prototype the designs so that they would be more presentable to both the developers and the stakeholders. The prototyping was a bit complex for this project, as there were a lot of moving interactions that are hard to recreate in Figma. Some issues I ran into were: creating an infinite canvas, splitting the project into different flows, and exposing all the features to developers. I was able to address these (and other) issues with some creative solutions, but in the end I was able to create a working prototype.
The prototype also allowed me to identify any potential issues that the developers may come across once that process begins. After making a list of potential issues, I made sure to speak with the stakeholders about potential solutions so we could address the problem head on.
Handoff To Developers
This step was fairly simple and straightforward. We shared the final designs/prototypes with the developers and where'd any questions that came up. They have now finished the product and the client is working on showcasing the product to potential customers.