This document provides details on the design of a mobile app and dashboard to support an expedition to the North Pole. The mobile app will allow explorers to upload biometric data collected from Microsoft Bands to generate donations for charity. A dashboard will engage potential donors by displaying the explorers' biometric data and social media updates. The document outlines user requirements, personas, sketches of the proposed designs, and how the designs meet usability principles and the client's needs.

1. MSc Computer Science
COMPGC02 - Apps Design, January 2016
Team 18 - Client: Microsoft UK
Marco Greselin, Chantal Marin, Lukmaan Kolia
The Band to the Pole
HCI Report1
1
This HCI Report has been edited in November 2015. The final design choices of our app are discussed
in the main technical report. In particular, we have decided not to develop an uploader and use the
Microsoft Health app to do the tasks of storing data in the cloud.

2. App Description
The Band to the Pole is our effort to create a unique experience for users at home to follow the
expedition of James Redden and Laura Lassen to the North Pole in April 2016. The expedition has two
goals: to generate donations for three selected charities, and to gather physiological data during the
expedition for future scientific research.
This project will produce separate solutions which will address each of the goals. To increase
engagement of potential donors, a mobile-first interactive dashboard which pulls data from the
Microsoft Band will be produced. The dashboard will have social media elements, allowing interactions
to share and participate.
A simple Windows Phone app will also be created to allow the expedition team to store data from the
Microsoft Band and upload to the cloud, allowing future analysis of biometric data at these extreme
conditions.
Users Goals And General Context
The process we adopted to define potential users was carried out after a thorough analysis of the
fundamental reasons of our consultancy to Microsoft. MS goal was to identify how Microsoft Band can
be used as part of the expedition.
Our initial brainstorming focused on creating an app that would help the explorers while they are at the
North Pole. Using sensor data as well as the Band vibration mechanism, we thought of ways to send
alarms in the event of certain metrics (e.g. heart rate) deviated from the norm. This avenue, however,
proved unsuitable for several reasons:
- Temperatures at the North Pole reach -40​O​
C. As the Band stops working at -10​O​
C, interaction
with the Band whilst outside had to be avoided. The device should be kept under the jacket at all
times.
- The two explorers would remain close to each other during the entire journey. Features such as
us of microphones to communicate would have proved arbitrary in this scenario.
- The explorers will be equipped with a satellite phone. The smartphone they bring with them
(which connects to the Band) will not have data connection except at night when they set camp.
- Equipment such as gloves and several layers of clothing would prevent interaction with mobile
devices whilst outside.
- We wanted to do something that could be used effectively and help our client, not merely a
demo of all features of the Band used in normal conditions.
- The key reason of the expedition is to generate funding for chosen charities. Using this as a
starting point would capture additional elements which would not have been considered.
In light of the above considerations, we changed our perspective and thought about the core reason for
the expedition. We decided to help our client collect money for charity using Microsoft Band as a way to
engage users at home. This group has been identified as Potential Donors. We presented our idea to the
client: create a mobile-first web page that acts as a cockpit to follow the expedition every day, pulling
data from MS Health and the MS Band. We think of this as an experience rather than a dashboard.
One of the challenges was to ensure data presented on the dashboard had purpose. As the targeted
audience for the dashboard is the average user at home, a simple but engaging combination was
2

3. identified through a screening process of the sensors available. The dashboard will also be enriched
with UGC from Twitter and Facebook and the explorers will be able to interact with the visitors.
The dashboard needs to be populated with data. However, MS Health (the out-of-the-box solution used
to store data from the Band) is not sufficient as it only provides data for selected metrics. A simple
uploader that stores the data locally on the phone for the entire day, which then allows the explorers to
upload the data at the end of the day when the explorers have internet access, would address the data
requirement issue.
As a result, two solutions will be built:
- A mobile-first web experience to engage potential donors using biometric data and social media
integration.
- An uploader for the explorers that collects data from the band and allows upload of data once a
day when they have internet connection.
The two users we identified have different needs and expectations:
- Potential Donors
- Look for engagement.
- Reach from various devices.
- Are curious about the story.
- Technical expertise is not required.
- Explorers
- Have limited time available to upload the data.
- Have limited resources (low access to the internet etc.).
- Cannot use the smartphone and the band while outside.
Our goal is to drive donations for the charities and we can easily measure the success of our application
in through two metrics:
onverted visits C = total number of unique visitors to our site
number of unique visitors directed from our site to the donation page
hare of contribution S = Donations generated from all sources
Donations generated from traffic from our site
3

