A few examples of my product designs for ALTR while working part time.
After my Internship at ALTR, I was taken on for part-time work in the Fall of 2022 while I was taking classes for my masters degree. During my internship, I had a summer-long project that was my priority, however now working part-time, I would be integrated among the UX and Product team and undertake current Jira tickets and implementing solutions as-needed for the organization. This was exciting for me as I now felt I was contributing to solving current pressing issues in the product instead of working on my own separate project on the side. I worked part time from September through December of 2022 and assisted in UX process in ALTR's scrum/agile environment.
The majority of my UX work here involved interface design for ALTR's technical product. My work involved making navigating through the product easier for customer, cleaning up unnecessary UI, organizing and maintaining a comprehensive and clean Figma design library and prototyping pages for future iterations of the product. The UX design at ALTR involved cross functionality with the dev team through the iteration and refinement stages of the UX process. This entailed pitching my designs and having a strong rationale for why my designs were useful and intuitive for user's on the front-end, while dev would give me feedback on feasibility of implementations on the back-end. This back and forth process taught me a lot about the refinement process, and the importance of understanding the product not only on the interface-design front, but also how the pages or functionalities I was designing for worked on the backend. By understanding the technicalities of the functionality of the product, I was able to create better interfaces and interactions on these pages for users, as well as assist in identifying places in the product that could be confusing. Learning more about data governance, Snowflake, SQL, administrator roles, columns access and row access policies and various notifications and alerts for anomalies gave me a stronger grasp on my design methodologies for a SAAS product such as ALTR, as well as a greater understanding of the entire data ecosystem.
Below are a few examples of some of my smaller Jira Tickets I handled while at ALTR, so you can get a better understanding of my work here.
In the ALTR Product, there were multiple places on various pages and tables in the interface where ALTR refers to a user's columns in their connected data source as "data" instead of "column". I identified this as an issue in the product for multiple reasons:
The acceptance criteria for this particular Jira ticket entailed replacing all of the instances in the product where the term "data" was being used when a user's "columns" were actually being referred to. There were also other instances of misleading verbiage in the product that might offer confusion to users. Such as the word "governed" being used to represent when a user was "connecting" their columns as well as when a user "protecting" their columns representing the "tokenization" function inside ALTR. These text changes were broken up into 3 smaller tickets which involved the main changes of:
These changes would offer more clarity for the users in what particular actions they were making inside ALTR as well as provide more useful information on various pages and tables to assist them in navigating the product more smoothly. However, making text changes inside a product is not a small feat, after communicating with dev, it became evident I we needed to mock up every interface a user might come across these words and change them accordingly. That means finding every possible instance in the product that had these terms, and to do so, I had to map out every possible user path on the various pages and make the correct changes. This was tedious and time consuming and highlighted the importance of having a well fleshed out design system and up-to-date pages in the Figma. I spent a great deal of time walking-through every user path to ensure I had mocked-up every interface that would involve these changes, which ended up in a very large web of Figma files but resulted in making these changes easier for dev to find and implement.
While walking through every interface in the product attempting to find where the changes for the previous examples tickets needed to touch, I found a place where there could be some simplification for the user, specifically in the radio box functionality on the Data Management page when a user wanted to connect a new column into ALTR from their data source. When a user opens this fly out, they are automatically deciding to connect this column into ALTR, however those with access to the tokenization function in ALTR, have the ability to tokenize this column upon connection. Refer to the Image below to help see the interface before my changes:
(Also here you can see the changes from my last example implemented! You can see connect, column and tokenize all being represented here instead of the previous data, governed and protected verbiage)
These two radio selection buttons could be simplified, as the 'connect only' selection is redundant given the user has to connect the column whether they want to tokenize it or not. My solution was to make this interaction more user friendly and reduce redundancy by changing the selection button to just indicating if the user would like to tokenize their column or not. If the check box was left unselected, the user would just connect the column after the final "add column" button was pressed; if the tokenize check box was selected, then the column would be connected with tokenization upon completion of the form. See below:
However, this change was not as simple as I initially thought. ALTR has different pricing tiers that offer different levels of functionality into the product. The higher tiers have access to tokenization while the lower tiers don't, so not every individual should have the ability to tokenize a column. Due to this, the "add new column" fly-out forms and "edit column" fly-out forms should represent what options the users have access to. This tokenize checkbox should only be present for those with access to tokenization, and because of this discrepancy, I had to mock-up every possible user path — including but not limited to; the connecting, editing and disconnecting options for every tier — to ensure the correct fly-outs corresponded to the correct pricing tier for the user. This involved another web of Figma files to ensure all user paths were accounted for.
Both of these tickets taught me a few lessons.
Working at ALTR as a whole taught me more about my personal design priorities. It taught me how to work in a fast pace agile environment and how to work collaboratively with a wide range of individuals. I learned the importance of communication, teamwork and feedback through the UX process as well as how to create functional and intuitive interfaces for a technical product. I would love to be a part of another work environment where I can showcase how my logic and rationale support my UX designs in a user-centered fashion.