Smartwatch and wearable prototyping

Make every glance count.

Turn smartwatch, fitness band, and companion app ideas into a clickable prototype. Use Mockitt to arrange small-screen layouts, reuse components, and connect the moments that make a wearable useful.

Smartwatch running interface concept showing workout metrics and the saved result.
Small-screen layoutsReusable statesClickable prototypesShared reviews

Start with the moment of use

A smaller screen needs sharper priorities.

A wearable interface often has only a glance to communicate something useful. Choose the information and action that matter in that moment, then move the longer reading and detailed settings to the right place.

01Activity tracking

During a run, show right now.

Prioritize distance, elapsed time, and pause. Show the summary after the workout; let the phone handle routes and detailed history.

02Daily reminders

One notification. One clear decision.

Explain what happened and offer a direct action: view, remind later, or dismiss. Make the outcome visible after the person responds.

03Device and phone

A quick action on the wrist. Details on the phone.

Separate quick checks from setup, history, and troubleshooting. Then design how the two devices connect and recover.

01 / Design for the screen shape

The same information.
A different arrangement.

Choose the target screen's shape, dimensions, and usable area before arranging the page. A circular watch, rectangular watch, and narrow band need their own layout decisions—not a scaled-down copy of the same screen.

Round, rectangular, and narrow wearable screen concepts with different arrangements of running metrics.

Round: protect the edges.

Keep essential information readable inside the curved screen. Check longer labels, large values, and the placement of touch controls.

Rectangular: group by task.

Give the main metric, secondary information, and action their own space. Respect rounded corners and system areas.

Narrow: reduce side-by-side content.

Stack values and units, simplify secondary information, and make the next action recognizable without a dense row of icons.

Use the target platform's guidance for touch areas, type, and safe regions, then check the design on the intended device.

02 / Make the interaction tangible

Start. Pause. Resume.
Save the result.

A running prototype should show the whole experience: prepare, start, pause, continue, and finish. Try the sample states below to see how the information and available actions change.

Outdoor run0.00kmReady when you are

Interactive concept with fixed example data.

Ready to begin

One main action, before the workout starts.

Give the start control a clear position. If a required permission or location is unavailable, explain what is missing before the person begins.

Make the main action obvious.

During a workout, pause should be easy to find. Keep it distinct from ending the session.

Preserve the person's progress.

Pausing retains the workout. Resuming returns to the active state. Saving gives a result the person can recognize.

Show the difficult moments too.

Plan failed saves, lost connections, and retries, including where the existing record is stored.

ReadyRunningPausedSaved
Wearable design components showing workout metrics, a compass, weather, and status indicators.

03 / Build it in Mockitt

Small-screen details.
Reusable building blocks.

Arrange text, shapes, icons, and components, then connect the screens and states. Build enough of the journey for the team to understand the behavior, not just the appearance.

Set up the right canvas.

Start with the device dimensions. Place the main metric, unit, and action before adding secondary information.

Reuse the visual system.

Keep metrics, buttons, alerts, and lists consistent across the workout and settings screens.

Connect and preview.

Use screen links, overlays, and state changes to review starting, returning, and leaving the task.

Explore Mockitt prototyping →

04 / Connect the wrist and the phone

Saved on the watch.
Not yet on the phone.

Those are different states. Put the device and companion app in the same prototype so the team can discuss saving, transferring, and viewing a record without confusing one step with another.

Keep the device result visible.

A saved workout waiting to sync should still look saved. Do not make the person wonder whether it disappeared.

Explain progress on the phone.

Show connecting, syncing, and failed states separately. Offer a retry where it can help.

Make success easy to check.

Let the person find the workout time and summary after syncing, rather than relying on a message that quickly disappears.

Watch and companion phone concepts distinguishing a saved workout from a record waiting to sync.

05 / Review the behavior with your team

Discuss what happens after the tap.

Share the same prototype with product, design, and engineering. Connect each screen to the state, rule, and implementation requirement it represents.

01Preview

Walk through the task.

Start the workout, pause, resume, and save. Check long labels, large numbers, empty states, and the way back.

02Comment

Keep feedback in context.

Discuss labels, hierarchy, and controls on the screen they affect. Share access appropriate to the project and its reviewers.

03Hand off

Connect the interface to the hardware.

Provide dimensions, assets, and state behavior. Document crown input, physical buttons, haptics, and permissions for implementation on the actual device.

A concrete starting point

What should your wearable help someone do?

Choose a use case and screen shape to prepare a prototype brief. Share it with your team or copy it into Mockitt AI to explore the first screens.

Choose the device and task before visual details. AI access and usage depend on your plan; view pricing.

Your wearable prototype briefUpdates with your selections

Questions before you start

Wearable prototyping, with the device in mind.

Can Mockitt be used to design smartwatch and fitness band interfaces?

Yes. You can design layouts, reusable components, and clickable interactions, then review the wearable and companion app together. Set up the canvas for the intended device and validate the implemented experience against the platform's requirements.

Can the same layout work on round and rectangular watches?

The information may be shared, but its arrangement often needs to change. Review curved edges, corners, available space, and action placement for each shape rather than resizing the whole screen.

Can a prototype read heart rate, location, or Bluetooth data?

A prototype can show the interface and example states for those features. Actual sensor readings, Bluetooth connections, storage, and synchronization require implementation and testing with the device.

What should the first wearable prototype include?

Start with one task and its complete flow. For a running watch, include ready, active, paused, resumed, and saved states. Then add the failures or permissions that could stop that task.

Should the companion app be part of the same design?

Include it when the experience depends on the phone for setup, history, syncing, or detailed information. Showing both sides helps reviewers identify which device owns each action and what should happen when the connection is unavailable.

Keep the experience connected

Continue from the wrist to the rest of the journey.

From a glance to a complete experience

Build the small screen.
Connect every next step.

Make your wearable idea something the team can try.