Designing with constraints — Live Activity and Dynamic Island
Apple launched the Live Activity widget with iOS 14 and followed it up with Dynamic Island in iPhone 14 Pro. With these updates, Apple attempts to reinvent push notifications delivery on mobile devices. On it’s launch, it was instantly obvious that Swiggy, a food delivery app which sends multiple notifications to communicate delivery progress, has the perfect use case to utilise these new features. Fast forward to now, both are live for Swiggy users 🎉
We were awestruck by the Apple’s slick demo but as we dug deeper we realised that there’s more than what meets the eye. This blog is behind-the-scenes of how we went about designing the latest widgets for our users.
Why Swiggy is the perfect use case?
Being a hyper-local food delivery app, post-order tracking is a critical part of users' journey. After a user places a food order, these are the following states that we communicate to keep them updated on the order’s progress:
- Order received/accepted by restaurant.
- Restaurant is preparing the order.
- Delivery partner has reached the restaurant.
- Order is out for delivery.
- Delivery partner has reached the user’s location.
- Order delivered.
The above steps all take place within a span of 30 – 40 mins. And to keep the user informed we send 5 notifications vs with the live activity widget all of the updates can be handled in a single widget! It was clear that Swiggy users could get immense value out of the live activity framework.
What is Live Activity?
Let’s start with some context on what is live activity —
This is how Apple describes the widget — A Live Activity displays up-to-date information from your app, allowing people to view the progress of events or tasks at a glance. You can read up the HIG guidelines for more information.
It is a smart way of surfacing live updates for any activity which happens in a short span of time on your device. Some of the use cases include cab rides, flight tracking, and sports updates. Live activity solves the following things:
- Avoids crowding of push notifications.
- Chunks information in a reliable and glanceable manner.
Dynamic Island
Later in the year, Apple introduced Dynamic Island on its iPhone 14 Pro. It’s a pill-shaped cutout at the top of the device which can be used to share the status of any live event when the device is being actively used. The most common use-case includes song status from any music app, stopwatch/ countdown, or toggles for screen recording.
In reality, it is an extension of the Live Activity widget which neatly ties the experience together when the user is actively using the device.
This is how Apple describes the island — On devices that support the Dynamic Island, the system displays Live Activities in a persistent location around the TrueDepth camera. You can read up the HIG guidelines for more information.
So one of the important things was to ensure consistency with the already designed Live Activity widget along with of course our app.
Now, let’s get started…
Live activity and Dynamic Island both are rather simple frameworks with limited scope and complexity, which is what makes them so good! A bigger part of designing for them is working around the constraints, so as part of describing the process I will be talking about the different constraints and how they shaped the designs.
Since we were super enthusiastic and wanted to be early adopters of the feature we began the hands-on work the next day of release. That meant that a lot of documentation describing the constraints was not yet available for reference. Over here, kind folks at Apple stepped in to help us and after multiple back and forth emails and calls with their DevRel we got the clarity we needed. So let’s get started
In many places the following abbreviations have been used, LA for Live Activity and DI for Dynamic Island
Interval of receiving an update can be high
The frequency of receiving an update can vary and sometimes be on the higher side. This can be due to different technical and operational reasons.
This meant that an approach that leans heavily on the progress bar or the map might not be the best. The user might see the progress bar not being updated for a while which may lead to unnecessary anxiety. So we didn’t want the users to anchor too much to the progress bar or the ETA number and to solve for that we introduced a third element, illustrations.
Instead of making the progress bar or title with ETA the primary hero element (like above) we chose to leverage our illustration style. With the illustrations we were able to strike a balance, as the progress bar and ETA, while still prominent, didn’t have the highest visual hierarchy. The illustrations accurately communicated the order status without being too specific. Illustrations also solved perfectly for glanceability which is one of the primary goals of the widget.
Courtesy: Ezaz Ansari and our in-house Design Solutions team!
At Swiggy our visual team has been continuously evolving the illustration style introducing 3D characters as part of that. Going forward you can expect to see more 3D being part of our visual communication :)
Making sure LA works with all kinds of backgrounds
LA will show up on the lock screen, and how a user chooses to customize their lock screen is not in our control so when choosing a background style for the widget we had to make sure it looks the best with all the kinds of backgrounds. This restricted our choices and we ended up going with a mostly solid black background with a slightly reducing gradient from top to bottom.
How many pixels can be used on the Dynamic Island?
While designing we had to navigate through some ambiguity and we still don’t know how many exact pixels can be used up on the dynamic island. HIG attempts to answer some of these questions but there still remain grey areas. The island can expand a bit in shape in all the views which means that the pixels available are not limited to the actual size of the cutout.
The larger question was how to use the limited space to best communicate the order status and this is how we went about the different presentations:
For compact: the left side shows the icon indicating the order status and the right side will show the ETA
For minimal: the pill shows the icon indicating the order status
For extended: straightforward and should be the same as live activity widget for consistency. The only adjustments needed were to accommodate the camera notch.
One of the things to highlight here is the picking and tweaking of icons, the icons were crucial as by themselves they had to convey the order status. The advantage we had was that icons are already part of a user's journey on Swiggy so they are most familiar with the icons we were going to use. The only thing to make sure of was the same icons work on the small space on DI.
An interesting example of tweaking an icon was the bowl icon which was going to convey that the food is being prepared state. The original icon part of our system worked well in larger sizes with supporting text but didn’t work out on DI. The icon was too intricate with details too small and too close to each other. Adding a little flourish to the spoon and increasing size of circular elements (representing food) instantly made the icon more comprehensible.
Lack of animation support
We had started with plans to include subtle animations for added delight in different order states but had to scrap those ideas and stick to static designs. Although we do see some simple animations for Apple features there is no support yet for any kind of animation for third party on both LA and DI. The reason mentioned by Apple was the drainage of the battery that continuously looping animations can have.
Font of course can’t be customised
Honestly, this was expected. Looking at the precedent set earlier for home screen widgets Apple once again stuck to the default system font. Although as a designer at Swiggy, I want all touch-points to carry the same font for our users I also understand that from a system level, it does not make sense. This can easily be abused by product builders and will result in a poor experience for iOS users.
Conclusion
As designers Milan and I faced constraints in various forms, such as limited resources, time, or other limitations as mentioned earlier. However, designing with constraints can be an enriching learning experience, as it helped us develop adaptability and flexibility. While designing it can be frustrating but the trick is to produce the best output despite all challenges and that is what design is all about. In the end, the love of the users will make all the effort worthwhile.
Going forward
One of the most interesting observation from the project was how the whole of order tracking could be folded into such a minimal experience. Literally, a 24px icon is able to successfully communicate the order status. Going forward we certainly see our approach to in-app order tracking being shaped by some of the insights we gained from the new widgets. Apart from that from a support point of view we plan to —
- Add support for InstaMart and all other services on Swiggy as well.
- Include a visual cue to differentiate the widgets in case of multiple simultaneous orders.
Want to get say hi? Send me an email at sanyamjain18@gmail.com or tweet @sanyamjain_
