See Tickets Mobile Site

User interface /

See tickets
mobile site

I was challenged to create a dynamic mobile site as we felt there was a big hole in the business that needed filling when people bought tickets for events whilst on the move.

User interface

By researching, and through personal experiences, people use their phones more during the day, during commutes, and on lunch breaks. It isn’t always easy to have a computer to hand to book concert tickets.

It made sense to create a smooth experience to book through and store users information to their account on. So the next time users wanted to buy tickets, it would be easy enough to do so in no more than four clicks.

Location screen

When a user first enters the site, they get asked if the site could use the phone’s location. This helped keep events relevant to the location of the user. You could also use the search bar to search for events within a specific city or area.

(Android – iPhone – Windows)

Login & Sign up

We gave users the ability to browse the website regardless of creating an account or not. However, when the time came to buy tickets, users would be required to Login or Sign Up.

Creating an account allowed users to ‘like’ and ‘follow’ events of their choice. Users could also save their details to speed up the checkout process when ordering tickets. As this is time-sensitive, the whole process a lot simpler and easier to complete.

Homescreen

The home screen was designed into different sections to allow users to filter and easily search. You could search for a Date range, Location or Event type. Changing these filters updated the results on the homepage accordingly.

The home screen showed an infinite amount of events, with the ability to add individual events as your favourite. Adding a favourite event allowed users to navigate back quickly to that event at a later date.

When a user adds an event to their favourites, it gives the user the option to receive notifications announcing when tickets went on sale or if ticket allocation was running low. We didn’t want people missing out!

Filtering & Search results

To help users narrow down their search results, we added the ability to search a specific date range, events happening on that day, the following day, or coming up at the weekend.

As well as this, we used geo-location to bring in all the events happening within a set radius of the phone’s location.

Finally, if the user had a favourite genre of music or festival, then they could favourite multiple artists – these would be remembered and filtered for the user on the homepage.

Tracking & despatch

Sometimes tickets took longer to arrive than expected; users could check the state of their order. We created a Tracking and Despatch area, where we added various FAQ’s and outcomes to help the user out.

A progress bar showed users the state tickets were at, and when the tickets will get delivered.

Tour page

The tour page is where users select the date / location that they would like to see an event.

Certain events had promotional videos and pictures you could view by swiping through on the thumbnails. I also added a ‘Similar Artists’ area at the bottom of the page so the user could view other areas and events.

Event page

The event page lets users select the number of tickets they require to add to their basket.

It also has additional information like the Seating Plan, Venue location and the directions.

Checkout

The checkout area needed to be straightforward and easy to use as it was time-sensitive.

If the user hadn’t purchased tickets after 5minutes, the tickets then get released, and the user would have to go back to repurchase the tickets. This prevented robots bulk buying tickets, or people adding tickets to their basket and forgetting to purchase them.

Within the Profile area, if a user allocates their bank card, they would only have to click the ‘Buy Tickets’ button – this helped save a lot of time at the Checkout stage.

If the user doesn’t fill these text fields, then they need to do so before being able to complete the purchase.

Impero Remote Manager

User interface /

impero
remote manager

Operating in two key sectors; Office and Education. I worked on the company rebrand and structure of their products, and branding identity to create a simple to understand and instantly recognisable format for customers.

USER INTERFACE

Designs approved and templates built. Now to populate the app with the new styled icons I created. The app was launched in four languages;

French, German, Arabic, and Dutch.

Icon design

The icons that ran through the app were simple. Each icon had three corporate colours; this helped give the app a modern facelift.

remote manager

Remote Manager is a seamless and innovative blend of online safety, network admin and classroom management software.

Imagery

It works in conjunction with the Education Pro, Workplace Pro and YouID software.

In doing so, we created a fresher and brighter identity that connects with Impero’s customers and creates a clear vision that flows through all products and sub-brand.

Website

The last thing to get rebranded was the website. During the test phase of development, the site got A/B tested so that we could choose which website layout to use once the official site went live.

