Windows 10 Helpdesk App

A level computer science project with UX design process | C# Windows 10 Universal App | Made with research and testing | Phone and PC compatible

An A level computer science project with a UX process

For my A level computer science final piece, I created a helpdesk app for my school. Initially this was going to be a Windows desktop app which turned into a Windows Phone 8.1 app and then finally released as a Windows 10 Universal App, which although deprecated now, was a new technology at the time. It was exciting because the same app could run on a Windows 10 desktop and a Windows 10 Phone – rather like how a responsive website runs on a phone and a desktop computer with the same code.


In 2016, Wymondham High Academy had:

Graphic of users with laptops, tablets and phones behind them.

Over 700 desktop computers

200 Microsoft Surface tablets

100 laptops

1,700 students

Over 200 staff

3 schools in Wymondham to manage IT for

Meaning that there could be anywhere in the region of 5,000 devices onsite at any one time. With such a high number of devices the tendency for there for be problems is high and if devices go wrong a lot of users can be affected. Therefore, problems need to be reported and attended to quickly by technicians.


In 2016, Wymondham High was using an ‘off-the-shelf’ helpdesk solution called SpiceWorks. Staff would send an email to a specific email address and the email would appear in the SpiceWorks helpdesk. Technicians reported that it was difficult to log tickets in SpiceWorks and that they’d welcome a bespoke system for the following reasons:

‘Multiple schools and sites can’t be assigned in the current solution.’

‘The response to the customer could be updated and the layout of the ticket is very old and cluttered.’

‘The current solution doesn’t work well for teams – if I’m off work, I need somebody to assign my tickets to.’

‘A web-based solution is OK, but when the internet is down the helpdesk can’t be accessed. Local software might work better.’

A group of people graphic.

What teachers said

Talking to teachers (the other user group), the following was said about the current solution:

A group of people graphic.

‘I can’t assign a priority to my ticket. ‘Red’, ‘amber’, ‘green’ or timescales such as ‘urgent’, ‘can be done in the next week’ and so on would help me tell the technicians how important my issue is.’

‘I’d like to know an estimated time of completion and what’s being done – or at least that the ticket has been read. At the moment all I know is that it has been received.’

‘A mobile platform would be useful. The current system isn’t optimised for mobile use and I’d be able to report a problem even if my computer wasn’t working.’

Further information from teachers concluded that:

100% of respondants felt that the helpdesk was essential

50% felt that current solution fulfilled its purpose

33% strongly disagreed that the current solution fulfilled its purpose

50% felt that integrating the helpdesk with their school Office 365 account could be useful

67% felt that it would be useful to be able to assign a priority to their ticket

50% felt that the 'traffic light' priority system would be the easiest for them

67% felt that it would be beneficial to have different sections for the different types of problems

50% felt that it would be helpful to integrate Yammer or Skype (two Office 365 communication tools) into the helpdesk to talk to technicians

67% agreed that a mobile helpdesk app would be beneficial

Graphic of a group of people.


Firstly, I worked with the IT technicians to determine exactly how the helpdesk system works. The diagram below shows that a user signs in, creates a ticket and then doesn't hear anything more unless more information is required. The technician does a lot more, assigning the ticket, carrying out the ticket and closing it. There is not a lot of communication between the user and technician.

The system flow diagram shows how there is little communication between the user and the technician - often their paths never cross.

The initial idea was to create a desktop app that would run on the school’s computers that would allow the users to report issues. However, I was later advised by the IT department that a better idea might be to develop a phone app so that problems could be reported and responded to at multiple sites and also mobile broadband could be used if the internet went down.

The app therefore became a Windows Phone 8.1 app, then development was restarted and it became a Windows 10 Universal App Platform app. At the time, the Universal App Platform (UAP) framework allowed developers to use Visual Studio 2015 to code one C#, Visual Basic, C++ or Java app with a front-end coded in XAML (a markup language with style controls) which could run on any Windows 10 device – phones, tablets and desktop computers included.

App structure diagram which shows the order in which pages are accessed. Generally, the user starts the app, then completes the helpdesk form, then sends the ticket via email (built into the app). Key to the app structure diagram.

The app functionality and flow was considered very carefully based on formative user research. The final structure allowed the user to log into the app using their Office 365 email address and then report a problem by selecting a problem type, room, typing a description, selecting a priority and then sending. The app would then send this ticket to the helpdesk for the technicians to receive.

