01 · Task Automation · Admin Panel
Spark
An admin panel for creating, scheduling and monitoring automated tasks with clarity.
Role
Product Designer
Focus
Task Automation · Admin Panel
Platform
Web · Admin dashboard
Tools
Figma
Project artwork is from the original presentation. The narrative below is editorial design rationale; it does not claim unprovided interviews, testing or measured business results.
Overview
Spark is a task-automation admin panel. My CV places Spark within my UXtellar work on automated purchasing. Its product scope brings task creation, scheduling and monitoring into a single operational workspace.
The problem
Automation reduces repetitive work, but introduces a new challenge: knowing what will run, when it will run and what happened afterward. The interface needs to make these answers clear without requiring an operator to inspect every task individually.
Goals
Business
- — Present a coherent product experience for operators configuring recurring automation and administrators overseeing activity.
- — Keep the main task and supporting information consistent across the journey.
User
- — Move confidently through task overview to monitor activity.
- — Understand the current context and the next meaningful action.
Design scope
- Product framing
- Information hierarchy
- Interaction design
- Visual interface design
- Task Automation
- Admin Panel
Product analysis
The central tension is control versus speed. Frequent operators need a compact overview; a new task requires deliberate input. Configuration information explains intended behavior, while execution information explains what actually happened. Keeping these concepts distinct helps avoid treating a valid setup as evidence of a successful run. This is a design analysis, not a report of user interviews or usability testing. It frames the questions the product should answer without presenting assumptions as research findings.
Flows & architecture
The sequence below is an explanatory model of the main journey, not a screen-by-screen inventory of the original design file. Each stage establishes context, supports a decision or clarifies the result.
Explorations & trade-offs
A single long form exposes all settings but increases scanning effort. A staged setup focuses attention but can hide dependencies. A useful direction combines grouped configuration, readable scheduling and a review step, while keeping an operational overview available for routine inspection. These alternatives describe design trade-offs; they are not presented as archived wireframes or a record of tests that were not supplied.
Visual design & system
A consistent interface system connects typography, spacing, navigation and action hierarchy. Headings establish context, supporting copy explains decisions and primary actions identify the next meaningful step. Reusable patterns should retain the same meaning across screens. Color should reinforce priority or status, never be its only signal. Narrow layouts need to preserve reading order and legibility rather than simply shrink the desktop arrangement. The original visual treatment is available in the project artwork and Behance presentation.
Key decisions
Separate configuration from execution
A task can be correctly configured without having completed a run. Distinguishing intended behavior from activity makes scheduled, running and completed work easier to interpret.
Make schedules understandable
Recurrence, timing and the next planned run should be interpreted together. A readable schedule summary helps operators catch mistakes before an automation becomes active.
Prioritize actionable status
Task identity, status and a relevant next action are more useful together than a disconnected collection of totals. The overview should support decisions about what needs attention.
Treat consequential actions deliberately
Editing or stopping an active automation has different consequences from opening its details. Review, confirmation and explicit feedback support a safer operational model.
Outcomes & learnings
The documented deliverable is the Spark design presentation, with links to the Figma file and prototype. No verified launch metrics or usability results were supplied, so no conversion, retention or efficiency gains are claimed here. The design takeaway is to match hierarchy to the user's current decision. The evaluation questions below provide a concrete way to assess that direction with users.
Evaluation questions
- Can an operator explain when a task will run?
- Can they distinguish a configured task from a successful execution?
- Can they identify an automation that needs attention?
Next project
Cheney Constructions