Making cloud automation easier for non-technical users

Turning cryptic cron syntax into a clear, user-driven scheduling experience
Product thumbnail
Developer workflows
Low-code tooling
Tight timeline

TL;DR

Problem
Predictable load + cryptic cron led to manual resizing and idle spend.
Solution
Schedule-based autoscaling with quick presets, full cron, and a calendar preview.
Impact
Lower idle capacity costs and increased scheduling confidence across instance pools.
~$2k
Average quarterly savings
5
Iterations
16
Lattes consumed

Context

At Oracle Cloud Infrastructure, this project rapidly progressed from April to June 2020, reaching General Availability. Although engineering had started on the scheduler logic, a clear user flow was missing. As a senior UX designer, I crafted an intuitive experience for users familiar with OCI's autoscaling, while enabling powerful, predictable pattern functionality.
Company
Oracle Cloud Infrastructure
My Team
PM, principal engineer, dev leads, content strategist
Timeline
Project start: April 2020 | GA launch: June 2020
Tools used
Sketch to PDF export, Jira, Confluence, Slack, Agile
My Role
Senior UX designer
Impact
Informed the launch of schedule-based autoscaling for instance pools, and a year later, for instance state autoscaling.

Problem

Many workloads have predictable schedules, yet teams had to manually adjust infrastructure or pay for idle resources during low demand. The core issue was the absence of an automated, cost-efficient scaling solution for these scheduled workloads.

Solution

We developed a scheduling interface that lets teams set instance pool capacity changes based on predictable patterns, automating scaling and reducing idle infrastructure costs.

The deep dive

Jobs to be done

In enterprise and technical design, we rarely have fully detailed personas for each feature. Instead, I focus on jobs to be done: the specific tasks and outcomes real users need. They’re here to get something working, solve the problem, and move on with their day.
  • DevOps engineers: When load follows a predictable weekday pattern (e.g., 9–5 local, Mon–Fri), I want to scale instance pools out/in on a recurring schedule, so I can meet demand without manual changes.
  • QA and staging managers: When a QA/staging testing window opens, I want to schedule capacity to start beforehand and shut down afterward, so I can run tests reliably and avoid paying outside the window.
  • Retail platform teams: When a planned promotion or traffic surge is approaching, I want to pre-schedule temporary scale-ups by region, so I can absorb the spike without throttling or errors.
  • Cost control specialists: When the business is closed (nights/weekends), I want to scale down non-critical pools by time zone (respecting holidays/DST), so I can minimize idle spend without risking SLAs.
  • IT service managers: When maintenance is planned, I want to schedule capacity holds/reductions and automatic restore after the window, so I can patch safely without customer impact.

Constraints and considerations

The existing autoscaling flows were built for reactive scaling, meaning the new scheduling model had no precedent within the established user interface
The solution needed to account for complexities such as time zone differences, daylight saving changes, and recurring patterns without introducing excessive complexity for the user
The interface had to support both basic, common scheduling needs and more advanced, specific requirements within the same coherent design.

Key contributions and design approach

Engineering provided an early prototype of the scheduling engine, but the critical user flow was yet to be defined. My initial approach involved conducting quick interviews with DevOps and internal capacity teams to gain a deep understanding of their specific scheduling needs and to identify common patterns such as seasonal peaks, promotional events, and routine maintenance windows. This foundational research was crucial for shaping an experience that truly met user requirements.

Following the discovery phase, I explored various methods to embed the scheduling model seamlessly into the existing autoscaling UI. This involved extensive testing of different layouts, including calendar-based, table-based, and rule-based options, to assess their clarity and user-friendliness. The goal was to ensure the new scheduling feature felt like a natural extension of the familiar OCI autoscaling environment, rather than a disconnected addition.

The final design culminated in a dual-mode user interface that effectively supported both quick, straightforward scheduling for common patterns and advanced, recurring rules. A key highlight was the inclusion of an inline preview of upcoming scale events, which significantly boosted user confidence before saving changes. Furthermore, the interface provided a visual representation of trends over time, helping users to understand the long-term impacts of their selected cron schedule.

A graphic explaining the different ways to display time and why they don't work for this feature.

Impact and outcomes

This project directly informed the successful launch of schedule-based autoscaling for Compute instance pools. The official release date for this feature was June 16, 2020. A year later, the work also informed the launch of instance state autoscaling. Quantitatively, the solution demonstrated an average quarterly savings of $2k. The project involved 5 design iterations and, remarkably, 16 lattes consumed, reflecting the intensive effort.

Future vision

Following the successful launch of this feature, the next steps identified for its evolution included the continued development of a projected timeline preview, showing precisely when instance pools would scale. The addition of more quick-start options, informed by user data, to further streamline the scheduling process. The potential incorporation of additional “cron flavors” to offer greater flexibility in defining schedules.

What I learned

This project underscored several fundamental principles that I now consistently apply in the design of low-code tools:

  • Write for clarity, not cleverness: When dealing with inherently dense concepts like cron expressions, the primary objective is to make their underlying logic easily navigable and understandable for users.
  • Small details matter: Even a seemingly small and focused project can reveal its profound impact by helping a large number of users solve critical problems.
  • Transparency builds trust: Providing users with both builder-style options and direct expression inputs offers freedom and control without introducing confusion, thereby building stronger user trust.

Other case studies