I am currently a user experience architect at GreenLancer. GreenLancer is a startup that is focused on providing a platform that leverages standardization, automated workflow, and a large network of solar professionals. As Greenlancers sole UX employee, I am responsible for creating and maintaining all aspects of GreenLancer's user experience. My duties include developing the new UI, creating and maintaining the digital style guide, identifying what aspect of the UI needs to be worked on next, setting up participatory design sessions with stakeholders, identifying and monitoring KPI's, and developing interactive prototypes.
My design process at GreenLancer slightly differs from my design process at GE. When I start working on a new feature, I sketch out wireframes in order to come up with a basic idea of what I think the feature should look like. Along with the sketches,
I come up with a list of questions that I have regarding potential interactions. After this, I hold a half hour or hour long session participatory design session with our CTO. By holding a participatory design session so early
in the process, we're both able to see how the other person envisioned the development of the feature, and are then able to come together around a unified design. This solved a problem that we had early on where I would create
a design for a feature, and he had a different vision as to how that feature would be designed.
After this meeting, I go back and redo my sketches based around the outcome of the meeting. Then I begin to transfer my designs into Sketch where I turn them into higher fidelity mockups. After this, I hold another meeting with the CTO and any other interested stakeholders in order to get feedback. I make changes if necessary, and then I create a page in our internal Wiki for this feature. This is a great way to share with the rest of the company what I'm working on, and when writing out the description for the feature, I'm able to catch any interactions that I either missed, or implemented incorrectly. At this time, I will also make interactive prototypes if necessary.
Upon arriving at GreenLancer, I was tasked with redesigning the entire UI. This was a major undertaking, but I was excited to do it as I knew that I could drastically improve the existing UI. I conducted a heuristic analysis during my first few days at
the job, and the biggest issue with the existing UI was that it was very hard to tell where you were. While there was a breadcrumb, it was located at the bottom of the application, which is a very unintuitive place to put it. The
second issue was the fact that many of the pages that users had to navigate out were cumbersome and would display information that was wholly unnecessary to the task at hand. One example of this is how a page that consisted of
around 10 text fields stretched about 2-3 printed pages down due to the fact that the page insisted on showing multiple read only fields that consisted of installation information that was not pertinent to the form that the user
had to fill out.
The first feature I worked on after the heuristic analysis was the overall look of the project page. Users spend most of their time on our site working on individual projects, so increasing the usability of the project page was my number one priority. The first (and most major) change I made was to make the project page look more like a dashboard. The benefits of this are twofold. The first benefit is that by having a static list of high level options in the sidebar, the amount of time it takes for users to get to their desired page is drastically decreased. The second benefit is that it simplifies the schema that users have to learn, which will reduce their cognitive load. The old UI divided items such as attachments and discussion tabs up by services, even though the services were all in one project. This caused customers and internal users alike issues when it came to remembering what service a specific file or discussion was located in. The third benefit is that I was able to move or remove unnecessary and rarely used elements, such as the archive and edit buttons as well as a block of text that was dedicated to four project parameters that were not needed. In their place I was able to add in features that had been requested by users, such as a service status and an activity feed. I also added a map that would link to Google Maps and display a satellite image of the address where the project was taking place.
The second feature I worked on was changing how our users communicated with us. Our users primarily communicate with us through the discussion tab that is located within an individual service. The primary issue is that one project can have multiple services,
and if we have to fix a mistake, a change order service needs to be created. This leads to mistakes being made on our end, and unhappy customers inquiring as to why we didn't follow their instructions. My solution was to create
a Tickets tab that would allow internal and external users to quickly and efficiently send messages back and forth while minimizing the chance that our internal team will make mistakes.
The benefits of the Tickets tab go beyond reducing user mistakes. Since it serves as a repository for all customer communication, it's trivial to switch between messages. Instead of having to go into a service, scroll down to the discussion tab, then go back out to another service, users can quickly view and respond to messages. Another benefit of creating the Ticket tab was that I had the opportunity to work with our production team in order to identify potential features that they wanted to see in the new UI. One such feature was the ability to send messages that were only visible to those with admin rights, while another feature was to introduce a "resolve issue" button that would close out the thread and let all participants know that the issue had been taken care of.
While this has been a great learning experience so far, there are some changes I would make if I was given the chance to start over. The first change I would make is to develop the screens with a mobile first implementation in mind. While the dashboard aspect lends itself well to a mobile screen, there are still some constraints imposed by the smaller mobile screen that I wish had been resolved earlier. Some constraints include choosing what elements to hide and show and how to deal with wide tables. A second change I would make is to do more initial sketching. While the participatory design sessions that I hold always involve sketching, I've noticed that I then refine those designs in Sketch instead of refining them on other whiteboards and then putting them into Sketch.