All of the systems the UX Console team was supporting were complex, cloud computing services. The larger org was designing and building a Bare-Metal cloud from scratch and having an extensible and usable user interface was seen as a key feature that would set Oracle apart from other cloud computing offerings. This was a new product, so I used sitemaps and user flows early on to help define what we needed to build and to understand the different paths, use cases and edge cases. These were reviewed with both the service teams building each of the features, and the UX team that was building the console that supported those services.

Early on in the project, a couple of us worked on a design pattern for a complex, multi-step, multi-dependent, cross-service vertical wizard. For example, an administrator may want to create a new group at the same time they are creating (or adding) new users to the system. Or one might want to create a new network and storage, while creating and launching a new instance. The designs ended up being (way) out of scope for the minimal viable product we were working to launch, but the exercise allowed us to better understand which systems were dependent on what, and if there were paths we would need to force the user to take first in order to not dead end the them in the middle of a task, or in some cases, keep them from bricking the system.

It’s important to me to use realistic data and/or content whenever possible, and to always illustrate additional states, use cases or design explorations. This ensures the designs are extensible. It’s also useful when working closely with engineering to make sure the implementation addresses the various use cases gracefully, that QA team has test cases to test for them, and the technical content team can write documentation that supports them.

Because of the types of systems and services cloud computing supports, it was important that the design pattern for indicating issues in the system was more extensive, helpful, and actionable. The design team worked to come up with a pattern that could message when:

• things were in a good state

• there was information one needed to know but no action necessary

• there was something that might be an issue and/or a recommended action should be taken

• or when something was in an error state and was blocking the user or other systems.

Many of the design iterations included cursory explorations for future revisions and features. The purpose of this was to help drive discussions around priorities and scope, as well as to make sure the designs were extensible enough to handle future feature releases. These examples typically explored the ideal user experience, which were often out of scope—but when reviewed with product and engineering, they helped drive intelligent conversations regarding how an API was being designed and what it could and should be able to support later.

The Good

I got to work alongside some of the most talented engineers, product people, & technical content people in the cloud computing business: people that had been some of the early pioneers of products like AWS. Additionally, the UX team was in a unique position to see and support all of the various service verticals—computing, networking, storage, etc.—as a result, I was able to gain valuable experience facilitating cross-platform reviews and discussions. Some of these design reviews ended up being the first or few times the various team leads and directors talked with each other in detail about their services.

The Not So Good

As the UX design lead, I was responsible for managing and prioritizing all of the design related tasks. And while we did an amazing job pushing forward and meeting our deadlines, I failed to work closely enough with the UX engineering team to make sure the designs we were reviewing with leadership (and getting sign-off on) were within scope of what our own engineers would be able to build and launch. The UX design team got too far ahead of our own engineering team. This ended up reflecting poorly on my direct leadership, as it mismanaged the expectations of other service teams leaders.