phoenix
phoenixPhoenix - Your AI Assistant
Inactive session will be ended in 24 hours
End Session

UI/UX redesign — Digi-Badge holder app + emails (Figma)

  • Posted:
  • Proposals: 31
  • Remote
  • #4515360
  • Open for Proposals
Gabriel A.David O.Bisma I.Raj S.Joshua A. + 26 others have already sent a proposal.
  • 4

Description

Experience Level: Expert
Project overview
We need a visual redesign only (no development) for:
1. Digi-Badge Holder app — mobile app for UK Blue Badge holders (register, verify identity, start parking, show QR code, find vehicle, manage account)
2. Transactional emails — password reset, email verification, photo approved/rejected
Brand reference: https://digi-badge.co.uk/
Match the professional, trustworthy, public-service tone of the marketing site. Credible and clear — not playful or startup-y.
Design only. Our in-house team builds the app in code later. You are not coding MAUI, XAML, or APIs.
________________________________________
Attached materials
I am attaching:
• ~22 app screenshots (BlueStacks Android emulator, portrait phone)
• 1 screenshot of current password-reset email (plain/unbranded — the “before”)
About the app screenshots:
• Taken on BlueStacks in portrait — this is as large as the app renders on a phone; not cropped or low-res
• Use them as a feature and layout reference, not as design direction
• Current look is functional, not final branding
• Some flows may be missing (maps, camera, payment) — use sensible placeholders if needed
________________________________________
What the app is built in (information only)
• .NET MAUI (Microsoft mobile framework, successor to Xamarin)
• XAML for UI layout
• iOS and Android
You deliver Figma (or equivalent). No MAUI/XAML skills required.
________________________________________
App scope — holder app only
~50 screens in the full product. Screenshots cover the main journeys:
Area Examples
Auth Login, sign up, forgot password, verification codes
Home Welcome / parking hub, active session
Parking Free/paid parking, location, confirmation, session timer
Badge & QR Digital badge view, QR for barriers
Find Map / locate vehicle
Account Profile, vehicles, history, receipts, settings
Verification Photo upload, face check, ID steps
Legal Privacy, terms, help
Do not change:
• 4-tab navigation: Home · QR · Find · Account
• Screen inventory and user flows — refresh look and feel only
• Offline banner must stay obvious when there is no signal
• Light mode for v1 (dark mode optional quote)
Starting colours (you may refine to match digi-badge.co.uk):
• Primary blue: #005BAC
• Page background (current): #89B8E6
________________________________________
Transactional emails (same project)
Emails today are boring plain HTML/text from noreply@mybluebadge.com. Example: password reset is one line of text and a 4-digit code — see attached screenshot.
Redesign these 4 templates (same design system as the app):
# Subject Notes
1 Reset Your Blue Badge Password Large, clear OTP code — many users are elderly
2 Verify Your Email Button to verify — not a raw URL only
3 Photo Approved Short confirmation
4 Blue Badge Photo Rejected Clear reason + what to do next
Email requirements:
• Responsive HTML (600px max, Gmail + Outlook safe)
• Figma mockups and developer-ready HTML with inline CSS
• Shared header/footer (logo, footer links)
• High contrast, large readable type
________________________________________
Audience & accessibility (critical)
Most users are elderly and/or disabled. The design must:
• Large touch targets — minimum ~44–48pt; bigger on primary actions
• WCAG 2.1 AA contrast minimum
• Simple, plain language — no jargon
• Scales with phone system font size — layouts must reflow when users turn up text size (Dynamic Type / Android font scale)
• Screen reader friendly — sensible for VoiceOver and TalkBack: visible labels, don’t rely on colour alone, avoid icon-only buttons without text
________________________________________
Portfolio requirement — must have
Only apply if you can show at least 3 sample screens from past work (mobile app and/or HTML email). Link Figma, Behance, or PDF. No samples = we won’t proceed.
________________________________________
What you must deliver
1. Figma file — mobile frames 390×844
2. All holder app screens
3. 4 email templates — Figma + HTML export
4. Component library — colours, typography, buttons, inputs, tabs, banners
5. Accessibility notes + developer handoff (inspect / dev mode)
6. Assets — SVG or PNG where needed

New Proposal

Login to your account and send a proposal now to get this project.

Log in

Clarification Board Ask a Question

  • David O.

    Hi Jamie,

    Before you make a decision, may I ask one important question about the accessibility requirement?

    For the larger system font sizes, do you already have an accessibility approach or target behaviour defined for the app, or would you like the Figma designs to establish how the screens should reflow at increased text sizes?

    I ask because this affects the layout decisions across almost every screen, especially for the elderly and disabled users you’re designing for.

  • VCONN P.

    Hi Jamie,

    A few questions:

    1. Of the approximately 50 screens, do you already have screenshots/reference layouts for all of them, or will some need to be created from written descriptions of the existing flow?

    2. Do you have an existing Figma/design file or component library, or should we build the new design system entirely from the screenshots and current brand guidelines?

    3. For the transactional emails, will you provide the final wording/rejection reasons, or should improving the content hierarchy and wording also form part of the redesign?

    Looking forward to your reply!

    Jamie H.Yesterday

    Hi,

    Thanks for your questions.

    We have screenshots of the existing app and its current user flow. However, some new or redesigned screens may need to be created from written descriptions, as the purpose is to improve the app rather than simply reproduce it.
    We do not have an existing Figma file or component library. The new design system should be created using the existing screenshots, our branding, and the style of www.digi-badge.co.uk.
    We can provide the required information and specific rejection reasons. However, improving the wording, content hierarchy and presentation should form part of the redesign. Any changes to the meaning will need our approval.

    At this stage, we would like you to provide at least three example screen designs showing your proposed direction for the app. We will use these to select the designer whose approach best matches what we want.

    Thanks,
    Jamie

  • Tafsol Technologies

    -/ For the missing map, camera, payment and verification states, do you have existing requirements/wireframes, or should these be visually designed based on the surrounding flows while keeping functionality unchanged?

    -/ Are there different parking states we should account for, such as free vs paid parking, payment failure, expired/extended sessions, location permission denied, QR failure, offline mode, and no GPS signal?

    -For accessibility, do you want us to provide specific developer annotations for Dynamic Type/font scaling, screen-reader labels, focus order and interaction states, in addition to the visual accessibility notes?

    -/ For the rejected-photo email/app state, will the rejection reason be dynamic, and should users have a direct CTA to upload a replacement photo?

    Jamie H.Yesterday

    Hi,

    Thanks—answers below:

    We have the existing functional flows and can explain the requirements for the map, camera, payment and verification screens. We do not have complete wireframes for every missing state, so these should be visually designed around the surrounding user journey while keeping the agreed functionality unchanged.
    Yes, the designs should account for the relevant states, including:
    Free and paid parking
    Payment successful, pending or failed
    Active, expired and extended sessions
    Location permission denied
    QR/barcode scan failure
    Camera permission denied
    Offline mode and loss of connection
    GPS unavailable or inaccurate
    Verification pending, successful or failed

    We can confirm the exact requirements during the full design stage.

    Accessibility is important. The designs should include developer guidance for font scaling/Dynamic Type, screen-reader labels, logical focus order, colour contrast, touch-target sizes and the relevant interaction/error states.
    Yes, the rejected-photo reason will be dynamic. The email and in-app notification should clearly explain the reason and include a direct CTA allowing the user to take or upload a replacement photograph.

    For this initial selection stage, we are only asking for three representative concept screens. We are not expecting every flow, state or developer annotation to be completed before a designer is selected.