This is a writing about my experience at Oracle in my Junior and Senior years at Drexel University. From April 2018 to September 2018, I was working there full-time on co-op (a work program mandated by Drexel University for six months) and then from September 2018 until I graduated in June 2019 I worked on a part-time basis.
Note: Since it is not clear what I can and can't share from my time there, this is more of a general essay about my experience, rather than a case study of the projects I worked on while I was on the team.
The branch of Oracle I worked at was in Conshohocken, PA (located 30 min. outside of Philadelphia) and was a part of CEGBU, which stands for the Construction and Engineering Global Business Unit. The company was originally called Primavera until it was acquired by Oracle in 2008. The main product that they work on is a suite of construction project management software, their most popular being a program called P6. In recent years however, the company has turned its focus towards combining and modernizing this suite into a product called Oracle Prime. With this, they formally expanded their User Experience team.
The UX team had a pretty standard structure; in the office, we had a Design Manager, a Lead UX Designer, two Senior Designers and two Junior Designers. There were also many people who worked remotely from different Oracle offices, and while these people did contribute to Prime and participated in meetings, they were usually remote because they were from acquired companies and were working to modernize their products to Oracle standards. Many of the people working on the team had years of experience working in the UX field, which made it a great environment for mentorship.
One of the best parts about being an "intern" at Oracle is that you are rarely treated like an intern. From day one, you are given the same level of respect as if you were a newly-hired employee. While of course there is a share of "menial" work you'll get as a co-op, all of it is strictly related to the design process and growing as a designer, and as I spent more time at the company I did less of those tasks. Co-ops at Oracle Prime are also historically responsible for managing systems that help other designers do their work, almost like a DevOps role but for UX Design.
Most of my time went towards three main areas: Assisting with new features, managing the icon library, and coordinating with international teams. Below, I will go more in-depth for each of these.
A PART OF THE TEAM
As a co-op, a lot of my work could be considered as-needed, meaning that I would help other designers on the team with tasks assigned to me on Jira so that they could focus on their main goals for that project. Among the team, we typically used Sketch with some plug-ins that made re-using components easier. Designers could upload a component they made and it would be available for other designers to use instantaneously. We would then upload our work to Confluence to share with the team and receive feedback, as well as for general documentation.
But sometimes I was also assigned to work on a new feature solo. An example of this that I spent a lot of time on was Time Zones. Historically, everyone working on a construction site was usually on or close to the site itself, so "time zones" weren't a consideration. But as Oracle's products grew, it became more common that people from all over a country could be overseeing a project. I was responsible for thinking about how time zones could be implemented if a contractor wanted it, but without causing too much confusion and disarray. This meant communicating a lot of automated behind-the-scenes work that goes into reformatting the times for an entire project.
Along with this, I would typically participate in user testing sessions as a notetaker, where we had one interviewer and one other notetaker. But for the Time Zones project, I organized and ran a two-day user testing workshop (mostly in the interviewer position) where we A/B tested the different paths that a user might take. For this, I used InVision.
ICONS, ICONS, ICONS
Another large and frequent responsibility I had was creating new icons and managing the icon library. There were a lot of working parts to this, but in general, the process started with a request from another designer on the team or another coworker from a different team who was overseeing a new feature. Then, I would make the icon in Illustrator, usually seeing if I could re-use parts of existing icons to save time and improve consistency. Next, I would upload the possible options to a Confluence page and have the team give votes & suggestions. If all went well, I would then send the SVG file to the development team to be included in the next build. At any given moment, I was probably handling three to four icons at different stages in this process.
When I first learned that I would be working on icons, I was a bit worried. I thought that my main strengths and experience was in following a holistic UX Design process, whereas icon design was more on the UI or Graphic Design side of the spectrum. However, I was pleasantly surprised to find that creating an icon follows much of the same process as creating a user flow or a low-fidelity wireframe. I had to think carefully about how a user would interpret the icon, and quite often I would do competitive analysis to see what other services our users often used would use for their icons so I could understand what mental models they came to our product with.
But the more time I spent dealing with icons, the more I knew something had to change. There were simply too many icons (more than 700 at the minimum) in the library, and I was questioning if the more complicated icons were even communicating anything to the user over simpler shapes. This process took a considerable amount of my final couple of months at Oracle, but we started consolidating icons to reduce the overall library size. And before I graduated, I created a new guide that simplified the whole icon creation process, preventing any future bloat as well as making it easier for non-designers to communicate with current designers about when a new icon is needed or when one should re-use an existing icon.
ORACLE NEVER SLEEPS
Oracle is a large international business, so the teams that work on some of our other (typically older) products like P6 are now stationed in different countries like India, Australia, parts of Europe, etc. It was my responsibility to coordinate with some of these teams and then work on updating some of these older products to match the updated styles that had been created for the newer Oracle Prime software. Some of these were as simple as following the style guide, but some of my work here could blur the lines between applying styles and creating new features. For example, I designed a Disconnected Mode feature for some older software where we couldn't use some of our existing components, which meant I needed to design some new components from scratch.
LESSONS FOR THE FUTURE
I am extremely grateful for the opportunity to work at a company like Oracle this early on in my career. Despite the reputation for Oracle's bad interfaces, I found that the team I worked on was committed, experienced, and extremely helpful in my growth as a UX Designer. Here are the main lessons I took from my experience:
It's OK To Be Wrong - As a student, when you get a decision wrong, that tends to mean you have to spend your personal time fixing it. However, when you are working at a company where you are there for a set amount of time, you have more time to address these mistakes without it worrying that it will snowball into something more serious. Because failure is a part of the design process, I felt more comfortable with setup, but it took some time to adjust to it.
Everyone Can Be A Designer - When everyone works on a product, it is inefficient to leave the UX Design team as the sole arbiters of how the product should look. Developers, Business Analysts, Customer Service Agents, etc., can all have great and unique suggestions.
Design To Be Built - Designers tend to be idealistic, and I'm certainly guilty of perfectionist designs. However, sometimes the design that sacrifices some polish but is much easily implementable saves the entire company time and money.