4. Storyboard
In an effort to translate the above general context, we present a storyboard that represent the data
journey from conception to consumption and conversion.
1. The explorer is outside, no internet connection is available.
2. The explorer reaches a base camp at night and is able to upload the data to our server using our
uploader on his phone.
3. We retrieve data from MS Health and process it.
4. Our mobile-first app creates charts with the processed data.
5. Visitors are engaged and read through our website.
6. Visitors decide to make a donation to supported charities.
4

5. Personas
Personas are fictional characters that represent the various needs, goals, and observed behavior
patterns among our real and potential customers. In order to help us understand our customers better
we decided to carry on an extensive analysis. We discovered during our research that two personas were
necessary for this project.
The first persona is what we call the explorer. The explorer represents the user that uploads the data to
the website and basically an essential element without who this project would not be possible.
The other is the Potential Donor. This other persona represents the user that is the one that will be doing
the donation which responds to the goal of the project itself.
The Explorer The Potential Donor
Neil is 52 years that lives in Dubai and used to
work as a Finance Director before he retired.
Having taken part in several sports in school and
college, and being an avid hiker in his young adult
life, Neil has always had an affinity to the
outdoors. An expedition to the North Pole would
be his next big challenge.
Drawing on his experience, Neil sees the
potential in wearables (such as the Microsoft
Band) as they are able to monitor physiological
variables. Having been accompanied by a doctor
in his previous expeditions, using the data
gathered would have enabled the doctor to more
efficiently monitor the team members’ health and
take appropriate precautions. Visualization of the
data would help to see the data effectively as
opposed to have a collection of numbers.
Our app would allow visualization of the data and
to share it with his doctor at the end of the trip.
Lucy is 25 year old lives in London and works at a
local tech shop. Being tech savvy, Lucy keeps
herself up to date with the tech field via several
tech-focused news platforms. Though having
graduated from a non-tech field, Lucy is
proficient with computer hardware and has built
several workstations. She has also dedicated
time toward several charities.
Lucy is really interested in helping some charities
and has been looking into the different initiatives
happening at the ment. An article on a team of
explorers trekking 200 km to the North Pole for
charity caught Lucy’s attention, particularly as the
team intended on using the new Microsoft Band
2 to capture physiological data.
Our app would allow Lucy to directly follow the
expedition from home via an online dashboard,
making the experience more engaging compared
to previous excursions with only intermittent
Twitter updates.
5

6. User Requirements
In our analysis we are considering two separate products: the first is an uploader that allows the
explorers to send data to a server every time they have internet connection, while storing it locally when
they are outside. The second is a website (or a an app) that creates a rich experience for potential
donors. This enhanced engagement would result in more conversions visitors / donors. We will analyse
the requirements for both solutions in this section.
End user: Explorers, Solution: Uploader
Number 1
Type Functional
Description Pair phone app to the Microsoft Band and establish connection
Rationale Vital in order to exchange information between the Band and the phone.
Number 2
Type Functional
Description Store captured data locally
Rationale Explorers will only have access to the internet once a day, requiring local storage
until internet access is available.
Number 3
Type Functional
Description Ability to upload data to remote storage
Rationale There is a high data loss risk due to the nature of the expedition. Being able to
upload the data to a safe storage when there is internet access minimises this
risk.
Number 4
Type Functional
Description App able to pair and establish connection with more than one band
Rationale Though not a priority to implement, this would further minimise hardware failure
risks.
6

7. Number 5
Type Non-functional
Description Create minimal features with larger-than-normal user interface elements
Rationale App will only be used at night whilst camped, with the larger UI elements
facilitating navigation with cold fingers.
End user: Fundraisers/Potential Donors, Solution: Dashboard
Number 1
Type Functional
Description Dashboard showing overviews of key data gathered
Rationale To engage the fundraisers and general public into the expedition, and provide a
platform conducive to gathering donations.
Number 2
Type Functional
Description Daily Twitter update with key overviews
Rationale To also engage the fundraisers and general public, with an additional purpose of
directing traffic to the dashboard.
Number 3
Type Non-Functional
Description Data must be correctly represented graphically in the dashboard
Rationale Must represent the data correctly.
Number 4
Type Functional
Description Provide a link to the donation pages
Rationale The online dashboard is built with generating additional donations as a key
motivation. Providing links to the charities streamlines the process.
7

