Market-oriented information about the current product is accessible on the AHI website. Its most significant impact is in the healthcare sector, which continues to be the company’s primary focus. However, there were multiple industries to support as the company aimed to claim prior art and pivot. The main industries I was tasked with supporting for several years included:

⁍ Health & Wellness

⁍ Life and Health Insurance

⁍ Fitness

⁍ Apparel

I developed use cases tailored to each market, which were utilized throughout the sales and customer support processes. I initially created partner-facing documentation (excluding developer-specific materials), which was subsequently supported by another designer and eventually by dedicated staff.

🧿 This project was a typical Figma handover that I shared with partners. Given that everything was driven by the Software Development Kit (SDK), much of our discussions revolved around navigation, entry and exit points, theme options, and so forth

One competitor that entered the market was Amazon Halo. It was a hardware device (wearable) and an accompanying app that had several other features like sleep and activity. Years earlier, they had acquired another company, BodyLabs, and were using the phone to 'scan' people. Combined with some research, they trained a body measurement pipeline with some detailed visuals.

The Process

It used the front camera and also required you to stand in front of the device. But it required you to take 3 photos of yourself: Front → Side → Side.

The Halo introduced more poses to account for the larger give in phone height (knees to waist). Their UI degrades sharply from the UI side of the app into the scan and out again. You will notice her feet are cut off, but it still scans, despite requiring “Fill frame head to ankles”.

The balance they walked required more physical actions. It was a rushed product. The UI was poorly implemented, and there was far too much messaging around rearranging arms and legs.

It’s worth noting that they chose a partially transparent outline of a person that is filled to demonstrate how someone should stand. In our version, we use a custom hollowed-out version to stand inside. I do not doubt that this was to avoid patent infringement with AHI.

I reviewed their tech extensively but could not get my hands on one to review myself. It left me feeling pretty positive about what I had done and the length of effort in balancing the number of steps and acceptance with a decent result. To be up against a big player like Amazon and still come out on top, it’s a feel-good moment 😊

The scan guide was initially part of the integrated SDK, along with other features like results views and track & compare. However, during the process of rebuilding BodyScan, the decision was made to remove the scan guide and let partners handle the integration.

I opposed this decision because it added time and cost to a project, which delayed its launch and getting the data into the ecosystem. Some partners chose not to use our guide assets and created their own guides. This sometimes resulted in a less satisfactory user experience as they overlooked key points such as phone height, leading to higher scan failure and drop-off rates.

The impact of this decision was significant. In a value proposition analysis I conducted, I estimated a minimum expense of US$250,000 for integrating BodyScan, per platform. It was identified as a major barrier to the success of the product.

This also impacted the time it took to collect people’s biometric data, further delaying the point of data saturation in a partner’s ecosystem. Our technology was meant to be fully integrated into their decision-making processes and become indispensable.

Placing the phone too far back on a surface can result in the view of the ankles being blocked when positioned in the outline. This issue is exacerbated by the fact that someone viewing the small screen from a distance may fail to notice that their ankles are not visible as people will focus on their face and head.

Performing a body scan may seem straightforward, but like many complex UX problems, the devil is in the details. To ensure accurate scanning, a person needs to find a physical surface in their home that is slightly shorter than half their height. The camera should be positioned at around half their body height, and the physical device height needs to compensate for the difference. The size of phones, ranging from SE to Max, can make a significant impact on the scanning process.

To address this, I researched the height of common furniture available at places like Ikea. Furniture, designed for human use, is built on established standards. In some cases, there is natural flexibility built into most furniture, such as adjusting leg height.

The challenge arises when individuals are either above or below average height. Combined with the device angle, it can become impossible for them to fit within the scanning outline. To mitigate this issue, we implemented height-based suggestions. For those within a shorter range, we recommended using a dining room chair or a coffee table with books. For those above average height, a kitchen table or dining table with books was suggested.

Due to the height and device angle, some individuals attempted to take a body scan multiple times but failed. Occasionally, the height was correct, but they were in a confined space such as a bathroom, so they could not fit in the outline.

The height of the phone proved to be the most significant factor and barrier in performing a scan. As a result, the BodyScan underwent a major overhaul, resulting in version 2.0.

The phone height problems reported by users was the initial trigger for updating BodyScan. It had reached a point where advancements in phone technology made it possible to rethink the capture using real-time capture.

New algorithms and ML models were created and extensively tested through some baseline captures of people and a custom-built device rig. This would move a phone up a guide and perform captures of a test subject. Eventually, by ‘walking the curve’ and collecting more data we could give another ±10cm around a person’s midpoint. A person would have a greater choice of surfaces to capture their measurements.

I broke the new capture into stages depending on the physical stages a person performs or a major trigger. These are:

❶ Alignment (Phone Setup)

❷ Framing Loop

❸ Positioning

❹ Front Capture Loop

❺ Side Guide

❻ Side Capture Loop

Each stage of the workflow is associated with specific conditions, events, and checks that are crucial for coordination between the primary developer and QA. I created a comprehensive workflow diagram in Figma, which served as the primary reference throughout the project. This improved onboarding time for new developers.

The most challenging and error-prone stages occur before the outline is drawn. We need to determine if there is a person present, if we can see their ankles, and check the height of the phone—ensuring it’s neither too low nor too high. This involves a series of movements, such as moving forward or backward.

Assuming everything goes smoothly and the person doesn’t wander off to make a coffee, we achieve successful positioning of depth for them to stand. Even if they move out of position, we have already identified the correct spot for them to stand. The outline is then matched to their approximate body shape, making it easy for them to fit in by simply repeating their previous actions.

