T-REX is a hybrid solution, combining field hardware with an online service. The hardware integrates with older pump jacks, extracting data and enabling users to manage their wells remotely via the internet. The T-REX website aims to display well conditions, provide notifications for well alerts, and offer in-depth data analysis for troubleshooting or determining necessary actions.
Before diving into the design process, I sought insights about our customers. Conversations with the CEO and engineers provided clarity on three distinct personas that would guide my design decisions. Although these personas varied in their job roles, they shared some similarities: predominantly blue-collar workers, spanning various age groups, and generally less tech-savvy, sometimes even resistant to new technology.
Once personas were identified and I had gained a better understanding of the industry, I began constructing T-REX’s design system using Brad Frost's Atomic Design methodology, starting at the atomic level. While I incorporated elements adopted from Bootstrap, I added some customized elements to differentiate our software. I adhered to a few key principles, including ensuring that elements were built on a 1rem (16px) foundation and maintaining color consistency for clear communication
After establishing the atomic levels, I progressed to crafting the components (molecules), navigating between the Bootstrap framework and finding ways to deviate from a typical Bootstrap application. Recognizing our personas, I instituted a hard rule: all clickable and interactive elements should be blue. Observing individuals who are less accustomed to modern applications revealed their confusion over what they considered interactive. By creating a consistent "blue" pattern—although unconventional in more popular design methodologies—it was an effort to provide an inclusive solution for this group of users.
When conducting customer interviews, I would present low-fidelity prototypes and pose open-ended questions to gather feedback on proposed features. One discovery from our target audience was that high-fidelity prototypes often left them confused, making them wonder if they were viewing the actual site. They also became overly focused on any incorrect data. As a result, I realized that filler text and numbers needed to be replaced with more realistic-looking data in low-fidelity designs to lessen confusion about what they were looking at.
My note-taking process began with obtaining customer consent to record the sessions. After each recording, I would extract the audio and use a process in Google Colab that employed AI to generate text transcripts from the audio. Once transcribed, I would highlight notable quotes or observations and organize them in a Confluence table for team members to review.
With defined requirements in place, I proceeded to craft high-fidelity workflows, showing expected behaviors, validation checks, messaging, and detailing happy-path scenarios versus navigating potential pain points. Upon completion, I would schedule a meeting with stakeholders to ensure all business needs were addressed.
With experience, I learned that sharing such intricate workflows with stakeholders could become excessive and time-consuming. I pivoted to documenting the requirements in JIRA tickets for stakeholders. We then collaboratively reviewed these tickets to ensure all requirements and business needs were accurately met. Despite this pivot, I continued to design workflows for development and QA purposes.
After finalizing the walkthroughs, I created a handoff document for the developers. This guide, crafted before the update to Figma's development mode, was dubbed the 'Lego Manual.' It meticulously detailed all the components, providing specifics such as spacing, icons, font styles, colors, and behaviors.
Upon its completion, I collaborated with the development team to address any design questions or concerns and to negotiate potential adjustments to components or modifications to behaviors as needed.