Back

Google

Engineering training tools

Conduct interviews to gain a better understanding of how Google engineers use the internal resources available to them and redesign those tools to better fit their needs.

Due to the nature of this project, it cannot be shared publicly. While a description of the work is here, please reach out if you are interested in further details.

About the project

As a design contractor for an internal team at Google, I was tasked with redesigning some of the online tools available for engineers. This included an internal search platform and tutorials built around various engineering tools and tasks. There was a lot of great content in place, and the goal was to improve the layout and structure to make it all easier to use.

The bulk of my time was spent conducting and documenting interviews with engineers throughout Google. I reached out to Googlers based on their team, location, and time at Google to discuss what tools they used while working and what their thoughts were on the tools our team had to offer. Later in the process I tested the usability of my new designs as a follow up to the initial interview.

About the team

For this project, I worked with two project managers, and a few technical copywriters. We shared our research findings with key members of department and got their feedback on next steps as we progressed through the project.

About the work

The tools in place at Google had existed for some time now, but being internal tools, they hadn’t seen a lot of time and attention from a UX perspective. They certainly weren’t the worst layouts and designs I had ever seen, but they definitely had room to improve.

While my final deliverable were updated mockups and prototypes of my new designs, the bulk of my time at Google was spent as a UX Researcher. Overall, there were a few main areas I focused on redesigning during the project.

The original design of the articles had some clear problems in the structure of the page. The top of the article had a quick table of contents, but no summary information about the article. The side bar was being used as a menu to other articles, but all developers I spoke to said they never used it.

Table of contents & related articles

I started by cleaning up the sidebar and moving the table of contents there. From my research I found that the table of contents was extremely important for developers, because they preferred to skip through most articles to find the bit they needed. By keeping the TOC always available, this made that a lot easier to do. Since many articles had related articles or were part of a series, I kept this in the sidebar as well under the table of contents. These links were originally at the top of the article and many developers reiterated my first thoughts towards that design - “Starting the article by pointing to other articles is not very helpful”. By moving it to the sidebar, I kept it within view without needing to scroll, but in a more logical order with other content.

Article introduction

Second, I found that developers were looking for key bits of information before reading the article: a quick description, the date it was last updated, and the author. I moved all of these to the very top of the page. My goal was for a developer to have enough information to decide if this was the right article for them in an easily accessible way. In the previous design, information, such as the date last updated, were at the very bottom of the article, and multiple developers showed me how they scrolled all the way down to find it first.

Header Navigation

The original menu included several links related to different, not necessarily related resources. My research quickly showed that not only did developers not use the top navigation, they didn’t know what most of the links were. I decided to remove the links and and replace them with two key functionalities - “File a bug” and “Edit”. An important point about these articles is that they are built and maintained by other Google developers. While some knew that they could contribute to the article, not all did. By moving these buttons to the top of the article (rather than the bottom, where they were before) my goal was to encourage developers to use them to keep articles up to date.

Tagging & Topic pages

One thing that became apparent very quickly was how difficult it was to get between articles of related content. I came up with a concept of “article tags” by topic to solve this problem. Each article could have up to 3 or 4 tag (ie. C++, Android, etc.). The tags could then link to what I called “topic pages” would would list all article tagged with the same topic, plus offer up some related topics.

Portals

Last, I built what we called “portals” for various topics. These were meant to be catalog’s of various articles (of all different types) and links to external tools. Our ultimate goal was to promote these “portals” for topics like Android or Machine Learning, and reduce the need for developers to find an individual article via search. This would also allow us to surface other useful resources aside from our articles, without cluttering the articles themselves with too many links.

Guides

To top it all off, I built decks with guides for how to properly construct an article. In the end, the success of this architecture relied on the author writing a proper introduction, a well structured table of contents, and tagging their article with relevant topics. My guide walked through the new article structure and the purpose of each piece, and gave tips on how to best take advantage of it.

Other research findings

An interesting bit of information that my research showed me was that, given that I was designing for very technically savvy people, I could take advantage of browser features such as “Find” and bookmarking rather than building this into the tool. Information like this helped me prioritize the features I wanted to add, what I could get away with leaving out, and what was not worth the time to build.

What would I do differently?

As a part of my proposed design for the article pages, I also created designs for a proposed backend to manage these pages. If I had the time and resources, I would have loved to see that backend get implemented. My interviews really showed me that the tutorial were only useful if they were well maintained, and being an internal tool, quality wasn’t always guaranteed. Given that I got to work with the technical writers so closely, it wasn’t difficult to see how the articles became out of date. A tool for the authors, in my opinion, would have made a much more significant impact that redesigning the articles themselves, and would have made a lot of people’s lives quite a bit easier.