Repository navigation
MS6
ParkWise offers students and users of Universidad de los Andes parking facilities a faster, more informed, and reliable way to find and manage parking spaces. The app combines real time availability data, occupancy forecasting, space reservation, and navigation to available spots, allowing users to stay informed about parking conditions both before and during their arrival.
In this way, ParkWise aims to reduce uncertainty, time wasted in lines, and the difficulty of finding a spot, providing a more convenient and predictable parking experience. It also addresses specific needs, such as locating spaces for electric vehicles or individuals with reduced mobility.
Every colour in ParkWise carries a specific semantic meaning. Colour is never applied for decoration alone: if a colour appears on screen, it is because it communicates state, hierarchy or interactivity.
| Role | Token | Hex | Usage |
|---|---|---|---|
| Primary | Blue 700 | #0052CC |
Primary actions, active states, links |
| Blue 500 | #0065FF |
Hover state on primary elements | |
| Blue 100 | #DEEBFF |
Selected chips, tinted backgrounds | |
| Success | Green | #36B37E |
Available spots, confirmed reservations |
| Warning | Amber | #FFAB00 |
Low availability (< 5 spots), stale or cached data |
| Danger | Red | #DE350B |
Full levels, destructive actions |
| Secondary | Purple | #6554C0 |
Find my car flow |
| Surface | Page | #F4F5F7 |
Page background |
| Card | #FFFFFF |
Cards and sheets | |
| Border | #EBECF0 |
1px separators and card outlines |
| Colour | Why this meaning |
|---|---|
| Blue | Communicates interactivity and trust. It is the universal language of clickable, primary actions, so the user never has to guess what is tappable. |
| Green | Availability. The driver's eye is already trained to read green as "go", which lets a full parking grid be scanned without reading a single label. |
| Amber | Caution without alarm. Used for low availability and for data that may be stale, two states that require attention but are not failures. |
| Red | Reserved strictly for full levels and destructive states. It is never used for non-critical UI chrome, so that when red appears it always means the same thing. |
| Purple | A controlled secondary accent for the Find my car flow, visually distinct from the primary blue so the user can tell a wayfinding task from a booking task. |
All text-on-background combinations meet the WCAG AA minimum of 4.5:1. Blue text (#0052CC) on white reaches 7.0:1.
State is not conveyed by colour alone. Status badges pair the tinted background with an icon and a text label, so a user with colour vision deficiency reads the same information from the shape and the wording.
The first version of the prototype used a dark navy ground throughout. After the design review, we moved to a light ground (#F4F5F7), which improves legibility in daylight, the environment where most sessions occur. An earlier glassmorphism exploration was also produced and discarded for the same reason: heavy translucency reduced the contrast of the status colours, which are the most functionally important element of the interface.
This change is a direct application of the prototyping cycle described in the course material: prototyping is not a phase but a loop, and even a version the team considers finished should be reviewed.
Two typefaces. Inter for all UI text, DM Mono reserved for machine-readable data.
| Typeface | Role | Weights | Usage |
|---|---|---|---|
| Inter | Primary | 400 / 500 / 600 / 700 | All UI labels, headings, body copy, buttons, captions, navigation |
| DM Mono | Data | 400 / 500 | Spot codes (B201), countdowns (12:47), cache timestamps |
| Style | Size | Weight | Usage |
|---|---|---|---|
| Display | 20px | 700 | Screen titles, page headings |
| Heading 1 | 15px | 600 | Section titles, card headings |
| Heading 2 | 14px | 600 | List item labels, sub-section titles |
| Body | 13px | 400 | Descriptive text, paragraphs |
| Caption | 12px | 500 | Secondary info, metadata, sub-labels |
| Overline | 11px | 600 | Section labels (all-caps), category tags |
| Mono — ID | 13px | 500 | Spot codes: B201, A103 |
| Mono — Data | 12px | 400 | Cache timestamps, distance labels |
Inter's neutral grotesque voice disappears behind the content: it never competes with the functional information the user came for.
DM Mono creates instant visual separation for machine-readable codes. A user scanning a parking grid reads B201 as a unique identifier rather than as a word, and the fixed width keeps countdowns and timestamps from shifting as digits change.
Lucide-style outlined icons at 20×20, 1.8px stroke, round caps and joins. No filled icons except semantic status shapes.
| Icon | Usage |
|---|---|
| Home, Map, Reserve, Profile | Bottom navigation tabs |
| Search | Find a Spot search bar |
| Car | Find my Car, map entrance marker |
| Check | Reservation confirmed, compliance ✓ |
| Cross | Dismiss sheet, compliance ✗ |
| Info | Best-time-to-reserve tip |
| Chevron | Level card drill-down affordance |
| Wifi off | Offline screen banner |
| Refresh | Retry connection button |
| Zap | Electric vehicle spot |
| Accessibility | Reduced-mobility spot |
- Icons appear without labels only when the meaning is unambiguous: navigation tabs and dismiss actions.
- Icons are paired with text in quick-action buttons and status rows to eliminate ambiguity.
- Colour follows context: blue icons on interactive elements, semantic colour inside status badges.
- Icons are never decorative. Every icon earns its place by reducing the word count.
One icon family is used across the entire app. Mixing outlined and filled sets, or mixing icon libraries between sections, is treated as an inconsistency rather than a stylistic choice.
This version uses no photography. The parking floor map is rendered as an inline SVG with semantic fills so that it remains legible at small sizes and works without an image CDN, which matters because levels P2 and P3 have no connectivity.
| Rule | Value |
|---|---|
| Spacing grid | 8px base, 4px for tight pairings |
| Minimum touch target | 48×48px |
| Card radius | 8px |
| Badge radius | 3px |
| Card border | 1px #EBECF0
|
| Page padding | 16px horizontal |
Depth is created through the card-and-surface hierarchy rather than through shadows: white cards on a light gray page, separated by 1px borders. This keeps the interface flat and legible under direct sunlight, where shadows read poorly.
ParkWise follows an Atlassian-inspired design system rather than adopting Material Design or the Human Interface Guidelines directly.
The course material notes that design systems are not exclusive to operating systems: companies such as IBM, Decathlon and Airbnb maintain their own to express their brand identity. We chose an enterprise-style system for three reasons.
Functional colour semantics. Atlassian's system assigns a fixed meaning to each colour token and forbids decorative use. ParkWise is a status-driven product where the user's entire decision rests on reading a state correctly, so a system built around semantic colour fits the problem better than one built around brand expression.
Density and data legibility. The interface presents counts, codes, timings and percentages simultaneously. Enterprise design systems are optimised for exactly this kind of information density.
Cross-platform neutrality. Our implementation target is Flutter, which renders its own widgets rather than delegating to the native toolkits. A platform-neutral system avoids the inconsistency of applying Material conventions on iOS.
Known trade-off. The card component, central to our layout, does not exist in the iOS design system. Where the app runs on iOS, the card is implemented as a custom component following HIG spacing and typography conventions rather than being carried over unchanged from Material.
The final version of the prototype was developed using Figma Make, following an Atlassian-inspired design approach.
🔗 View the final prototype in Figma
The prototype covers seven screens spanning the complete parking journey, from pre-trip prediction to post-park car retrieval.
| # | Screen | Content |
|---|---|---|
| 1 | Home | Occupancy forecast, level cards, quick actions |
| 2 | P1 · North | Interactive spot grid with bottom-sheet selection |
| 3 | Find a Spot | Search, filters and results list |
| 4 | Reserve | Countdown ring and compliance history |
| 5 | No Campus Spots | External lots and notify-me CTA |
| 6 | Find My Car | SVG floor map, route toggle and walking steps |
| 7 | Offline | Cached data, saved reservation and retry |
| Screen 1 | Screen 2 |
|---|---|
 |
 |
| Screen 3 | Screen 4 |
|---|---|
 |
 |
| Screen 5 | Screen 6 |
|---|---|
 |
 |
| Screen 7 |
|---|
 |
🔗 View the glassmorphism prototype in Figma
This version was produced earlier in the process and discarded: the translucency reduced the contrast of the status colours, which carry the most functionally important information in the interface. It is kept here as evidence of the design iteration described in the colour section.
🔗 View the skewmorphism protoype in Figma
This version was produced earlier in the process and discarded: the colors and general feeling of the interface weren't approved by the team members and disliked by close testers. It is kept here as evidence of the design iteration described in the colour section.
Light ground. Switching from dark navy to #F4F5F7 improves legibility in daylight, the primary usage environment for a parking app used while walking to a car.
Card-and-surface hierarchy. White cards on a light gray page with 1px borders create depth without shadows.
Semantic status badges. Tight 3px-radius pills with tinted backgrounds replace glowing coloured text. Badges communicate state at a glance without requiring the user to read the number.
Countdown ring. The SVG arc on the Reserve screen uses an animated stroke-dasharray. The ring colour shifts from blue to amber to red as time runs low, encoding urgency without additional UI.
Consistent icon set. Navigation and status icons use a single SVG family with the same stroke width and viewBox across every screen.
Four patterns, each chosen to reduce orientation cost and keep the user in flow.
| From | To | Trigger |
|---|---|---|
| Home | P1 · Map | Tap level card |
| P1 · Map | Reserve | Select spot → Reserve CTA in sheet |
| Home | Find a Spot | Quick action |
| Find a Spot | Reserve | Tap Reserve on a result |
| Home | No Campus Spots | When all levels are full |
| Home | Find My Car | Quick action |
| Any screen | Offline | Signal lost, graceful degradation |
1 · Bottom tab bar. Four persistent tabs (Home · Map · Reserve · Profile). The active state uses a 2px blue top indicator; inactive tabs use mid-gray. Navigation is always visible and never hides behind content.
Rationale: the bottom bar keeps primary destinations within thumb reach on a mobile form factor. Four items sits at the upper end of the 3-to-5 range recommended for a navigation bar, beyond which cognitive cost rises.
2 · Frame-level push navigation. Tapping a level card, a spot, or a search result pushes the target screen. The back affordance is the bottom navigation tab or an explicit back button in the header.
Rationale: linear push keeps context intact. The user always knows where they came from and can retrace their steps without losing state.
3 · Bottom sheet (modal overlay). Selecting a spot on the level map surfaces a bottom sheet with the spot ID, walk time and a Reserve CTA, without leaving the map. A drag handle and a dismiss control close it.
Rationale: bottom sheets preserve spatial context. The user can dismiss and re-select without losing their place in the grid, which matters when comparing several spots.
4 · Conditional flows. If all campus levels are full, the app bypasses the normal reserve flow and routes to No Campus Spots. If signal is lost, screens degrade to Offline with cached data.
Rationale: anticipating failure states reduces friction. The user is never left on a dead-end screen; there is always a next action available.
5 · Sticky header with scrollable content. Each screen keeps its title, filters and legends in a fixed white header with a 1px bottom border. Only the content area scrolls beneath it.
Rationale: preserves orientation at any scroll depth. The user always knows which screen they are on and which controls are available.