BodyScan 1.x involved a 10-second countdown followed by a burst mode of 8 images. However, in this version, we were able to significantly reduce the wait times by using real-time joints and inspection. Once the person was successfully in position, the outline would change from dashed to solid. At that point, a countdown would start from a familiar 3 seconds.

The purpose of the 3, 2, 1 countdown experience is solely to ensure that the person remains still and focused during the scanning process. However, we can start capturing images as soon as they are in the correct position, even if it’s just for a brief moment, without any indication or countdown. Once we have obtained the necessary data, we can seamlessly move on to the next pose.

While this alternate method could be explored in another project, it would introduce certain challenges that may extend the project timelines.

BodyScan 1.x underwent unsupervised user testing to establish the baseline for comparison. The main test goal is to record the Time To Completion (TTC) and the number of attempts. It's also important to mention that, for multiple reasons, the project has been (and probably still is) under development for over two years.

A major part of this development centered around the UX testing and development loop. The initial Proof of Concept (POC) was conducted using well-timed video prototypes that utilized the built-in camera in ProtoPie. This progressed into some doctored guides and some rudimentary inline messaging to test certain flows.

Test conditions include:

⇢ The scan must be conducted in the participant's own home.

⇢ Participants must meet the age and device criteria.

⇢ Must screen record all attempts, including start and end times.

⇢ Complete a post-capture feedback form.

The screen capture would be manually reviewed, and the observations entered into spreadsheets and then later into Dovetail. Although the criteria focused on specific items like TTC and the # attempts, the screen recordings provided an invaluable glimpse into people's homes.

You can observe pose hesitation and body augmentation, lighting, background objects, time of day, available prop objects, clothing, fridge magnets, distractions from children and light sources, etc.

Data points from the video and feedback included:

⇢ Time to successful scan

⇢ Time to correct position from bad position

⇢ Total attempts

⇢ Front: Total phone position changes

⇢ Message trigger: Phone position changes

⇢ Message trigger: Move forwards

⇢ Message trigger: Place phone higher

⇢ Message trigger: Place phone lower

⇢ Time spent with no countdown or message

⇢ Good body positioning score

⇢ Side photo: Phone position changes

⇢ Time spent with no countdown or message

⇢ Side photo: Faced forwards

⇢ Side photo: Good body positioning

⇢ Environment score

Post-capture feedback questions:

💬 Overall, the task of taking a BodyScan to get results was (1-10)?

💬 Why did you give it that rating?

💬 What was the easiest part of the BodyScan for you?

💬 What was the hardest part of the BodyScan for you?

💬 What object/type of surface did you place your device on?

💬 What kind of objects did you use to prop your phone up to align it?

💬 How did you measure your weight before taking the scan?

💬 How did you measure your height before taking the scan?

💬 Did you actively read the scan instructions before starting the scan?

💬 Was there anything that just felt odd?

💬 What would you change in the scan process to make it easier for you?

Below are some UX screen recordings to outline the various problems and observations that could be observed.

I had to remain focused on key metrics and not attempt to fix every problem but having the screen recordings meant that I could revisit them at any time to collect different information.

The UX Test Summary Report is unable to be shared. ☹️

This build introduced different triggers and timing, and in some instances, it did not represent an improvement over the first. I included it to illustrate the critical role of observation and to highlight an understanding of the processes occurring behind the scenes. Additionally, the joints were made visible. Activating this feature allowed for a clearer visualization of the mechanics at play. These development tools have been further enhanced, as can be seen in the “BodyScan 2.x Debug Mode” video above.

You’ll notice numerous device interruptions. It seems she had recently completed her phone’s setup, which resulted in post-installation messages appearing while she was aligning the device.

It was immediately apparent to me that the phone was positioned too high. She conducted the scan near the kitchen, utilizing a small, rounded dining table, which intermittently obstructed the view. Standing at 165 cm tall, and factoring in the angle of the phone, she was precisely at the limit of the phone height calculations.

The kitchen provided a cluttered and complex backdrop, potentially complicating segmentation or joint detection efforts. The primary light source appears to be a window, likely situated above the kitchen sink to her right. The home is of an older style with high ceilings and features a space where a wood-fired oven once stood, now occupied by an electric stove.

The first instruction to “place phone higher” was triggered erroneously. This indicates an issue with the height calculations and the algorithmic count. At the 1:50 mark, when the message appeared, her head joint was within the ‘safe’ zone, and her knee joints were also correctly positioned. The system should have instead prompted her to ‘Place phone lower’.

After multiple unsuccessful attempts, she eventually abandons her initial setup in search of a different surface in another room. By now, the setup process has become familiar, and she spends considerably more time “salsa dancing”—my term for the user’s forward and backward movements as they attempt to find the correct depth for the scan.

Ultimately, she manages to complete the capture. During the follow-up interview, she expressed significant frustration with the height adjustment instructions. When I inquired about the time she thought the setup had taken, she estimated ‘15 or 20 minutes.’ In reality, the entire process lasted approximately 5 minutes. However, her perception of time was distorted by the combination of frustration and the physical inconvenience of having to change locations, which made the experience feel much longer.

While working on R2.0, I implemented additional messages and support for both dark and light modes, elements that are apparent in an ongoing but simplified Figma project. The plan was to transition to illustrated and customizable guides—potentially animated—for enhanced clarity and readability of messages.

This work was intended for inclusion in the BHA Project, aimed at Body Analysis assessments. Consequently, screens from this development phase were temporarily repurposed as placeholders while the project moved forward.