Reflecting on working on Settings

I worked on the settings project for about 6 months. Here are some things I learned.

Scale your design

Working with multiple teams, I was in meetings all the time. I started to seek out ways that to set up a framework and less manual work. So I proposed a framework concept to unify all the services and settings, which allows third party developers to maintain the content. 

What I could have done better was to also create a redline guidelines for the eng, instead of speccing every single page.

Prioritize your work

I worked with at least five PMs at the same time in this huge project. Each of them are different in working styles. Each of them think their project deserves the highest priority (which was totally understandable). I have to admit that I struggled a lot in prioritizing. I ended up doing what was the most urgent task.

At the end of the project, I started to take the lead and prioritize the work myself. I even said no to some project, and tell the PM that their project is not the priority.

Choose the right way to communicate

We had lots of internal tools in Google to communicate: Slides, Flow, Folio, site, etc. I chose the deck as it started as a small project. No one expects such big scope when it was first started. As the scope increased, the deck became a pain to maintain, especially in the implementation phase. Because the deck became so popular, we have to always keep the latest mocks there, otherwise we got comments and emails. What I failed to do is to create a project site that explains the rather foundational structure, and use folio links to update the design because they are more dynamic and can be changed quickly.

In terms of copy, my brilliant PM, Dina, invented a way to keep the freshest content in a spreadsheet. This frees me a lot of time because I don't need to do the text change in Sketch and export to upload it in deck.