imperosoftware.com

The website uses the location of the user. So when a user is in a different region, it loads up that specific regional webpage.

Each region has it’s own tailored visual elements that run throughout the pages.

A/b testing

A/B testing is a method used on many sites to find out how well a design is influencing users’ engagement, particularly in regards to a specific call-to-action.

imperosoftware.com

When users arrive at the site, they are shown one version of the design at random, and overtime statistics are measured to see which design gave the best results. Once a winner is determined, it becomes the design for all visitors.

Ikanos Pro Series

User interface /

Ikanos
Pro series

Golden-i is a hands-free computer that you control by voice commands and head gestures. The main aim of this technology is to assist the wearer during their daily jobs, allowing the user to keep their hands free while working.

GOLDEN-i OPERATING SYSTEM

(Gi-OS for short!)

The Gi-OS had to be simple, it was going to be part of something incredibly complicated, so it needed to be easy for the user to use and relate too.

GOLDEN-iOS v1.0

Generating new ideas.
Solving big problems

We created a sophisticated user interface and a comprehensive set of built-in applications to go with it – this set of applications was called the Prosumer Series.

Website

mygoldeni.com

Every January CES (Consumer Electronics Show) takes place, and we wanted to go to impress.

I worked closely with the Marketing team to create web banners advertising the new Ikanos website as well as the new swanky mygoldeni parallax website.

ikanosconsulting.com

In the build-up to CES, I worked on social media to kick up excitement and reveal promotional videos to tease users with future development work.

With this came the official creation of the Prosumer Series, these were a set of built-in applications that worked on Golden-i headsets.

Consumer product

LifeBoard

LifeBoard takes Golden-i to a different level, enabling users to customise up to 6 different screens to meet your working preferences. Designed for any working professional, by merely talking to Golden-i LifeBoard allows users to manage their day with ease by showing you your calendar along with the latest news and information:

Access files and documents, watch instructional videos and browse the web.

LifeBoard now includes the innovative Ask Ziggy speech-driven virtual assistant. Ask Ziggy allows users to send messages, make calls, set reminders and browse the web by merely talking to your Golden-i hands-free device.

Logo concepts

Here are a couple of logo variations for the LifeBoard brand. It needed to be simple, and give a hint of a flavour about the idea behind to concept.

User interface

Users are greeted with 6 customised screens to view personalised content; News, Calendar, File viewer, Phone contacts and Email.

The interface had to be simple, it going to have a lot of information on-screen – notifications and future events from the calendar, as well as call log history.

There was also the option of adding previous products that we had developed in the past, such as Firefighter Pro, Police Pro, Paramedic Pro.

Ikanos Lifeboard UX

user experience /

Ikanos
Lifeboard

Users need to open and view documents. View calendars, social media feeds, and make video calls to other users.

Team

1x UX Designer
2x UX / UI Designers
5x Developers

Creative Process

I was responsible for the creation of the patented product LifeBoard. Working under the guidance of our Senior User Experience Designer, we created the prototypes and the visually slick interface to complement the vision we had for handsfree computing.

Leading Research

We developed a product that hadn’t been created before, so we had to make sure our research correct to help.

Time Management

Working under tight deadlines to show critical investors and stakeholders the development of the project.

User Testing

The product was tested on lots of people to help adapt and improve the initial experience of the product.

Product Features

The Gen 3.8 headset was the new ‘sexy’ product. It had a faster computing processor and a better screen resolution which allowed us to improve the detail of the user interface dramatically. It was also a lot lighter to wear in comparison to earlier developed versions.

Open & View Documents



Make / View Calendar Enteries



View Social Media Feeds

Make Calls to other Users

STERIS Collect & Deliver UX

user experience /

STERIS
COLLECT & DELIVER

the problem

The plan for this project was to create a lean app-based solution to help porters in their daily job when collecting and delivering trolleys from a hospital facility to a cleaning warehouse, minimising any defects caused by human error in the process (roughly 80 defects per week!)

