Bosch (contract)

Methods used: Heuristic analyses, user interviews, & sketching.

Work Overview

I am currently a user experience designer at Bosch who started in April 2016. I was brought on in order to identify personas, conduct heuristic analyses on legacy programs, make recommendations as to how existing product functionality could be combined into a next generation product, develop wireframes, and perform user testing to validate my hypotheses. Due to the nature of the contract, my work time is divided up into cycles. Because of this, I will have a paragraph or two dedicated to each cycle. As this contract position is currently ongoing, I will be updating this page as my work progresses.

Cycle 1

During my first cycle, I spent the bulk of my time learning about the legacy programs, identifying personas, and creating workflow maps that would represent all possible paths that different users could take in said legacy programs. First, I worked with a subject matter expert who was able to identify all of our users and give me some background on them. Next, he walked me through Bosch's existing products so I could become familiar with their functionality, as well as point out how one program could be used in different ways by different personas.

Afterwards, I began to work on building out the personas in connection with workflow map creation. For the workflow maps, I first created a folder for a persona, and then created a map in that folder that would correspond to an existing program. Two benefits of doing this is that I was able to trace out all possible activities that a user could take in the system, and the second benefit is that I'm able to identify overlapping functionality.

While I was reviewing the legacy systems, I also conducted heuristic analyses on them. While this wasn't a cycle 1 requirement, I figured that it would be helpful to do it anyways as it would lessen my work later on, and give me a good idea about the major usability issues that were present in the system. Some of the issues that I identified were lack of verification, inconsistency, multiple databases that contain duplicate information, and two different types of tables being used in a single application.

Cycle 2

During the second cycle, I focused on the usability of our next generation product, as well as performing additional work on personas. This personas work was focused around identifying additional personas that may not have been covered by previous products, but were targeted by our next generation product. I also conducted additional heuristic analyses of our next gen product from the viewpoints of customers, internal agents, and administrators.

The heuristic analyses revealed a number of issues across all three versions of the product. For example, many of the same errors that were committed in the legacy programs, such as lack of verification and different types of tables, were carried over into the new products. New usability issues were introduced as well, such as having different methods of alerting the user to errors. For example, in the customer facing version of the product, a modal was utilized in one section of the product to display errors, but then toasts were utilized in another section to alert users to their errors. Even worse, after alerting the users via toasts or modal, the offending fields weren't even highlighted after closing the toasts or modals.

New usability issues weren't just limited to the customer facing version of the application. In the agent facing version, the initial dashboard had multiple accordions that were all collapsed upon login. There was no indication as to what the most relevant accordions for agents were, and as they were all collapsed upon load, there was no way to immediately show any relevant information at all. A second major usability error was the use of four large and overly salient buttons to show or hide commonly used functions. There was no reason that these functions should've been hidden when they could've been integrated into other areas of the page, and no reason that the buttons should've been implemented in the first place.

In the admin panel, one of the most glaring usability issues was the newsletter functionality. The implementation of the newsletter functionality was that the user could type in plaintext messages, however, the user could also type in raw HTML, and have it compiled upon clicking the send button. The major issue with this is that there was no way to preview the message before sending it, so it relied on users typing in the code with zero errors. My recommendation for this was to implement a markdown editor that at the very least had preview functionality.

At the very end of the cycle, I was able to talk with a user of the system, despite this being a goal for later cycles. After talking with him, I was pleased to find that many of the usability issues I described were issues that they were experiencing in day to day activity. He also highlighted usability issues that I had overlooked, such as how hovering over ellipsis at the end of ticket descriptions would show the entire description instead of the piece that was missing.

Additional Work

Along with my assigned work, I have also been working on an internal side project within Bosch. This side project is dedicated to modifying the appearance of one of our products in order to bring the visuals up to date. In order to do this, I created a style guide in Sketch that contains the new elements for the product. I created the following pages for this style guide:

As this project was under a tight deadline (4 weeks from start to finish), my next task was to begin changing the CSS on the product to match my style guide. This required me to utilize Team Foundation Server to go in, check out the respective files, edit them, and then check them back in. While I was able to do about 90% of the work myself, the remaining 10% of the work was outsourced.

Lessons Learned

While the contract is still ongoing, it has been very educational as to how developer driven design can not only prevent usability issues from being fixed, but even perpetuate them across products. While I developed a style guide at Greenlancer, this is the first time that I've developed a style guide under such a close deadline. This has really made me appreciate having ample time to develop and refine style guides before implementing them. I also have a newfound respect for front end developers, as editing the CSS at times was incredibly challenging.

© 2017 Jonathan De Heus