DICE is a ticketing app focused on live music and events. The app’s goal is to make going out and creating plans feel effortless. DICE offers fast mobile ticket purchasing and personalized event recommendations. Users can buy tickets in seconds and send them to friends in-app. DICE’s curated homepage helps users discover relevant shows, which can be filtered by date, city, and interests. This critique reviews DICE’s mobile iOS application using principles outlined in Don Norman’s The Design of Everyday Things.
Finding upcoming events
Finding an event on Dice is easy and intuitive. From the moment a user lands on the Home screen, DICE clearly communicates its available actions, minimizing the user’s cognitive load.
At the top of the homepage, the headline “Make Plans” acts as a signifier that frames the app’s primary goal. Directly beneath the headline is a horizontal navigation bar with categories such as “This Week”, “New Shows”, and “Top Shows.”
The categories themselves function as both signifiers and affordances. The pill-shaped buttons signal that they are interactive and meant to be tapped. The mapping between selecting a categorical button and seeing an updated event page is immediate.
On the bottom navigation bar, the search icon on the right serves as a universally recognized signifier. Even without a text label, the icon leverages knowledge in the head, allowing users to predict its function. Tapping the icon leads to a dedicated search page with a search bar at the top. Right below the search bar, filter options for date, price, and city further support effective mapping. These filters mirror how users naturally think about planning events (and their mental models), showcasing the app’s strong conceptual model.
Further down the screen, event categories such as “Party,” “Sport,” and “Comedy” act as secondary navigation aids. These categories function as signifiers that help users find events that match their interests. By grouping content this way, DICE reduces cognitive effort.
One area DICE could improve is how the map is integrated into the search experience. Currently, the map is accessed through a small “View map” button in the corner of the screen. The button blends into the bottom navigation and makes the map feature feel secondary.
Additionally, the “Recently Viewed” section takes up most of the screen. This creates an unbalanced hierarchy that pulls attention away from the search bar and filtering tools, even though those are the user’s primary controls for finding upcoming events. This disrupts discoverability as the interface suggests that revisiting past events is more important than actively searching.
This could be improved by embedding a condensed map view directly into the search page, placed underneath a shortened “Recently Viewed” section. This way, each section on the page would have a more balanced visual weight. To maintain full usability of each feature, the “Map” and “Recently Viewed” sections could include a small arrow button next to its headline. Tapping this would open the section into a full-screen view.
Purchasing a ticket
Once a user clicks into an event, the main event details are immediately visible. This includes the event title, banner image, date, time, and location, placed at the top of the page. The date and time are highlighted in yellow, which improves readability and acts as a strong signifier. This contrast in color draws allows the user to instantly recognize important and time-sensitive details.
Below the main event information are buttons to save, play, share, like, or dislike the event. These buttons use simple, familiar icons paired with action labels. The combination of iconography and text strengthens the affordances of each button, making it obvious what actions are possible. Users do not have to guess what each button does, helping bridge the gap between knowledge in the head and knowledge in the world.
Further down the page is the event description written by the organizer, followed by event policies. This content is visually separated from the main actions, reinforcing a clear conceptual model: high-level details first, and more in-depth information second.
At the bottom of the screen, a simple navigation bar displays the lowest ticket price along with a bright yellow “Get Tickets” button. The color contrast and fixed placement of the navigation bar act as strong signifiers, communicating the next step in the flow. When the user taps “Get Tickets,” the page expands to show ticket tiers, such as General Admission and VIP, each with different price points.
After checkout, users are taken to a completion screen confirming their purchase. This provides clear feedback, helping close the Gulf of Evaluation by making it obvious that the action was successful.
One issue in this flow is the price displayed on the initial event page. The app shows the lowest possible ticket price, even when that ticket tier is sold out. This creates a mismatch between user expectations and system behavior. For example, an event may initially display a price of $50.89, but after tapping “Get Tickets,” the lowest available option is actually $90.64.
A better solution would be to display the lowest available ticket price on the intial event page. Sold-out prices could still be shown within the ticket tiers, but the initial price would better align with user expectations, improving trust and understanding of the interface.
Sending a ticket to a friend
One of DICE’s strongest features is how easy it is to send a ticket to a friend. After purchasing a ticket, you can tap into the ticket details and view the “Send ticket to a friend” button placed directly below the ticket banner. From there, you’re taken to a search page where friends you’ve previously interacted with on DICE appear. You can also search your full contact list in the search bar since the app is connected to your phone contacts.
The experience becomes complicated when the recipient doesn’t have a DICE account. In that case, a popup appears asking you to invite your friend to register before sending the ticket. This shifts the task from sending a ticket to managing someone else’s onboarding, widening the Gulf of Execution. The app’s response no longer matches the user’s expectation either, increasing the Gulf of Evaluation.
A better solution would be allowing users to send tickets as a shareable link via text. The ticket would still be reserved for that friend, but they could download the app and create an account on their own time, with the ticket automatically appearing once registration is complete. This approach reduces friction for the sender.
Conclusion
Overall, DICE does a great job at providing users with clear signifiers, intuitive affordances, and consistent mapping. Key actions are highly discoverable, and the interface clearly communicates what is possible at each step. However, small issues such as pricing clarity and ticket sharing introduce more friction and could be improved upon.