To do this, I looked at moving their current process of good ol’ pen and paper to a digital format. The porter would scan the clean trolleys they collected from the cleaning warehouse and drop them off at a hospital to be used, scanning their location on arrival, followed by any dirty trolleys they collected in that trip.

TEAM

1x Business analyst
2x Developers

My role

User research // User flows // Wireframes // Visual design // Prototyping // Testing

Exploration

The app aims to help delivery drivers perform their tasks with ease and efficiency, as well as cutting out any mistakes.

The current process involved drivers filling out sheets of paper with collection and delivery times, as well as writing down the number of trolleys they collected and where they had been collected or delivered from.

If there are any mistakes, a financial charge is added to the bill, this is in the hope that it will cut down mistakes going forward, but this is still happening.

Insights

Whilst shadowing a driver for the day, I learnt about the current processes in more detail, which highlighted a few issues that the drivers have on a day to day basis.



Trolleys getting mixed up

A trolley that is meant for one hospital may turn up at another. It sounds crazy, but these trolleys have poor wheels, cleaning staff tend to group trolleys together based on location ready for the porters to collect. Don’t be surprised if a trolley from one group slowly creeps away from the rest.

You only need a member of staff to notice a random trolley sitting in the corridor somewhere and they will put it back in the group where they thought it came from, but it’s actually the wrong one – et voila! Mixed up.



Fast-tracked trolleys

If the driver gets a call to come and collect a ‘Fast-tracked trolley’, they literally have to drop everything that they are currently doing to go collect that trolley ready for its emergency procedure. As a result of this, this is another way in that trolleys can easily get mixed up.



Completing delivery logs

The porter will generally turn up to a hospital with a van of roughly 10+ trolleys ready to hand over. There is only one porter per van – so you would normally take 2 trolleys at a time (unless they’re really heavy). So that is 5+ trips from the van to the ward (which tends to be on the 6th floor somewhere) meaning elevator trips. This process can obviously take a long time after you’ve dropped the clean trolleys off and collected the dirty trolleys.

As well as this, the porters have to remember what they have dropped off, and what they have collected so they can fill in the delivery logs correctly – obviously, there are quite a few things that can go wrong with this, leading to quite a few discrepancies.

High level user journey

I created a high level user journey to help highlight the path that a porter will generally take during their shift. (excluding any Fast-track journeys)

Product Features

Delivery drivers use a device called a Bluebird. It has a built-in scanner that allows drivers to scan their location where they are collecting trolleys from, as well as scan any trolleys that waiting for collection.

Once scanned, the app notified the facility the trolleys were collected, and they are getting delivered.

As well as notifying the facility, users could also view the location of the delivery van in transit due to the geolocation of the drivers phone device.



Lean UX process



Native Google Design



Geo-location tracking



Offline handling

Ideation Process

I created user flows – one happy path, and one that covered service drop out, the signal can be pretty poor in some hospitals so this needed to be carefully considered.

Happy path

After the user logs into their account, they land on the Tasks screen – this shows a personalised page relevant to the user and what tasks that they would perform on a day to day basis.

The ‘Collect’ feature, requires the user to scan the location they are collecting the trolleys from, then scan the trolleys waiting to be collected.

When scanned, the barcodes of the trolleys are checked against the database to see if it is recognised. If recognised, the trolley name and its ID gets logged to the collected list, and details are updated on the database accordingly.

If the barcode isn’t recognised, the user is then notified to take action to solve the problem. Users will be able to tell if the barcode isn’t recognised by the error noise the system makes (it’s loud!), as well as the Bluebird device vibrating in the user’s hand until the error has been acknowledged.

This process repeats until there are no more trolleys left to scan.

Unhappy path

The unhappy path covered how the app handled offline functionality.

The app talked to the database to make checks when scanning locations and trolleys, so it is vital to keep a signal.

Signal strength tends to be quite low in older facilities, so if the signal drops, the handling of this needed to be seamless, considering the importance of the trolley’s contents.

