Aevice Health Internship

WHAT I DID

I had the pleasure of working on many different things over the months:

•

Designed mobile and web features for different user groups

•

Create pixel-perfect prototypes for investors and exhibitions

•

Conducted user testing on features and iterated on designs based on synthesised results

•

Engaged in competitor analysis, ideation and brainstorming of problems and solutions

•

Learnt and developed a site using Webflow

•

Collaborated with stakeholders including software, business development, regulatory and product manager to develop solutions given business restraints and priorities

The non-disclosure agreement limits what I can share, but you can check out a highlight reel of my experiences below. I can also share more in a private chat.

COMPETITOR ANALYSIS

I engaged in competitor research and external reading to develop my domain knowledge. This included learning more about the guidelines surrounding asthma, as well as medical terms and FDA restrictions.

This information helped to shape the features we worked on - from ensuring lay users understood complex medical information, to simplifying data visualisation for medical professionals.

UNDERSTANDING OUR USERS

Interviews with healthcare professionals formed the base of user personas. With these personas in mind, we created user journey maps to identify pain points and opportunities for further opportunities.

User persona of healthcare professional. Her main pain point is that patients' self reported symptoms are not always accurate

User persona of caregiver. Her main pain point is that she struggles in remembering her son's symptoms over time

IDEATION & HMWS

The design team had multiple brainstorming sessions with How Might Wes and Crazy 8s explore ways to improve user engagement and consistency of app usage.

We also conducted a company wide ideation workshop. I had the opportunity to support the lead facilitator, from crafting problem statements to presenting our user personas.

We then consolidated the major themes and put them out for voting. The most popular ideas would be evaluated for feasibility and considered for further action.

Many post its stuck up on a wall in groups. Pieces of paper in the background with screens drawn on them.

People crowding around a wall with post its. Someone is presenting off the wall.

DESIGNING FOR ANDROID AND WEB

The product design team works as a cohesive unit to design screens for new features, as well as iterate and improve existing flows. I designed screens for both mobile and web.

We used pair designing to ensure both edge cases and happy paths were considered. It also allowed us to sanity check and bounce designs off each other. This and the frequent design critiques trained me to better articulate design rationale, as well as provide feedback to my peers.

PIXEL PERFECT PROTOTYPES

I created pixel-perfect prototypes on Figma for pitch decks, international exhibitions and future user testing.

These experiences cemented my love for prototyping and stretching the limits of Figma. It was so fun seeing our designs come to life. It’s the small things like typing animations, interactable data filters and chained hover states that make the prototypes seem real.

Figma file of different screens with arrows showing the prototyped flows

Three Aevice staff standing in front of the Aevice exhibition booth at CES. In the background there's a TV screen, phone and tablet that show prototyped flows.

I was also involved in usability testing with external participants. We sought to test the ease of use of a physical device alongside a companion mobile app. Over 3 rounds of testing, we sought to improve on 3 areas:

1. EASE of use of physical device

Establish whether the device is understandable and easy to use on its own.

2. ease of use of mobile APP

Establish whether the accompanying mobile application is clear and users can perform follow up actions.

3. ACCURACY OF USE OF PHYSICAL DEVICE

Find out whether users are able to use the device accurately. If not, establish common user errors.

PREPARATION

We first prepared the usability study plan. The aim was to ensure that there were no leading questions, whilst still being able to identify users' struggles and understand their experience.

One major issue we had is that we required, but could not find sufficient parent-child participants. To solve this, another designer and I looked to various sources, and eventually created a database of over 200 participants.

CONDUCTING THE TESTS

I was involved in both note-taking and conducting the usability tests.

I enjoyed seeing our designs through the eyes of different users, as well as checking our assumptions against users’ mental models. It was both interesting and frustrating to see the patterns and pain points that emerged, especially with respect to things that the design team had not even considered as an issue.

POST-TEST

We then synthesised the data and pulled out the major pain points. We discussed these with the R&D team and identified solutions for further design iteration.

This includes redesigning instructional illustrations, allowing users to better identify system status, and changing microcopy to redirect users' focus.

By the end of the third usability test, we had a product that was easily used by users. The physical device was sufficiently intuitive that it could be used as an accurate standalone device. The mobile application was also clear and users were able to easily complete the follow up actions.

BUILDING THE HELP SITE

The design team was in charge of building a help center for the product on Webflow.

Site building was a trial by fire: a classic combination of deadlines, ambitious goals and zero prior knowledge. Through significant self-directed learning, problem-solving, and multiple failed attempts, the site is ready for its private group of users. Although initially scary, I really enjoyed the deep dive into a new tool.

DOCUMENTATION

One struggle I had was preparing and updating documentation for handing over the help center.

I had to consider how to ensure that future designers, who might not have knowledge of Webflow, would be able to understand and make changes to the site. To better understand how documentation is done, I talked to designers and software engineers from other companies like Indeed, Meta and Zendesk.

Eventually, I created a Google Slides deck with step by step instructions on making various changes, as well as information on the custom code used. I also shared with the team some issues that they might encounter in the future, and possible solutions.

GETTING THE OK

I aimed to get the green light for the site before the end of my internship. This required consultation with other teams like business and regulatory, and solving any issues they might raise.

I'm glad to say that we managed to receive the stamp of approval from management just before my last days at Aevice: the site is now up and running ☺️

REFLECTIONS

This was my first experience at applying UX in the real world, and it has confirmed my passion for such work. The internship has trained me to communicate with designers and non-designers, and I've improved my presentation and storytelling skills.

Each struggle has left me with new lessons. I worked closely with the Business Development team for a few months, and initially struggled with designing something that fit their needs. Things only clicked after I identified their interests and designed with them in mind. This was a crucial lesson in using design to drive value propositions, and has made me more aware of the different tensions that affect my work as a UX designer.

The past months at Aevice have been exciting and purposeful, with each day being full of new challenges and meaning. I've grown significantly as a designer, and I can’t wait to grow more.