• May - Aug 2019
• UI Developer Intern
• React
• JavaScript
• SCSS
• 1 UI developer intern (me)
• 1 front-end intern
• 3 back-end interns
• Summer Internship
During the summer of 2019, I worked as a UI Developer intern at Vail Systems, Inc., a telephony company based in Chicago.
For 13 weeks, my role was a mix of UI/UX design and front-end development. I designed the user
interface in Figma, built the foundation with Vail's custom SCSS framework, and brought the interface to life in React.
The project I worked on is called Valert - it is a notification system with an interface for Technical Account Managers (TAMs) that triggers email
and SMS alerts when data-specific thresholds in call centers are passed. For example, if a TAM wanted to be notified when
a certain company's call traffic rose to 500 calls per second, they could easily create a “rule” that tells the system to send
these notifications when that occurs.
Before Valert, Vail would create rules using a CDR listener application called Trunkmon. Since Trunkmon required more technical experience,
TAMs would have to speak with a manager, who would then create a ticket for operations, which would then need to be approved and reviewed.
This process would take a few days, and was not the most user-friendly towards TAMs. Furthermore, if a TAM wanted to change or delete a rule
at a later point, they would have to go through this whole process again.
There was an apparent need for a more efficient solution that would allow TAMs to easily create rules with little technical experience.
The previous process for creating a rule, where multiple parties would be involved
The process using Valert, which would cut out the middlemen
At the start of the internship, I received a list of required features and pages from my manager. TAMs would be able to open up the application and see a table of every rule a TAM has made. Once a new rule was created, it would be added to the table - thus, a form (or "Rule Builder") was needed so that TAMs could create new rules and add them to the table. With this information, I created a preliminary user-flow.
I then started working on what the basic layout of the product would look like.
I knew the main page had to be a table of rules that were already in the system, but I needed to sketch options
on how the "Rule Builder" would interact with the main table.
After sketching out some options, I created low-fidelity mockups in Figma for each one. I met with the Technical Account Manager assigned to our project
and had him try out each prototype.
After some observation, it was apparent that the last option with the dropdown was the most efficient - users would be able to click
on a row in the table, and that row would expand down to display more detailed information on that particular entry. With this design, users could "open"
multiple rows and view them all at once.
Sketches of Rule Builder general layout
A more detailed brainstorm for each input field
Once I had some sketches, I mocked up the Rule Builder in Figma. I focused more on the placement and organization of each input field
rather than aesthetics.
Once I decided on the initial layout and created a preliminary Rule Builder, I started to put the pieces together. This included mocking up the rules table with placeholder data. I also mocked up the Alert Logs, which was a table that displayed every SMS or email alerts that had been fired for that particular rule.
After completing the "medium fidelity" wireframes, it was time to add aesthetics. Since Valert is an internal project, I had a lot of freedom when it came to colors and fonts - the only users were Vail employees, thus I didn't need to adhere to any specific style or brand guide.
In addition to the rules table, Rule Builder, and Alert Logs, these wireframes also include success notifications (that appear when an action has successfully been performed on a rule) and notification messages for deleting and saving rules.
My manager prompted me to design a "safe" option - I chose blue as the primary color, and a simple font.
This design falls under "contemporary" - I chose a more vibrant color, rounded out the edges, and chose a font that was more playful yet still readable.
The last design was intended to be "adventurous" - I picked a bright gradient, and messed around with the placement of various elements.
I took elements from my three different aesthetic options and compiled them into one design. The primary color of this design was a bright blue - safe and readable enough, but still vibrant and fun. I also changed the background of the UI as well as the background color for the table and Rule Builder in order to distinguish these different sections.
Although I do not have access to the current or previous versions of Valert, the following images are screenshots taken of the final product.
The table of every rule a TAM has created
When a row is clicked, it expands down into the Rule Builder where the rule can be easily edited or viewed in detail
If a user attempts to navigate away from the rule with no saved changes, they will be prompted with this message
A confirmation for deleting a rule
A log of all the SMS and email alerts that have been fired for that particular rule
My main takeaway from this internship was that development process and the design process evolve very much hand-in-hand. Though my primary role was designing the UI, I also contributed largely to the actual development of the interface in React. I found how important it was for developers and designers to communicate with each other, and have input in each other's work. Many developers will often avoid participating in design decisions, and vice versa - however these two components of a product are deeply intertwined and having open conversations as a team is essential.