[ REDACTED ] TELECOM

VICINITY

Mobile • Enterprise • Information architecture • User journey

Creating a single touchpoint that standardizes experience, and
streamlines availment process of multiple services for employees

DISCLAIMER: Written in this article are from my perspective while working on the project and does not reflect the views of the company owning the product in any way. Some parts of the app had also been slightly altered for presentation purposes

[Redacted] Telecom has office sites located in various cities across the Philippines. Each site has its own services and facilities available to the employees. The company invests in these to provide better employee experience & culture.

Services and facilities inventory:

*The main headquarters hold the largest inventory of services and facilities, offering all items listed below. Other office sites offer only some of the following:

Gym class
Basketball court
Medical consultation
Cafeteria
Shuttle service
Parking
Car rental

Gate pass

Work desks
Huddle rooms
Meeting rooms
Health emergency response
Facility maintenance service
Security risk response

The problem

Employees have low awareness of the available services and facilities in the office site they’re based in or visiting

Various apps are being built specifically for a single service/facility, causing disjointed and inconsistent experience

Employees may be aware of these services and facilities but has no knowledge how to avail/request or may have different ways of doing so

App objective

Gateway experience

Provide employees a gateway experience in discovering services, facilities and location-based apps available per office site

Single touchpoint

Have a single touchpoint to book, request, report, and check-in to services and facilities available in all [Redacted] office sites

Streamlined request and approval process

Create a standard request/booking form which upon submission gets forwarded to the corresponding service owner/administrator

*Form will be forwarded to the supervisor's app access should approval is required

My role

As the UX architect & designer, I was in charge of the product’s strategy, information architecture, user flows, wireframes, as well as the logo and interface design.

Creating a single app for multiple services also means that I am responsible for communicating and building relationships with multiple service owners a.k.a. stakeholders.

As the app gets coded, I worked closely with the developers, conducted a design fidelity testing to ensure compliance to the approved design and experience.

PROJECT TEAM INCLUDES:

• Project owner

• Project manager

• Agile coach

• Scrum master

• Business analyst

Note: All of my outputs are checked as well by my UX manager for approval

Let's get the UX started

Cast of characters

Any user-centered ux process will start with the question “Who will use the app?

The answer given to me was simple, “All [Redacted] employees”.

I thought it can’t be that simple! 🤔 So I probed further and yas!

I was able to identify three different employee roles:

Service owner/administrator

This type owns the service and process. They dictate the information and workflow required to be able to book/request the service.

Supervisor

This type of user manages a team. Some services may require their approval prior availment.

Requestor (all employees)

Whether the user is a service owner or a supervisor, everyone can be a requestor. This is the general population of [Redacted] employees.

The big picture

Creating a mobile app that houses multiple varying types of services can be quite overwhelming and can go sideways if not mindful. So, it was crucial to define the key function of the app. I came up with three:

Provide location-based information
Facilitate booking/reservation and check-in
Trigger report to corresponding response team per site

These three defined what merits a service/facility/information to be built inside the app. So should there be any more in the future (which for sure there will be), we can cross-check if the functionality falls within these key functions.

#futureproofing #scalabledesign

Information architecture

Now that I know who my users are and defined the key functions of the app, I can now start creating the information architecture

Standardized experience

It may sound challenging to create a standard, generic experience for various types of services. But since we already defined the key functions of the app, realizing the commonalities in each services came easy.

I visualized the generic experience by creating a high-level user journey. This set the standard experience across all services, and in a way became my guide whenever a service that required customization almost led me to overcomplicating design solutions. At the end of the day, availing a service should be as easy as booking your hotel room for your next getaway, right?

Visuals and interface

Coming up with the name of the app was definitely not easy. I want something short but sweet. A single word to represent what the application is all about. I literally asked random people within the team to brainstorm names with me just to find the one.

In the end, Vicinity sounded perfect for a mobile app created to house location-based services.

My activities

Stepping in the shoes of the app user, I should first and foremost be informed of the following:

• Upcoming activities - time and location

• Requests that needs approval - current status

I'd hate to miss any bookings I have if I were them. When I have none or needs another service, then I'd go to the list of services available to me.

Office sites

Showing one office site at a time should save the user time and effort scrolling/browsing services in office site they're not in or rarely visit.

This page was designed to show one site at a time, displaying services available and location-related information.

Approvals

This page is only available if the system identified the user as a Supervisor or an assigned Service Owner/Administrator.

During my employee roles study, these types are always on the go, running and attending meetings. So, the approvals page was designed to be without any fuss.

Takeaway

The UX architecture of Vicinity has been proven effective even after the application was rebranded, and more services were accommodated.

The solid information architecture and generic high-level user journey were the key to having a scalable and future-proof product. Finding commonality in multiple services with different use cases may be challenging, but definitely possible. The key to this is to have a clear definition of your product's goal and function.

Vicinity became the go-to app of employees whenever they need a location-based service and information. Discovering new ones also became easy as Vicinity has its own announcement section. When the pandemic hit the country, it was one of the essential apps to the skeletal work force who needed to work at the office, and imperative when all employees were eased-in for return.