1. Background

The goal was to create a mobile-first approach to providing donor centre and mobile drive location search, booking management tools, and insightful donor status and tracking information as well as create a targeted channel for direct, real-time communication with donors

My design process involved running and facilitating a series of design workshops upfront with the client and their customers to understand the problems and issues with booking an appointment today with NZ Blood service. Then spending the time to wireframe and explore design concepts, which later be using for user-testing. From there, we worked closely with the development team and stakeholders within agile product life cycle, to design and build features and slowly building out the solution.

The concept of the solution was to create an experience that invites users to search and discover donor locations and time availability that will fit their busy schedules, turning what was a tedious task, and streamlining it into a simple effortless flow.

‍

2. My Role

• Lead Designer
• Coordinate and facilitated the design workshops
• Product strategy & feature prioritisation
• UX / UI design (Managed workload with another mid-level designer who came onboard in 2nd Sprint from my team)

‍

3. Design process overview

We stay one sprint ahead of the rest of the product team so that we would have the designs in the current sprint finalised before development begins. While developers work on Sprint 1, designers move ahead to work on features from Sprint 2.

‍

4. Research & stakeholder workshop

What we did in the workshop?

1. Background

• Outlined the schedule for the workshop.
• Brief introduction of the NZ Blood and their business objectives.

2. Situation Analysis

• Client walked through the existing hybrid mobile application and web platform and review feedback gathered through the various channels by the NZ Blood team.
• Reviewed the current business and customer processes for blood donation.
• Identified gaps in the technology, people, business, policies and constraints between current and desired state.

3. Feature Mapping

Blue sky thinking, What is the ideal blood donation application. Ranging from core features that must be in the MVP release, to features that are only feasible in the long term.

4. Personas

Identified personas that will represent the different types of users that will engage with the NZ Blood mobile application.

5. User Journey Mapping

Identified different user journeys to draw out the points of interactions and opportunities to add new features and value. Eg: Different states of the home screen for different scenarios.

‍

5. Design Goals and Challenges

Key Challenges

• Due to frustration with booking in the website or the app, the user would instead call the contact centre for booking, rescheduling or cancelling appointments, causing increase in call centre volume.
• Users preferred text message reminders over calendar or email reminders. However, SMS gateway was a costly service to maintain.
• Website user would migrate to the app if the user experience was improved, because of convenience.
• Users don't  keep their donor ID card with them, resulting in longer appointment with the nurse
• Too many barriers before user can ever see if appointment slots are suitable to them.

Design Goals

• A smarter mobile-centric donor, for whole blood and plasma.
• Replace the existing HTML web apps that has sufferred from limited performance and major UX issues
• Provide users with donor centres, location search, booking management and insightful donor stats and user blood profile information
• Targeted channel for direct and real-time communication with users.
• Relaunch IOS & Android app by World Blood Donor day 2016 (6 months away)
• Improve mobile app user experience

‍

6. Requirements and User Stories

Writing user stories before diving into design.

• Allow the team to weigh in on the technical complexity, business driver and return of investment & prioritise the backlog.
• Priority of order of features to design first for MVP
• Use for estimation
• Easily changed as project progress, to align design with requirements

7. Site Mapping

• Site mapping is the first attempt at brainstorming the information architecture.
• Used to capture functionalities, interfaces, navigation hierarchy & content type and gain a quick overview of the entire application without diving into sketches or wireframes at the early stage.

‍

8. Design Iteration

• The home screen is the place where all your most relevant content and latest news is aggregrated together.  It is also the first screen a user sees when they launch the app.
• Feature consideration: News Banner, Latest appointment, Blood profile, helpful tips

‍

9. UX Process

From sketch to design tool to prototyping.

1. ‍Hard sketch first to flesh out concepts at high level and narrow down on viable ideas.
2. Wire-framing in Sketch or Adobe Illustrator.
3. Prototype built in flinto - https://www.flinto.com/p/cb8898b0

‍

10. Integrating the Brand

The New Zealand Blood Service logo has been designed to be recognisable and approachable – at a range of sizes – even when quickly glimpsed.

The vivid sharp red used in conjunction with the dark green tone represents the importance of blood and the importance of giving blood. These simple and versatile colours make it easier to ensure consistency when designing the app.

‍

• We convinced the client to use San Francisco as the primary IOS typography and Roboto for Android.
• Elaborating on the advantages of using a native system font over custom font, as we’ve had Kern / line-height issues before using web fonts on native

‍

11. Visual Design

• Brand colours: red, green, and white, Red reserved for active and actionable items
• Font weights used to identify visual heriachy
• Flat graphic used to align with existing graphics from the branding guidelines. 
• Implemented a “Scroll to fill” navigation bar, to ensure “Login” or “Book “ is shown at all times (See Link)

• See locations list view (Top right), the icon went through a few iterations, one concern was that non-NZers won’t recognise it. However, after some ad hoc UX testing, most users understood what is represented.
• Low contrast box shadows used to provide depth to the key information, and seperate the tab bar from the content. 

‍

12. Working with developers

Designing for Development.

‍

• Specifications act as the blueprints that outlines the colour, components and typography styles used in the application.
• Annonation of dimensions and notes explaining layout and responsive constraints, and any other non-functional requirements .
• In the last 6 months, we have moved design specs into Zeplin.io for better collaboration.

‍

13. Feedback and product roadmap

Feedback

• Seven-fold increase in self-scheduled appointments.
• 24,000 active users on iOS and Android.
• 5,600+ bookings through the apps.
• 500,000+ screen views, 85,000 active sessions. Average 2.5 minutes on the app.
• 4.5/5 rating on both iOS App store and Android Play store.
• Positive users voicing their opinion and engaging with the NZ Blood Service on social media.

What’s next?

• Rebuilding the existing web experience following mobile success
• Phase 2 for mobile apps
• Increase notification types
• Target specific user segment for push notifications (Eg: Users with certain blood type)
• Improve UI for sharing “Your blood has been used” notifications

14. Retrospective

Obstacles & Issues

• Not enough opportunities to conduct user testing, mainly channelled to user through the stakeholders and then provided us feedback.
• We had a fix schedule deadline, thus meant that features had to cut and design had to be simplified for MVP.
• The backend was designed before the design process began, thus limiting us to designing layout & experiences based on the structure of the APIs. 
• API team was remote & client based, so communication was sometimes difficult with misunderstanding. 

What would I have done differently

• Push harder for impactful features. Eg: Personalised push notifications, Notification centre, Facebook login (due to the younger demographic)
• Our location: Have list view and map collate with other (Currently, two completely separate user journeys to browse for locations )
• Engage with the backend team earlier to explore what data can be shown through API calls.