So when the user scans a trolley while the device is offline, the trolley details are stored in an ‘offline list’, and the current functionality handles the way it would normally. – making a ‘success’ noise to notify the user that a trolley has scanned.

When the signal returns – the database checks the ‘offline list’ for any trolley errors and duplications. If there are any, the app notifies the user to take action.

Wireframes

After taking all my research and findings into account, I started creating the wireframes in Balsamiq to work towards addressing the pain points the drivers currently have.

I mocked up some basic wireframes to help gather feedback from the drivers on the overall flow and layout whilst also considering the following:



Make the process as lean as possible to minimise completion time



Making visuals as intuitive and easy to understand as possible



Accommodating technophobes - I don't want to isolate older folk

Login & Password expiry

When the user opens the app, the first thing that they have to do is login with their credentials.

The app login had a 10minute inactivity period before it logged the user out of the app. If the user works for a longer time, the user can tap ‘Remember me’, and it will keep them signed in until they decide to log themselves out.

After logging in, the user is taken to their Task page, where they can set up, or do their daily jobs. – Phase 1, started with Collect and Deliver.

Login design flow - enter user details (2 of 3)

Login design flow - enter details (3 of 3)

Collect

When the user opens the app, the first thing that they have to do is login with their credentials.

After logging in, the user is taken to their Task page, where they can set up, or do their daily jobs. – Phase 1, started with Collect and Deliver.

Hospital contacts

When the driver logs into a device, it populates the contacts page with the relevant staff that are on shift at that facility, as well as the relevant delivery points.

If something goes wrong during a journey, e.g. stuck in traffic, the driver can call the manager, or use the maps to navigate around and get to the location quickly.

Most drivers have roughly 3 or 4 delivery points that they drive to throughout their shift. Sometimes there can be ad-hoc requests for Fast Track deliveries that are needed urgently. These requests notify the user and take them directly to that location straight away.

Favourite tasks

The user can edit their favourites depending on what jobs they are doing throughout their shift. This updates the Task page when the user toggles each job on or off.

Notifications

The notifications page shows a timestamp of the driver’s journey throughout their shift.

So when a Driver arrives at a location, they need to scan their location barcode, as well as scan trolleys that are getting delivered and trolleys that they are collecting.

Flow chart

Creating a flow chart for the app gave me a high-level view of the whole process. Doing this helped me refine any little niggles with the expected behaviour and what pages users should navigate to when coming from specific pages.

User testing

I conducted a user test session with the drivers to see how they got on with the new design and whether they thought it improved the issues they were having previously during their shift.

I wrote a script including a scenario asking the user to login with their account details, select a task (in this case we were just focusing on ‘Collect’), scan their location, and a couple of trolleys.

I also managed to add the prototype onto the device so it gave the drivers the impression that it was the real thing.

During the session, I watched how they interacted with the device and started scanning the barcodes. Initially they were a little wary, but soon got the hang of it.

After they completed the scenario I asked what they thought of the process. Like all loved the simplicity of it but they all felt like they needed to go back to the van to fill the delivery logs in, but obviously the process cut out the need to do anything like that so they were really pleased with how much time it saved them.

The numbers

The aim was to reduce delivery defects by the drivers when collecting and delivering trolleys. The defect rate was quite high before the project kick off, and the issue was that trolleys weren’t obvious where they were getting delivered, and what the trolley content was. So facilities received trolleys they weren’t expecting.

Developing the app allowed drivers to scan the trolleys and their location; this reduced the defects significantly and increased overall productivity because hospitals were aware of when their delivery was expected. If there were an issue, the user would get notified by the app that there was a problem.

Defect Rate (Without app) – 79%
Defect Rate (With App) – 100%
Productivity increased (With app) – 44%

CURRENT TROLLEYS PROCESSED A WEEk

TROLLEY DEFECTS A WEEK (WITHOUT APP)

TROLLEY DEFECTS A WEEK (WITH APP)

PRODUCTIVITY INCREASED

« Older Entries

Next Entries »