At Weevio, we have just two developers on the team. I am one of two. Due to our size, when it's time to develop a new feature each developer must design and develop all aspects of the feature, including UI design.

I typically have the most fun when the feature does not rely on existing views and API endpoints. This was the case for the "Device Check-In Workflow" project I implemented.

Before we can dive into the details, let's start with the problem.

A client approached us (Weevio) with an opportunity to develop an automated, Device Repair Check-In system. Their workflow required a lot of manual work and really needed to be automated. Their system began as a static repair form on their website. When a form was submitted, it would be sent to their ticketing system. An employee then had to manually review the request and if valid, create a "Service Repair Order" (SRO) in the company POS system. This client is located in a high-population city, so as you can imagine it was not a very scalable solution.

After a few meetings, we landed on an MVP. Features included in this initial release included the following:

• Customer-facing repair form similar to their static web form with ability to customize with branding. Each form must support multiple devices.
• Employee-facing repair submissions table.
  • Here an employee could easily view and search all submissions with the ability to modify, cancel or approve requests. If the submission is to be approved, the workflow allows the employee to easily associate a customer to the Service Repair Order. If the customer does not exist in the POS the workflow easily allows the employee to create the customer record. Finally, after a customer record is selected, the Service Repair Order is automatically created.

After the MVP was shipped, I added the following features:

• Customizable repair request form.
• Autofill devices using a CSV file.

Sounds easy right?

Next, let's go over the system sequence.

This project consists of two workflows, the user workflow and the employee workflow. The user's workflow is ran in the customer portal. The portal is a website where Weevio business clients can send their customers. In the portal their customers can view their orders, approve quotes, make payments and deposits and manage access portal access.

Version 1 of the repair request form was pretty straightforward. In an earlier release, we built out client theme settings. These settings allow our clients to customize their primary color and upload their company logo. For the form, we simply retrieved these settings via an API.

For the next release the requirements got a little complicated. The customizable repair form was a good challenge. It really pushed me in terms of UI design. The UI had to be easy to understand and be dynamic. The form also needed to be easily enabled and disabled for users. Furthermore, it was necessary for some of the steps to have the capability to be toggled on or off, and the content within several steps required the flexibility to be customized through a text editor. Below is an image of the latest production version of the settings, operating within a staging environment. In fact, all screenshots in this article are running in a staging environment.

As you can see from the settings, Receiving and Delivery options are fully customizable. Users can create dropdowns that will be displayed in the form by entering options into the textbox. Each option is determined by a new line character. Text fields can also be added to the form by clicking the "+ Text Field" button and entering the prompt or question.

The CSV uploader has also been implemented however, for large CSV imports the process is a blocking operation. This will be fixed in the next version. The current plan is to develop an API that handles the CSV parsing and returns JSON to the client.

Pictured below is the customer-facing repair request form.

After the repair request form is submitted, it is listed in the Pending SROs table in Weevio Store. Weevio Store is an employee-facing dashboard capable of creating and managing orders, customers, repairs and as well as the ability to manage a line of customers using Queue. The purpose of the Pending SRO table is to prevent malicious actors from submitting bad device repair requests. This also prevents these malicious actors from filling the POS database with bad SROs. The Pending SROs table is pictured below with a pending SRO expanded.

When a Pending SRO is expanded all of the details submitted in the request can be reviewed and updated. The nested table is used to list the submitted devices. When the employee selects at least one device they can start the workflow to automatically create a Service Repair Order (SRO) by clicking on the "Verify Customer" button. Let's take a look at that workflow below using the whimsical diagram I created in preparation for the project.

When the user clicks the "Verify Customer" button a lot happens an API request is made. The API fetches all related customer records from the POS system based on the email submitted in the form. If the customer was signed into the customer portal when the form was submitted, a customer record number is associated to the repair request. This allows the first step to automatically select this customer record. Although all other customer records matching the email are also listed with the ability to create a new customer record.

In conclusion, the "Device Check-In Workflow" project undertaken by me has significantly streamlined our clients' device repair process, transforming a labor-intensive, manual system into a seamless, automated workflow. By leveraging my development expertise in UI design and system integration, I've delivered an MVP and subsequent features that not only meet but exceed client expectations. The customizability of the repair request form, along with the efficient handling of service repair orders through the Weevio Store dashboard, underscores my commitment to innovative solutions that address real-world challenges. At Weevio, our journey from conceptualization to implementation showcases our ability to adapt and evolve in the face of complex requirements, ultimately proving that even a team of two can have a profound impact on improving business operations and customer satisfaction. As we continue to refine and expand our offerings, the success of this project serves as a testament to the power of focused teamwork and creative problem-solving in the dynamic field of software development.