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%

TROLLEYS PROCESSED A WEEk

DEFECTS A WEEK (WITHOUT APP)

DEFECTS A WEEK (WITH APP)

PRODUCTIVITY INCREASED

See Tickets Mobile Site UX

User Experience /

See tickets

mobile site

Revamp the old mobile site to make it dynamic and have a smooth process for users to purchase tickets through.

Team

1x UX / UI Designer
4x Developers

Creative Process

I researched and produced wireframes for the new mobile site, along with low fidelity prototypes to share with key stakeholders and users within the customer service team.

This helped me collect crucial feedback at the development stages to help improve the user interface of the final design.

Google Analytics

Studying user patterns and drop-off rates allowed me to fine-tune features to maximise the users experience.

Wireframes

Wireframes support me to concentrate on the correct positioning and layout in it’s most basic form, before design.

User Flows

Give me an overview of the process, allowing me to streamline the process and remove any unnecessary actions.

Prototypes

Creating prototypes allow me to test and make tweaks to the process before the development work begins.

Product Features

Users could view concerts around the world by using the search bar. I was tasked to personalise results based on the geolocation of a users mobile phone. This notified them and made them aware of any concerts going on within a set radius specified in the user’s profile settings.

By letting users create an account, I could streamline the user flow and reduce the click count to four clicks for the entire buying tickets and checkout process.



Adjustable Search Radius



Streamlined User Flow



Quick Payment Process

Research

I researched into user behaviour and current processing times. Timed as soon as the user searched for events, and ended after the transaction completed. This gave me an average timescale for each sale made.

I studied Google Analytics to look for any pain points where users dropped off regularly in the user flow and worked on those areas specifically to improve the overall flow.

I produced wireframes for the mobile site, along with low fidelity prototypes to share with stakeholders and users within the customer service team to gather valuable feedback.

The numbers

In comparison to the previous processing times, it took users on average 10minutes to search for an event, purchase the tickets, and receive their confirmation correspondence.

After streamlining the user journey, and working on the areas where the most amount of drop-offs occurred, we managed to reduce the average processing time by over 7minutes. A whopping 76% improvement in processing time.

PROTOTYpes

After researching into best practises and looking at ways to make the process as lean as possible for the users. I created my wireframes in Adobe Illustrator.

LOCATION SCREEN

To start with, when a user enters the site, they are asked if the website could use their current location. This is to help keep events relevant to the user depending on where they are in the world. You could also use the search bar to search for events within a specific city or area.

SIGN UP & LOGIN

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.

UNiDAYS Native App UX

User Experience /

UNiDAys

native apps

the problem

The challenge was to create a native iOS and Android application to replace the current dynamic website that was being used.

The outcome had to use the latest native UX best practices and expected user behavioural patterns to not alienate users. As well as this, the app needed to be as lean as possible.

TEAM

1x Android Developer
1x iOS Developer

My role

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

Exploration

The current dynamic site had a few areas that needed improving when going forward with the native app. Regardless of what operating system you had on your phone or tablet, you would always get the same design.

Other areas that needed to be taken into consideration were:



A lot of work needs to be considered with the top banner of the site, currently the touchable areas between buttons would fail usability standards.



The discount text at the bottom of each perk is too small as well as the ‘favourite’ icon.

Creative Process

I was responsible for creating the native apps using common practices and expected user behavioural patterns.

The functionality had to be slick, without compromising the premium screen estate.

To help us create the app that would take the business to the next level, our users would want to download and enjoy its simplicity.

We set out a roadmap to plan to help us gather the right information to set goals to help us deliver a world leading application.

Site Maps

Creating a site map helped me to get an overview of the key user routes that would need to be taken by the user whilst navigating the app.

Behaviour Patterns

Different operating systems require different user patterns, anything out of the ordinary may alienate users and put them off using your app.

Focus Groups

Having lots of people testing the app at the same time, allowed us to pin point any pain areas during the set tasks we set for the users.

A/B Testing

This allowed us to test specific sections and user flows of the app where we were not 100% sure on which outcome would be best suited for the situation.

Site maps

The very first area I worked on was the site map for the app, creating all the hit points and areas that users will be able to navigate to and use.

This covered the top navigation and the footer for the app.

Focus groups

We thought it would be a great idea to organise a focus group between staff across other departments of the company to try and get extra ideas that we could put towards the creation of the app, as well as to see if there was any consistent issues that we needed to avoid or improve with the current dynamic website that we had.



Brain Storming



Creative Planning



Intuitive Design

A/B Testing

This allowed us to test specific sections of the app and keep an eye on the behavioural patterns of our users when they landed on the relevant pages.

Doing this gave clear results for which design we should use as one would work better than the other. If that was the case, we then phased out ‘Design B’ completely.



Native Design



Geo-Tracking Discounts

Customised Notifications

Next Entries »