Bringing Source Code Internal

The Opportunity:

Third-party services are an excellent resource when you are getting started, but they are designed for a general use that can reach the most customers. OCI has matured to the point that their reliance on Bit Bucket needed to end and source code management needed to remain internally for the company. Designing a tool that would parody some of the key features of Bit Bucket as well as creating custom features that could expedite source code management in OCI would be the ultimate goal. The challenge of balancing services from a third-party in an exisiting style guide would present it's own challenges.

Welcoming New Services in an Existing Style:

OCI had an established style guide for their cloud software suite. They were even introducing a new one soon that would rely on the current one being developed correctly and adhering to style rules. This meant that if we were going to parody source code management function, we needed to do so in a way that would fit nicely into the existing style guide, accept the new styleguide, and still be usable, intuitive and discoverable for our users.

Both products had a well established style guide, navigation architecture, and a clear settings profile. I needed to understand both systems and begin the work of fitting the Bit Bucket features we needed into the OCI styleguide. This meant changing navigation and controls to fit OCI, feel intuitive to an OCI user, and still include the services of Bit Bucket.

A Style Guide's Shortcoming:

The scope of the project was a large t-shirt size. We decided to break the project up into more managable sized tickets. The first would be the basic functions of source code management. The second would be enhancements of source code management that would benefit OCI specifically. We grouped functions that we thought could be improved upon like "blame functionality" into the second ticket.

This is where I found myself in a user experience conundrum that every designer working in a style guide finds themselves. The styleguide did not provide the best user experience for blame functionality. What OCI's "Maui" styleguide would prescribe is a codeview window with expanding rows to see who committed a source code change:

Breaking a Style Guide for Function:

I was able to run this version of the "blame" functionality by many developers on staff and while this was the approved way for OCI's style guide to display this fuction, it wasn't as usable for our developers. For the sake of adopting the new tool over Bit Bucket and making it work for the needs of the user, I decided I needed to break the styleguide. This would be in the best interest of the user and ultimately where my responsibilies lay.

When put in front of future users of this new tool, the new "blame" functionality won them over. It was much more on parody as the tool they were used to and felt that the new highlight feature was something that would even further enhance their workflow. A feature the old product at Bit Bucket was lacking.

A Win for a Maturing Corporation:

This is another example of how user experience work can make lives better, easier, and save the company money as well. I am an advocate for the end user as a user experience designer, but I also want to be an advocate for this type of work in business as well. Thoughtful use of user experience work can contribute to lowering the cost of business or grow revenue!

The business impact:

Moving source code management to an internal tool raised security for the company, but it also helped the operating cost of doing business too:

Figma Working File (Password Protected
for interview only)