8. Sketches
Hereafter, we collected some sketches both for the mobile uploader app as well as for the dashboarding
website. The website uses responsive design features. It is, therefore, the same exact site that looks
different depending on what device tries to access it.
User Interface: Metro UI
The first developments of a new visual language for Microsoft dates back in 2005 with the introduction
of Microsoft XP Media Center Edition and a year after with the MP3 player Microsoft Zune. The
principles behind this language is to put forward the typography and the content rather than the UI
8

9. chrome. However, the real introduction of Metro UI (later renamed Modern UI) is set with the launch of
Windows 8.
J. R. Geigy A.G.
Grid System for Swiss Design
Microsoft Zune, 2006
Four principles can be identified for this design language :2
- Typography​: sans-serif typography is used and in particular
the font Segoe UI. This removes any clutter for the user and
feels clean and minimalistic yet professional.
- Motion​: an example can be identified in the new animations
when opening the start menu on Windows 8 as opposed to
previous versions of Windows.
- Content​: Removal of chrome from the UI leaving full space
to the content. On the Zune we could see the album picture
taking 80% of the screen.
- Minimalism​: removing any form of ornamentation.
This concepts are highly influenced by the so called Swiss style, a
graphic design style dating back in the 1950s, initially developed in
Switzerland and that quickly spread across Western and Eastern
Europe (particularly in Russia). Fonts are consistently “sans serif” as
they are believed to express the “spirit of a more progressive age” .3
Photography is objective and not influenced by propaganda
attributes.
We will use these principles while developing our apps. They can be
translated as follow:
- The map representing the position of the explorer should
take full height of the screen and have as little clutter as
possible. It should be bicolor and so that the focus is on the
actual position marker rather than on the streets or other
names.
- The dashboard should have animations when the page
loads. Static images should be avoided.
- We should use sans serif fonts and possibly Segoe UI.
- We should prefer simple colors as opposed to complex
graphics.
- We should allow empty spaces to avoid clutter.
- We should focus on organisation of content in particular
adopting a grid system.
2
http://archive.is/UEoe#selection-305.6-305.105
3
​Meggs, P. B., Purvis, A. W., & Meggs, P. B.. ​Meggs' History of Graphic Design. John Wiley & Sons,
Inc., 2006, p. 356.
9

10. Meeting Norman’s Design Principles4
Uploader Dashboard
Visibility Most of the functions available can be
accessed directly from the screen, with
only 3 touches needed to navigate from
the home screen to executing a
functional requirement.
The dashboard will have 4 containers,
each displayed with a header and
summary data, with an interactable
element which will allow the user to
expand the container to display additional
information. This allows the user to
choose what they want to see more of.
Feedback 1. Newly paired bands will display in
the paired bands menu.
2. Confirmation popup and an updated
status icon next to Band(s) when
data capture is active.
3. Additionally, all buttons will animate
when pressed.
1. The containers will expand upon
clicking the expand element.
2. Hovering over certain elements would
display additional data
3. Confirmation text once they are
logged in and have shared or have
commented.
4. Buttons animate when pressed.
Constraints The application only contains essential
features, with only the skeletal
mapping determining which options
can be accessed.The only constraint
present is the blurring out of
forward-moving options until a
minimum set of required interactions
have taken place on the current page.
As the user is constrained to interacting
with the containers and certain elements
within the containers, users are only
capable of intended interactions.
Mapping All interactable objects will be clearly
labelled.
All interactable objects will be clearly
labelled, and will make use of only mouse
clicks/screen touches.
Consistency 1. The ‘HOME’ button is always in the
top left corner. The left side is
naturally associated with going
backwards, with the top corner
chosen as this makes the button
explicit.
2. Buttons performing a function are
located on the bottom right, as the
right side is associated with going
forwards.
1. The same element will be used to
expand the various containers.
2. Charts which present the data will
have the same theme.
Affordance There are two types of interactions:
buttons and checkboxes. These are
commonplace and intuitive, with button
edge gradient giving the impression of
a raised platform inviting users to
press it.
The interactable elements will be intuitive:
● The expand element will be a
double-headed arrow icon, providing
a clue to its function.
4
Donald A. Norman, ​The Design of Everyday Things​, 1988
10

