First Step: Collect every piece of information
VoltaGrid is a newly-formed startup that was looking to innovate the mobile energy industry by transforming the world through clean, affordable, intelligent energy technologies. Their main goal was to give energy equipment suppliers an infrastructure to provide mobile power to third-party customers in remote environments where sources were scarce. They approached Onica, a Rackspace company to help build an internal enterprise-based CND (Cloud Native Development) app for field technicians and customers to track the effiency and data of their fleets. When I came onto the project I asked for any previous assets they had already developed. They delivered an excel spreadsheet complete with 62 user stories that they wanted to accomplish along with a single logo.
Step 2: Map out the information architecture
After going through all of the provided user journeys I was able to define the different types of user roles with various permissions and map out the information architecture by building an Architectural Blueprint and Functionality Blueprint in LucidChart. The reason I needed to do this was to see how the flow of information was structured and to be able to give guidance to the Engineering lead on building out the API and Database.
I also needed to see how the information was expected to be grouped together and delivered in a cohesive method for all three types of Users who were expected to access the online portal.
The Functionality Blueprint was an effective visual method for me to map out actions associated with that information structure, and examine what methods can be localized (to the exact feature) or globalized (an action meant across all features).
Once we were able to figure out how the architecture flowed and the basic permissions across all the roles, the Engineer was clearly able to define which User had specific types of administrative access and how they were related to each other. It wasn't so much of a stacked role structure as it was about who had access to which features based on the type of user that they were. Operating Customers were considered Primary, Servicing Customers were considered Secondary and the term "User" was (more or less) a representative of the Organization they were a part of. The only context that the individual User had was managing their own preferences such as opting into specific newsletters or changing their contact preferences. Everything else was managed in whole as the Organization so that they could focus on their collective metrics and energy tracking.
Branding Identity via a Style Guide
Since their initial deliverable was limited to a logo and user activity I knew it was time to set some standards in place so I developed a Style Guide based off of some stakeholder discussions and the color profile in the logo they delivered. I have a pocket color wheel at home I like to refer to in order to define complimentary color and shading so when I set the green in the logo on the wheel I knew my Primary and Secondary profiles to use. Typically, a Primary color is the action (Submit, Approve, Send, Confirm) and the Secondary is the escaping action (Undo, Cancel, Edit).
I also wanted to include a Tertiary color set for designing the data being fed into the tracking aspect of the app and assign a specific color to each type of data point. That way if the data point appeared in various areas across the app it would retain a level of similarity and cohesiveness. If a user was particularly interested in solely tracking that specific data point then they could immediately find it anywhere it was exposed.
After setting the Primary, Secondary and Tertiary set I also set the Disabled color set which was a grouping of gray colors scaled from dark to light. Then I set the text colors for Success and Error alerts.
Engineering chose to work with the Materials.UI framework which delivered a lot of the smaller specifics like button corner radius and Header text sizes so the Style Guide didn't need to be too granular. Instead I focused on defining the Typography, button colors, alert styling, form elements, mobile app icons, and fly-out options.
My main motivation for developing this was to keep the Engineering group on track for their development sprints and have something standard across all of the products they intended to deliver which (for now) were the web-based responsive app and the mobile app. It was imperative to get early stakeholder sign-off on the branding standards to minimize scope creep later on in the development cycle.
Finding The Gap
I use this phrase a lot and what it means is - to compare and analyze a product in search of what makes it special, i.e. what GAP does it fill? What makes it unique and what gap can it fill in regards to the niche it fits into. What do the stakeholders feel make their product stand out in the industry and how can it be exploited? How can we sell this specific perk and come across as unique and superior?
I spoke to the stakeholders almost daily and scheduled regular meetings to talk about their objectives for where they saw VoltaGrid in the next few years. I had to get a feel for what they actually wanted to deliver to their customers, who they thought they were catering to, and what type of information they thought was important for everyone to see.
I also needed to know how the reported information related to itself and what a comparison of different data points conveyed. Basically, what are we reporting and why is it important...?
I also wanted to get a feel for what their visual inspirations were and start the list of major competitors that they felt gave them a run for their consumer base. By doing a Feature Analysis of their competitors and a Branding Analysis I would be able to see what gaps existed in the industry and the main visual/functional themes. My engineering background taught me to look for a pattern and that's exactly what I was doing. This would be the heart of what we delivered.
The gap was Metrics. The branding was renewable and zero-net-emissions. I got visually inspired by Kubernetes after seeing the Stakeholder's feedback. I realized that they wanted data visualizations over specific time periods based on how they wanted to structure their billing cycles. No problem I can do that!
Wireframes, Responsive Design, Mobile Device Research
There were multiple parts to the VoltaGrid project. While I was mostly responsible for their web-based app they became inspired by the Style Guide and Branding concepts I delivered and delivered those assets to the agency they hired to design and develop their front-facing website. I was incredibly excited to have my branding concepts on their front-facing website because it would mean cohesiveness across the users' entire experience! The last thing we all wanted was to alienate the user after they accessed the web-based app from the front-facing website and seeing a completely different identity.
Now that we had something tangible down it was time to produce some black-and-white digital concepts for the web-based app. We didn't have the green light on creating the mobile app yet because funding was still coming through to get this off the ground. I was inspired by what Kubernetes could do with data visualization customization and really pushed to design the web-based app with a mobile-first attitude. My initial deliverables included 3 responsive sizes to keep within the most generalized sense. I also compiled a list of devices (with their current OS) that the stakegolders used, and compared it to a list of the most widely-used devices according to sales in the regions VoltaGrid wanted to operate (US).I came up with 6 different devices with Android topping the list so if we had to delve into the mobile app designs I would be very ready.
Design with Modules in mind for a responsive framework
The nice thing about using the Materials.UI framework is that it scales pretty well for responsive design and the Engineering team expressed that they didnt necessarily need the visuals for their work, but the stakeholder needed to see how everything flowed at different breakpoints and I knew that some concepts wouldn't work just stacked on top of each other. Another blocker was that some user roles only permitted access to certain sections, where other types of roles had administrative access where they could see everything. I purposely created a module-based design so that each component was self-contained and could be hidden or shown based on role; and could be exposed in different sections of the web-based app with ease. That would shorten the development time while also giving users a global experience.
My goal was to create more digital assets representing the responsive breakpoints which advised the engineers on how to stack the modules in different views, what the overall layout would look like with different permissions exposing limited components, and stamping on the branding. I was also doing double-duty by creating these layouts in the hope that we would get the funding to create the mobile app, whereas I could re-use some components and save myself time in that design phase.
When the stakeholder saw their branding stamped onto the digital designs they were able to shore up an additional $750k to create the mobile app and extend the project timeline. YAY!
App Designs, Restructuring the flow
Now that we had the go-ahead for developing the mobile app I realized I would have to break apart how the information was structured because of how the user behaves while moving between screens. I also realized that I would need explore different additional features which related to how the mobile app communicated with the OS it was running on. I needed a way for a user to customize notifications, display version logs with new feature rollouts, show how the app interacted with QR codes through the camera and design a new method of capturing the users signature for approving billing.
I broke apart the architecture and got more granular with it while keeping the same grouping and expectations. I depended more on simplifying information through showing lists of items and globalizing common actions. I also relied on a global header which had actions that varied depending on the needs of the feature the user was accessing.
Even though everything was already stacked from creating the web-based designs I had to deal with the fact that users just can't scroll vertically forever on a mobile device unless they're wandering through a feed. To solve that problem I compiled all of the data visualizations into a carousel format so that the user could just flip through them. In order to account for all edge-cases I included screens for the lack of data and included an action for the user to take in order to get their data flowing.
Self-check time with Heuristic Evaluations and User Journeys
We came to a point in the timeline where I was way ahead of the Engineering team's efforts to build the web-based and mobile app so I turned my attention toward evaluating my own designs with Heuristic Evaluations. My process was to define all of the User Journey's that an individual can take and evaluate the effectiveness of getting that user to their goal by employing the 12 core values. Heuristic evaluation is a process where experts use rules of thumb to measure the usability of user interfaces in independent walkthroughs and report issues. My goal was to produce a User Journey map for each walkthrough, look for possible blockers, and suggest visual (or functional) fixes. The goal was to get this all done before the Engineers actually started developing the features so that it would all get done in the first iteration.
This method of checking my own work gave me an opportunity to look at the flows I created outside of my design shoes and make improvements or add clarifications where needed. For example when I created the User Journey for the Heatmap Report (see visual) it exposed the fact that the user gets a report of the data but doesn't exactly know how to digest or interpret it. My solution was to create a downloadable summary which compiles the data and offers strategic next steps either offered as additional services or self-care options. The stakeholder were pleased with this upgrade because it gave them an opportunity to customize their data reporting and sell additional purchases on top of their regular services. Think of these additions as bubble gum in the check-out line at a grocery store - nice to have but you don't necessarily need it.
Wrapping up and creating v.2 for future funding
The timeline was coming to an end for the initial web and mobile app so I wanted to prep the Engineering team for when they moved into support mode and leave the door open for a potential 3rd round of funding. My goal was to take the results learned from all the heuristic evaluations and implement updates to the visuals so that if funding came through they could start developing the updates immediately. I also wasn't sure if I would be the one returning to the project or if the entire thing would be handed off to another designer so I needed to prep all the assets for either outcome. I also wanted to make sure all opf the requests made by the stakeholders were covered in the designs (and signed-off) so that nothing would get lost in the transition.
Version 2 of the designs included updates to how the information was structured and what to emphasize. One particular comment that remains burned into my brain was that exposing data for the individual trailers was too granular and that the Stakeholders needed to see data on a more global, fleet-based scale. I updated the main dashboard where all the data was aggregated to showcase the groups of Fleets by County instead of just individual Fleets. I also removed the individual Trailers from the left-hand main menu and restructured it so that it showcased by County and Fleet (instead of Fleet and Trailer). This afforded a cleaner look and a globalized attitude of managing assets for the bigger picture.