The visual design was a little restrictive because of guidelines from Microsoft that make most Windows Phone and Windows UAP apps look the same, but the following high-fidelity prototypes were drawn using Adobe Illustrator.

The sign in page features some information about how to sign into the app using your Office 365 email address on top of a field for the user to type their address in. The app's background is black and the foreground white.

The welcome page is mostly basic XAML text fields and default Windows 10 app navbar located at the bottom of the screen.

The helpdesk page is where the user fills in the details. From here the user can select a problem, select a room, write a description, select a priority, attach an image and send a ticket. Most of the interface is button and text fields based, with radio buttons used for the priorities.

The user selects what they want to report and write a short description, before selecting a priority and submitting the ticket.

The Long List Selector makes finding a room easier. The user is able to tap on a letter on the list page, which fills the screen with buttons to quickly navigate to other letters in the list. E.g., tap on 'B' and the list goes to the items beginning in B.

Long lists can be made easier to navigate using XAML's 'Long List Selector' control which allows users to quickly jump to different parts of a list.

Each room in the school is listed in a long list. Underneath each room is a short description.

Each room in the school is in the 'long list' and each has a description underneath it, usually detailing its location within the school.


App code was tested by me with three levels of data: normal, borderline and extreme. This is to test error handling and different use cases.

The app was able to send a ticket to the helpdesk and the technician’s end was able to categorise tickets based on topic.

When the app was almost completed it was given to three technicians and a teacher to test on various low-end Windows 10 phones.


Feedback was generally positive.

‘The email it generates is very succinct and easy to understand.’

‘The camera feature is useful, but it would be better if it attached straight to the ticket.’

‘I like the interface, it’s very clean and modern.’

‘A 200 character maximum description might be too short.’

‘It would be good if I could message the user back.’

‘The priority system may not be used properly – what is urgent to one user might not be that urgent in comparison to other tickets.’

‘Smooth, fluid and easy to use. A stupendous piece of coding.’

‘Do users know that they’d need to tap on a problem type in order to select it?’

A group of people graphic.


The final app is functional. The user can use it to send a ticket to the helpdesk and it is received by the technicians. The other features such as the camera access work too.

The final version of the welcome screen is similar to what was envisaged in the design - white text on a black background and fields.
The helpdesk page in the final version is also similar to what was designed. Buttons that take the users to lists and radio buttons and text fields as other input methods.
The problem page features a list of problems, categorised, that the user can select. The items are in Segoe UI font and red on a black background.
The long list selector is similar to what was designed - big red boxes on the phone screen that the user can tap on to navigate them to certain points in the list.
The room list itself is similar to what was designed. Rooms are in the list and underneath each name is the location of the room in the school and the room's purpose.


The users suggested plenty of changes, starting with a button to remove an attachment once it has been selected. Chats and push notifications were discussed a lot in formative research interviews and formative research and never implemented in my solution. These could be added into the app to allow the technicians to communicate with the users once the ticket has been received.

Chat could be implemented into the app - chats appear in a list just like they do on popular messaging apps such as WhatsApp and Facebook Messenger.
Messages are threaded, with your messages shown in square speech bubbles on the left and the replies in square speech bubbles on the left.
Messages could appear in push notifications, shown here in the Windows Phone Action Centre.

Another suggestion was to use a light grey background instead of a black background on the app. The black background against white text is not comfortable for dyslexic users, so for dyslexic users the black background does not work well.

Helpdesk main page with a grey background.
Welcome page with a grey background.
About page with a grey background. This page is text-heavy with big blue headings.

Food for thought

Ultimately, with Microsoft’s deprecation of Windows 10 Mobile in late 2017 and end of support altogether in 2019, if this app had been further developed in 2016 it would be time to upgrade it now and a responsive website might have been the ideal successor. It would be compatible with more devices and still tick a lot of the boxes.


Enjoyed this case study? Have a look at some similar work!

Broads Authority Web App

How can you encourage families in Great Yarmouth and Lowestoft to visit The Broads using technology? Much of my time in Year 2 at university was spent on this live client brief that rendered interesting results.

Cura-T Facebook Chatbot

How do you make finding cancer clinical trials easier? Whilst interning at Earthware, I worked closely with Cancer Research UK to develop a Facebook Messenger chatbot to do just that.

Redgate Database UI Project

As part of my application process for an internship, Redgate tasked me with designing a new interface for a database, based on user research that they provided for me. This is what I came up with.