11. Meeting Client Requirements
Data App
Five key functional requirements were identified in order to meet the list of requirements from the client.
This can be further broken down into two groups; those addressing the setup and management of the
Microsoft Bands and those responsible for data management. As a result, the app differentiates the two
streams on its homepage.
In the Data Manager stream, the three options displayed encompass all data-related functional
requirements, and these are displayed in sequential order. Each option has a further landing page from
which executing the two commands is a button away, after capturing the necessary configuration
options from the user. The Band-related requirements are addressed by the Band Manager in a similar
fashion.
Keeping the number of clicks/taps to a minimum whilst also providing a coherent mapping of functions
was a key motivation during the designing process of the data app. This simplistic approach was taken
because interaction with the app will only occur whilst camped. The buttons are also larger, with as less
text on screen as possible. Though not apparent in the grayscale sketches, pastel colours will be used
for the menus to contrast the darker environment.
Dashboard
The desktop dashboard was designed with two key motivations; displaying summaries of key metrics of
the explorers, and using the interest generated from this to direct traffic to a donation page.
The dashboard is organised into 4 containers: A map displaying location of explorers with
distance-related metrics, charts for heart rate, charts for calories, and an area for social media
interaction.
To capture the audience, giving users the ability to interact with elements on the dashboard is
paramount. The dashboard will contain several interactable elements:
1. Hovering the cursor over of the current location of the explorers on the map would provide
additional information on distance/geographical metrics.
2. A drop down menu will isolate data for the individual explorers.
3. The social media container will include all social media buttons and a link to the donation page.
The link to the donation page is located immediately under the social media buttons to reinforce
the idea of donating as the next logical step after sharing using social media.
11

12. Evaluation
Method
The online dashboard was evaluated with a lab study, where participants were asked to view the website
on various devices. A lab study was used as opposed to an heuristic approach as the product is a
website, with the only interactable elements being a ‘Donate’ button and the Twitter API. As a result, the
elements being evaluated are the aesthetics and the likelihood of a user donating to one of the charities.
Live users were used as this would bring a ‘fresh’ set of eyes, able to evaluate the visual appeal without
any bias.
Results
The evaluation was carried out by first getting the group of users to visit the blog owned by the
explorers. After this, users were asked to visit the online dashboard and after scrolling through the page,
fill out a questionnaire. The goal of the questionnaire was to:
1. Assess the aesthetics of the dashboard. The design should be visually engaging.
2. Assess the likelihood of visitors using social media to share the website.
3. Assess the effectiveness of directing traffic from the dashboard to the donation page.
To collect data on the above, the questionnaire consisted of three questions, each addressing a point
above.
1. Rate the aesthetics of the website (colour theme, layout, amount of information)
2. How likely are you to use Twitter to share the dashboard?
3. How likely were you to donate before visiting the online dashboard?
4. How likely are you to donate to one of the charities after having visited the online dashboard?
The results are given in the table below, with 1 being least like and 5 being very likely. There was also
opportunity for additional comments, which are discussed below.
Question 1 Question 2 Question 3 Question 4
User 1 5 4 1 3
User 2 4 5 2 2
User 3 4 4 1 2
By splitting the likelihood of donating into before and after, the effect the online dashboard has on a user
is isolated from their default tendency towards donations. The results showed that users were more
likely to donate after having visited the website, as users felt more engaged with the journey.
12

13. Presentation Template
James and Anita are ​two passionate explorers that will go to the north Pole in April
2016. They contacted Microsoft to get some technical help and sponsorship for their
expedition. Our mission is to use data from the ​Microsoft Band 2 and Microsoft
Health​platform to help James and Anita.
What
We designed a ​mobile-first web experience to follow the expedition from home
leveraging biometric data from the Band. This will be enriched with social media
engagement and interaction.
To face technical challenges from the extreme conditions (e.g. no internet
connection except when they are in the Base Camps, very low temperatures etc.)
we will build a simple ​uploader that stores the data to the phone for the whole day
and pulls it to the cloud at night. This will be designed for Windows Phone using
the ​Band API​.
Why
We believe this will help James and Anita achieve their primary goal: collect money
for the charity they support. By engaging every day with the biometric data, users
will feel more part of the adventure, they will become returning visitors to our web
app and eventually ​convert into donors​. This user journey provides a highly
measureable impact.
Who
We will build two solutions to achieve our goal: an uploader that saves data to our
server once a day when internet connection is available and an app showing the
data on the web. Therefore, we target:
1. The explorers who need an ​easy and quick UI that allows them to upload
the data on the go with our mobile app.
2. The potential donors who look for engagement and need to have a
consistent experience​regardless of the device they are using.
How
Our mobile-first ​interactive dashboard will be making use of HTML5+CSS3 and
pulling data from Microsoft Health and Azure. We want the experience to be
consistent across different platforms​, engaging (making use of animations when
necessary) and beautiful. It will not be an analytics site. Rather, it will be an
enriching experience through a simple and intuitive user interface.
13