Elastic jobs in Azure

Role: Product Designer
Timeline: 3 Weeks
Tools: Figma
Collaborators: Engineers, Design PM

Tasks include: Researching users, Planning user tasks and flows, Creating wireframes and prototypes, Testing usability, and Designing user interfaces

Project Overview

Azure SQL’s Elastic Jobs allow users to run T-SQL scripts across multiple databases, either on a schedule or on-demand. However, the existing experience was complex and difficult to navigate, requiring users to manually configure various components without clear guidance. My goal was to redesign the experience to make job creation, monitoring, and management more intuitive and efficient.

The problem with elastic jobs

The Problem

Users struggled with:

Understanding the multi-step setup process (job agent, credentials, target groups, logins, job steps).
Managing jobs across multiple databases and servers dynamically.
Monitoring job execution status and troubleshooting failures efficiently.

These challenges created a high cognitive load, increasing the likelihood of errors and making the feature difficult to adopt.

What is an elastic job?

Elastic jobs provide the ability to run one or more T-SQL scripts in parallel, across a large number of databases, on a schedule, or on-demand. The target can be any tier of Azure SQL Database.
You can run scheduled jobs against any combination of databases: one or more individual databases, all databases on a server, and all databases in an elastic pool, with the added flexibility to include or exclude any specific database.

How to create an elastic job?

Create an Elastic job agent
Create credentials on the Agent database in Azure SQL
Create a target group and members
Create logins on the target master and user database
Create job and job steps

When to use elastic jobs?

Have a task that needs to be run regularly on a schedule, targeting one or more databases.
Have a task that needs to be run once, but across multiple databases.
Need to run jobs against any combination of databases: one or more individual databases, all databases on a server, all databases in an elastic pool, with the added flexibility to include or exclude any specific database.

Jobs can run across multiple servers, multiple pools, and can even run against databases in different subscriptions. Servers and pools are dynamically enumerated at runtime, so jobs run against all databases that exist in the target group at the time of execution.
This is a significant differentiation from SQL Agent, which cannot dynamically enumerate the target databases, especially in SaaS customer scenarios where databases are added/deleted dynamically.

Prototype and Design story

The design story

The purpose of this design was to help users find a way to create, monitor, and manage elastic jobs.

Creating a wizard-like process to create the full process of creating an elastic job. The purpose of the design decision to use a wizard, similar to how we use Turbotax, it is a process that can come off as complicated and can easily be digestible by users using a step by step process.

Each Target group with a job is in a card view where the user is able to monitor and see the status of the job executions.

I worked with a team of engineers and a design PM, we did weekly design sprints where, in each meeting, we discussed design feedback and had weekly design updates.

Designs were done in three (3) weeks with continued support given to engineering after design handoff.

The design approach

Process & Collaboration

1. Research & Ideation

Analyzed existing workflows to identify pain points.
Researched comparable industry solutions to benchmark best practices.

2. Design & Prototyping

Created low-fidelity wireframes to define the core user flow.
Developed high-fidelity prototypes in Figma for user testing.

3. Iteration & Validation

Conducted weekly design sprints with engineers and the design PM.
Gathered user feedback through usability testing and iterated accordingly.
Ensured engineering feasibility while maintaining design quality.

4. Handoff & Support

Provided a detailed design spec and interactive prototypes for engineers.
Continued post-handoff collaboration to ensure smooth implementation.

To simplify the workflow, I designed a guided, wizard-based experience, breaking down the process into digestible steps.

Inspired by tools like TurboTax, this approach ensures users can successfully configure an elastic job without confusion.

Key Design Solutions

Wizard-Based Job Creation
- Step-by-step flow simplifies complex configurations.
- Inline help text and error prevention mechanisms improve usability.
- Users can review and confirm settings before execution, reducing mistakes.
Card-Based Monitoring Dashboard
- Each target group and its jobs are displayed as cards, offering a clear visual hierarchy.
- Users can quickly assess job statuses, execution logs, and failures at a glance.
Design Justification Using UX Principles
- Hick’s Law: The wizard reduces cognitive overload by presenting information progressively.
- Jakob’s Law: Familiar step-by-step patterns make navigation intuitive.
- Fitts’ Law: Primary actions are positioned for quick accessibility and efficiency.

Outcome & Impact

✅ Increased adoption by making the elastic job setup significantly easier.
✅ Reduced configuration errors with a guided, error-proof process.
✅ Improved monitoring experience, allowing users to manage jobs effortlessly.
✅ Strengthened design-engineering collaboration, leading to efficient execution.

Reflection & Learnings

Guided experiences reduce complexity: The wizard approach made a previously intimidating process accessible to users of all levels.
Early engineering collaboration ensures feasibility: Close alignment prevented last-minute redesigns.
User testing is crucial: Direct feedback from real users shaped critical improvements.

This project reinforced my belief that great design isn't just about aesthetics—it's about making powerful tools easy to use.