This post is centered on a personal design exercise for the Apple Watch. I absolutely love Product Hunt’s way of open collaboration with its users, and wanted to experiment first hand what an Apple Watch version should feel like. I do not work for or represent Product Hunt in any capacity; I therefore don’t have access to valuable data that could have probably led to more informed design decisions.
Some could argue that Product Hunt typically falls into the category of apps that don’t necessarily translate well to the Apple Watch — This was definitely part of my initial doubts.
For a service that allows users to discover new products, being able to try them directly on the same device might be considered a prerequisite. As I began studying the possibilities, my confidence in finding a solution eventually started to grow.
Working on my first watch project, I had to extensively study the different offerings out there and was struck by the number of watch apps that are badly implemented by offering no additional value. This is a new medium we’re looking at, one that requires the same level of compromises in features we witnessed with the switch from web to mobile.
That being said, any watch version should mostly be looked at as a complement instead of an overly simplified version of the iPhone’s offering. The idea when designing for the watch is to enhance the overall experience, including bringing users back to the main iOS app.
Put differently: If there’s a way to offer a simplified independent experience on the wrist, all while complementing the main app with features specifically suited to this new medium, then it’s worth a look at.
N.B. If reading about the reasoning behind my decisions is of no interest; you can jump directly to the end of this post where I put together a quick video preview of the main app interactions.
For the sake of this exercise, I followed my own design process in an attempt to validate any premature assumptions I had.
After digging deeper into the Apple Watch human interface guidelines and the official SDK, the big picture became somewhat clearer.
Knowing whom I was designing for was pretty straightforward considering Product Hunt’s value proposition:
“Early adopters who enjoy discovering and discussing new products” obviously comes to mind first.
However, uncovering the precise users’ contexts and behaviors that would warrant a watch version was trickier as I needed to interview people that fit the criteria of both avid users and Apple Watch owners.
Developing provisional personas eventually helped me broaden my thinking and understand potential users’ anxieties, as shown in this one example:
As evidenced by the public Product Hunt PRD:
- Product people — Those building products that enjoy discovering, playing with, and learning from new, innovative products.
- Seed-Stage Investors — Always sourcing new deals and seeking signals to curate what startups to evaluate and meet.
- Everyday Tech Consumers — People that love to find new stuff.
Finding Seed Stage Investors to further test assumptions proved much more difficult — I consequently avoided including them in my analysis and chose to focus on a specific target of users: Product People and Everyday Tech Consumers.
My next step was figuring out which features from the iOS app needed prioritization over others as summarized in the following chart:
To clarify further, priority level represents the degree to which users find certain features indispensable. Relative impact on the other hand, shows the importance of those features with respect to the Watch version.
For example, “makers’ comments” can be found on the upper left quadrant. It is considered essential since it adds more personal information about a product’s vision — An important added value in leading to upvote decisions.
Feasibility on the watch however, is more problematic since it usually requires long blocks of text that would make it too difficult to browse.
I tend to jump straight into quick low fidelity wireframes to get a better feel of the direction I’m taking — Even more so when working on a relatively new medium.
While I did sketch countless potential options, I wish to focus on the 2 main navigation interfaces as stated by the official guidelines– Hierarchical (Vertical Scrolling) and Page-based (Horizontal Swiping):
I initially went for this option with the intent of staying true to Product Hunt’s navigation on other devices, as you can see in the following simplified wireframe:
The idea was that vertical scrolling allowed for more features to be integrated, including the less important ones. In my mind, this approach also allowed for more benefits to users in terms of browsing flexibility.
I quickly came back to my senses after realizing the complexities of such an approach. Considering the fact that further interactions would add yet another navigational layer to an already cluttered interface; you can see why this option is problematic:
Horizontal navigation presents many advantages over a vertical scrolling approach, most importantly by providing a limit on the number of products. Manual curation of content is actually advised by Apple in order to optimize value, specifically with respect to predesigned image resources.
The tricky part with a vertical interface is that the more information you try to include, the more you feel like you’re leaving out other elements — This ultimately creates a downward spiral at the expense of user experience.
I therefore chose to focus my solution on horizontal navigation:
Swipe between products and tap to navigate to a new page that includes additional information.
I wish to focus however on the lessons learned, specifically with respect to the 5 seconds rule. According to Apple: Users interact for an average of about 5 seconds with any given app on the watch.
I found that fact to be particularly true in the case of a Hierarchical navigation vs. Page-based. It’s also amplified if you consider the necessity to tap and interact with buttons on a significantly smaller screen.
Taking those factors into account, I knew I still needed to further simplify my solution.
As briefly mentioned above, my main doubt when approaching this exercise was the overall viability of a watch version.
If you can’t try a new product on the same device you’re using, how can you possibly make any decision to upvote or add it to collections?
The answer to that question isn’t that simple. However, in spite of the very low data sample I was limited to, feedback showed a tendency for users to act on first impressions.
I therefore had one specific objective in mind: To design a solution that provide users with just enough information, prompting them to either act directly on the watch, or be redirected to other platforms at worse (iOS and Web).
With that in mind, first time watch users are welcomed with the following tutorial:
For the main app interface, I stuck with horizontal swiping where each page is dedicated to a top trending product of the day.
You might ask why I opted for daily vs. overall popularity. The answer is simply because it falls in line with the recently simplified offering of the iOS app where contrary to previous version, “Today” now takes center stage over “Popular”.
Stating the obvious, featuring top daily products also allows for more variable content overtime.
Users can swipe through the top 10 daily products displaying the following information:
- Name & Logo for instant brand emphasis
- Tagline for a quick preview of value proposition
- Category that includes: Tech, Games, Books or Podcasts
If users are drawn to a specific product, then a simple vertical scroll leads to more information in the form of number of upvotes & comments:
Again with respect to the 5 seconds rule, this interface allows users to sufficiently immerse themselves into a product’s offering without compromising further discovery.
When designing for the watch, it is also important to consider technical limitations. For instance, at the time of this writing, WatchKit doesn’t allow developers to implement vertical paging. While the effect can be emulated with regular scrolling, snapping to page boundaries could have made navigation even smoother.
Designing for performance is also a must, thus the intentional lack of more elaborate media, mostly to avoid slow loading time. This is also amplified by the difficulty of implementing high-resolution images that can fit properly within the device’s limited dimensions.
The same can be said of other types of information such as makers or hunters. Makers for one can include several team members, making scrolling significantly longer. Being able to explore a considerable amount of products in one session, is much more rewarding than only discovering a few because of cluttered information.
If users eventually find a product to their liking, force touching opens up a contextual menu that gives the option to either upvote a product or add to personal collections.
As soon as this step is completed, it is reinforced with the small upvote icon appearing on the app’s interface — Particularly important to keep track of recent actions of the day.
The same flow happens when adding to collections:
Finally, if a user attempts to re-upvote a product despite having already done so, he receives the following message:
Glances provide contextual information (albeit limited) made easily accessible from the watch home screen. In this case, Glances showcase the top trending product of the day:
You can’t possibly expect users to continuously browse the main app interface on any given day. A quick peep via glances should at least prevent users from missing out on the very top products. If needed, tapping on the glance opens up the main app.
One last note on glances: I considered including a dedicated section on the main app for podcast listening — I eventually decided to rely instead on the native watch player. The reality is that podcasts are not the main feature of Product Hunt and users can always play those from their phone and control them later on, directly from their wrist.
Current Apple Watch owners can already mirror their Product Hunt iOS notifications — Those however, come in static looks automatically created by the system.
The advantage of having a version native to the watch comes in the form of custom looks with dynamic interfaces. I wish to focus specifically on the following two scenarios:
- New Friend Post
- Friends Upvotes
In my view, those are important to the long-term vision of Product Hunt — One that shows an increasing emphasis on community.
Since both the main app and glances highlight curated top trending products, I could be guilty of dismissing the more personalized aspect of the value proposition.
My personal belief however, is that a right balance can be found where notifications play the role of bringing other relevant information to users — Information that cannot possibly fit on the main app interface.
Finally, I also felt the need to experiment further with possible empty states:
I wish to point out that animations on the watch are pretty limited compared to the possibilities on iOS. I therefore needed to adapt to certain restrictions such as the lack of spring animations in page loading for instance.
At the end of the day, we’re also designing for significantly small screens – All those subtle animations we’re used to see on iPhone don’t always translate well to 42mm devices.
Here is small video preview I put together of the main interactions and animations of my design:
I needed a more hands on approach to designing for the Apple Watch in order to better grasp the intricacies that go with it. It ultimately all comes down to designing with simplicity in mind.
I am aware this is by no means a perfect solution (it never is), so in case I missed something, I’d love to hear your thoughts about it.
Thanks for being awesome by sticking with me to the end of this post.
If you like what you just read, please recommend 💚 this post so that others might stumble upon it. To see more of my work, you can go on edsab.com