Back to Work
BLUELINK
UX Research · Smart Home App · Capstone Project

Braeburn Capstone

A redesign of BlueLink, Braeburn's smart thermostat app.We rebuilt the homeowner experience around first-time setup, troubleshooting, and everyday control, rethinking both the user flows and the visual system.

Role UX Researcher & Designer
Team AC&Co 4 designers
Client Braeburn Systems
Timeline Mar — Aug 2026
Explore the case study
9:41▮▮▮ ᯤ ▬
Cooling → 72°FNext: 6 PM
CURRENT 74°
Tap to adjust+
FEELS LIKE
74°F
HUMIDITY
38%
Cold
Auto
Heat
Away mode ›
Radius: 0.5 mi · Last detected: 2 min ago
Home
Schedule
Reports
Settings
9:41▮▮▮ ᯤ ▬
Troubleshooting
Having trouble connecting?
We'll help you get your device online. Choose the issue you're experiencing below.
COMMON ISSUES
QR code not working
Wi-Fi connection
Device not found
Try Again
Contact Support

From installation to application

Bluelink is a two-role system by design: HVAC contractors configure and service the equipment, while homeowners manage its everyday use. The product changes hands at a critical moment — from installation to ownership — leaving the homeowner to build a relationship with a device they did not configure themselves.

Our brief was to identify friction across this experience and uncover opportunities to create a more seamless connection between the hardware and software. Q1 focused on building the UX research foundation; in Q2, we translated those findings into the redesigned end-user experience.

How might we

How might we preserve existing end-user processes — onboarding, troubleshooting, and everyday use — while implementing an improved user experience into the Bluelink app?

01Discover
02Define
03Develop
04Deliver
My contribution

In Q1 our team focused on research, building the foundation for the design work that followed. I led the contextual inquiry, user interviews, competitive analysis, and heuristic evaluation. In Q2 I focused on user flows and the high-fidelity prototype and helped build the design system, while my teammates led journey mapping and the two rounds of usability testing. Once testing gave us insights we could act on, we iterated the prototype together and carried it through to final handoff. The screens on this page are a team output; the flow and prototype work is mine.


What we needed to answer

Q1

What do users want from a value product like Bluelink?

Q2

Where does the contractor experience break down during installation and consumer handoff?

Q3

Where does the consumer experience break down during onboarding and daily use?

Q4

How effectively does the current app mirror and complement the physical hardware?

Success metric 01

A higher user confidence score during onboarding and in error states — a clearer understanding of what went wrong when a flow fails.

Success metric 02

Alignment between the user's reported mental model and the actual system model.

Success metric 03

Reduced negative feedback and drop-off on core flows — adding a thermostat, creating a schedule.


Five ways in, from market to mind

“You can have the best thermostat in the world, but if it fails or you can't get it to connect and you can't talk to anybody, what good is it? What good is it?”

Interview participant · retired HVAC contractor, 15+ years — and a Braeburn homeowner
01
Literature Review

The client's material was almost entirely market-level, with no UX perspective at all. Across 20 sources we rebuilt the foundation: how people form mental models of temperature control, and how trust in smart-home products is built and broken. The number that stuck: installation splits 51% DIY / 49% professional — a near-even divide, which says there is still a lot of room to improve how each of those two paths is supported.

20 sources Mental models Trust & automation
02
Competitive Analysis

The client's competitive material was about the market and its trends, not the product design. We redid it — 7 brands across 15 experience criteria: install guidance, scheduling, C-wire solutions, Wi-Fi band, app onboarding, app reliability. The verdict was blunt: Bluelink is positioned as a value brand for contractors and homeowners, the price holds up, multi-thermostat monitoring is a genuine differentiator — but app reliability came out as a clear weak spot.

7 brands 15 criteria Pro1 = direct competitor
03
Heuristic Evaluation

Four of us walked the live Bluelink app screen by screen. Result: 9 of Nielsen's 10 heuristics violated across 6 screens, 4 of them critical. The worst pair was consistency and minimalist design — every home-screen button is the same size and color, and the largest, brightest one turns out to be account information. The app also forces landscape orientation. Our shared conclusion afterwards: redesigning is cheaper than patching.

9 of 10 violated 6 screens 4 critical issues
04
User Interviews

Four depth interviews spanning both sides of the handoff: a retired contractor who is also a heavy user, a manufacturer's rep who had just self-installed, and two homeowners — one a double amputee for whom smart-home automation is not a convenience but a necessity. This is where we explored what actually happens at the moment of handoff.

4 participants Contractor + homeowner Semi-structured
05
Consumer Survey (Quantitative)

Fielded through QuestionPro: 103 responses, 98% completion. This round didn't ask why people buy — it asked what happens after the box is opened, which is exactly the half the client's existing market data couldn't answer.

103 responses 98% completion United States

Everyone opens the app — nobody trusts the automation

46%

Mainly adjust manuallyOnly 22% let the device run automatically. The app is used constantly — the automation isn't trusted with the job.

51%

Energy reports change behaviorMore than any automation feature. Cost information follows at 43% and alerts at 44% — geofencing lands near the bottom.

76%

Households share controlYet the app is built for a single user. Multi-user control came up repeatedly in the open-ended responses.

Where setup friction lives (n = 100)
Wiring 23%
Account creation / device registration 20%
Connecting to Wi-Fi 18%
No frustration at all 39%

Friction is front-loaded into wiring and account setup — precisely the stretch where the contractor is present and the homeowner is not.

Usability issues in daily use (n = 99)
Too many steps for simple actions 16%
App slow, crashes, unreliable 12%
Layout hard to understand / unclear labels 7%
No issues experienced 56%

The problem isn't comprehension, it's effort — which shifted the design goal from re-explaining the interface to cutting steps out of it.

A note on this sample

These 103 respondents are smart-thermostat owners in general, not Bluelink owners — 50% are on Nest and only 2% on Braeburn. So we used it as a category baseline: it tells us where users of premium products are still frustrated, while the interviews and heuristic evaluation carry the Bluelink-specific answers. Conflating the two would have produced the wrong conclusions, and we flagged that explicitly when reporting to the client.


Every problem traces back to one gap

The handoff
01
When onboarding fails, users are left with nothing

The official flow does account for the handoff — the printed guide is meant to be left behind. But in every case we interviewed, the handoff was improvised in person: one contractor's method was to pull out his own phone, demo the app until the customer said they wanted it, then finish the install and leave; one homeowner wasn't even home that day. The judgments made during setup stayed in the installer's head — one homeowner, two to three years in, still didn't know geofencing existed.

Failure states
02
When something fails, there's no path but the phone

A failed connection returns a code, not a diagnosis — thermostat, router, internet, phone: the interface never says which of the four links broke. So support became part of the product. Users name individual reps and cite them as the reason for brand loyalty. Support being the strong point is the bill for the product's UX debt.

Mental model
03
A good thermostat is one you never think about

Users define success as the device disappearing into the background. They aren't asking for more features — they're asking for the existing ones to be reliable. One participant abandoned geofencing outright because it was, in her words, about a fifty-fifty shot. This directly challenges the assumption that more engagement means a better experience: here, success means not needing to open it.

Say–Do gaps: four places the words and the behavior diverged
“I don't need features” — but they rely on them constantly
What they say

“I just want to turn it on, off, and change the temp. I don't need anything else.”

What they do

Uses scheduling, remote access, Alexa integration, geofencing and energy-saving modes daily.

“The app is simple” — but setup is the biggest pain point
What they say

“Once you get it, it works great.” / “It's pretty straightforward.”

What they do

Watched YouTube videos, called a coworker, phoned Braeburn support, or had a professional install it. “Straightforward” only in retrospect.

“I don't use the app much” — but it's actually the primary interface
What they say

“I don't actually open the app.” / “I connected them and that was pretty much it.”

What they do

90% of control happens on the phone. Checks temperature remotely, pre-cools before returning home, adjusts from the couch instead of walking to the device.

“The usability issues aren't a big deal” — but they generate friction every session
What they say

“It's a stupid gripe. It's ridiculous. Not a big deal.” — about re-authenticating on every login.

What they do

Mentions it unprompted and describes it in detail. Friction memorable enough to surface in a research interview is friction that has accumulated.

This comparison was the most useful instrument in the whole study. Users almost never state their pain points directly — they rationalize them away as first-world problems. So we stopped listening to how they rated the product and listened to what they described themselves doing.

Four segments, four ways to fail them
↑ High app engagement
← Low routine / unpredictable schedule High routine / predictable schedule →
Power remote users

Heavy app users with variable schedules. Manual adjusters for events, travel and arrivals. Core need: fast, reliable remote control.

High app usageManual controlTravelers
Set-and-forget schedulers

Consistent routines, deep users of scheduling. Retirees and shift workers with fixed hours. Rarely open the app once configured.

Scheduling power usersLow daily frictionRetirees
Reluctant smart users

Low app engagement, variable schedule. Distrustful of complexity, prefer the physical device, use basic on/off only.

Low tech confidenceFeature averseWFH
Smart home integrators

Deep ecosystem investment — Alexa, voice control. Predictable enough to automate everything. The segment that suffers most when connectivity fails.

Voice controlAlexaAccessibility
↓ Low app engagement

The point of segmenting wasn't to categorize but to see that the same defect costs different people wildly different amounts. For a power remote user, a dropped connection is an inconvenience. For the bottom-right segment who depend on voice and automation — including the double amputee we interviewed — the same dropped connection means being stranded.


Sentiment bottoms out at setup

01
Purchase & installation

Anticipation meets confusion. Wiring terminology mismatches between brands cause real anxiety, especially when the installer isn't present. The manual is praised; cross-brand jargon is the blocker.

Wiring jargon Installer–user gap Support saves it
02
App setup & first connection

The lowest-sentiment moment in the journey. The thermostat → phone → router chain was described as “a little confusing” by multiple users. Feature overwhelm on first launch. Those who reach support recover; those who don't give up on advanced features entirely.

Too many options at once Connection steps unclear Geofencing undiscovered
03
Configuring routine

Users who persevere reach their equilibrium here. Scheduling is set once and largely forgotten; ecosystem integrations get made. But value is highly lifestyle-dependent — WFH users and retirees often skip scheduling entirely. Integrations not configured at this stage are rarely configured later.

Scheduling delight Lifestyle-dependent Integrations fragile
04
Steady-state daily use

The happiest phase — because the product disappears. Users stop noticing it, which is exactly their goal. Remote control is used constantly, geofencing delights when it works, minor annoyances are rationalized away. This is where brand loyalty forms.

Invisible = success Remote control valued Minor login friction
05
Connectivity failure & recovery

When connectivity breaks, users have no idea where to start — router? ISP? thermostat? Alexa? That leads to blind troubleshooting: “I just go in and mess with it.” No system feedback on what went wrong. Users who call support recover their trust; those who self-troubleshoot lose confidence in the whole platform. For accessibility users, this phase is physically isolating.

Unclear failure source No system feedback Support restores trust

This curve set the priorities for the entire second quarter. The product performs beautifully at stage 4 — but whether a user ever reaches stage 4 depends on whether stage 2 drove them off, and stage 5 can undo the trust built at stage 4 in a single evening. So we didn't optimize the happy stretch. We spent the design effort on the two troughs: first setup, and what happens after something breaks.


From insight to handoff

In Q2 the team split into two parallel tracks — one driving usability testing, one building the design system — merging weekly for review. This is also where scope closed around the homeowner app for good.

Step 01 · Jul 3
Journey Mapping & User Flow

Two sub-teams in parallel: Sophia and Sarah mapped the full contractor-to-homeowner journey while Aaron and I broke down the app's user flows. Laid over each other, the handoff gap was impossible to miss.

Step 02 · Jul 5
Crazy 8’s

Eight ideas in eight minutes, one minute each. The point wasn't to find the answer — it was to burn through the obvious solution fast so the less obvious ones had room to appear.

Step 03 · Jul 10
Sketches & Lo-fi Prototype

Once we converged we built clickable lo-fi prototypes in Figma Make, so the flows could be walked through instead of argued about in a meeting.

Step 04 · Stakeholders
Mild, Medium, Spicy

We presented the concepts in three tiers — conservative, moderate, aggressive — at the same time. It was the most effective communication move of the project: it turned the conversation from “is this acceptable” into “how far are you willing to go,” and got the client to name their own constraints out loud.

Step 05 · Jul 17
Round 1 · Usability Testing

Round one ran on the lo-fi prototype while the design-system track started in parallel, so findings could be absorbed straight into components instead of stranded in meeting notes.

Step 06 · Jul 24 — 31
High-Fidelity Prototype + Design System

We built the design system on the 2024 Braeburn brandbook — 6 core colors, 9 semantic tokens in each of light and dark, 6 approved gradients — then built close to 70 screens of high-fidelity prototype on top of it, covering account creation, pairing, troubleshooting, scheduling, reports and settings.

Step 07 · Aug 7
Round 2 · Unmoderated Testing

Unmoderated, to check whether the Round 1 fixes actually held. With nobody there to explain, the interface had to speak for itself.

Step 08 · Aug 24
Handoff

The final delivery was a package: the design system, annotated flows, and an explicit trace from each test finding to the design decision it drove — so whoever picks it up knows why each call was made, and which recommendations they're free to decline.


Every screen answers a finding

Where we started: the original screens, annotated
Original Bluelink app — Select Thermostat home screen 1 2 3
Original “Select Thermostat” home screen
Original Bluelink app — thermostat controls screen 4 5
Original thermostat controls screen
1
H8 · Aesthetic and minimalist design

The largest, brightest, only-yellow button on the screen is “Service Dealer” — which is just an account information page. Visual weight runs exactly opposite to actual importance.

→ The redesign makes the current temperature the single anchor and files account info under Settings.
2
H4 · Consistency and standards / H6 · Recognition over recall

List items on the left are rectangular while the buttons on the right are pill-shaped — two UI languages on one screen. Devices are named by model number: “7 Day Commercial 7320” asks the user to remember which unit is in which room.

→ One component language, plus custom device names — a fix traced directly to Pro1 in the competitive analysis.
3
H10 · Help and documentation

A bare “?” floats in the bottom-right corner with no border and no label. In testing, not one participant realized it was tappable.

→ Help became a labelled, permanent destination in the bottom navigation bar.
4
H7 · Flexibility and efficiency of use

Temperature moves one degree per tap through arrow buttons, with no way to type a number. Going from 60°F to 75°F takes fifteen taps.

→ The redesign keeps ± but adds a draggable ring with both bounds visible at once.
5
H2 · Match between system and the real world

“Following Program,” “Occupied Schedule,” “Hold” — HVAC trade language throughout. One participant, verbatim: “Permanent hold sounds scary… what's permanent?”

→ Rewritten in plain life language: Cooling → 72°F, wake up, leave home, return home, sleep.

Both screens are landscape because the entire app forces landscape orientation — in a world where nearly everyone holds a phone upright. It was the fastest agreement we reached in the evaluation, and the starting point for deciding that a redesign was cheaper than a patch.

9:41▮▮▮ ᯤ ▬
Cooling → 72°FNext: 6 PM
CURRENT74°
Tap to adjust+
FEELS LIKE
74°F
HUMIDITY
38%
Cold
Auto
Heat
Away mode ›
Radius: 0.5 mi · Last detected: 2 min ago
Home
Schedule
Reports
Settings
Home
The whole state, one screen

On the old home screen every button was the same size and color, with no hierarchy. Here the current temperature is the single visual anchor, with heating and cooling read off one continuous ring in the brand's semantic colors. “Feels like” and humidity were called out by name in testing as moments of clarity — they translate raw data into something a person reads instantly.

Traces to Heuristic eval: no visual hierarchy on home (H8, critical) · forced landscape (H4)
9:41▮▮▮ ᯤ ▬
Cooling → 72°FNext: 6 AM
Scheduling
Schedule One
SUNMONTUEWEDTHUFRISAT
20212223242526
6:00 AMWake up72°
9:00 AMLeave home65°
6:00 PMReturn home71°
10:30 PMSleep68°
Save Schedule
Home
Schedule
Reports
Settings
Schedule
Written in life, not in calendar

Scheduling scored 4.48 out of 5 in the survey and was simultaneously the loudest complaint in the open-ended responses — a satisfied majority hiding a badly frustrated minority. The old version buried it in a multi-layer calendar where users had to guess how weekly and monthly differ. Here the schedule is anchored to life events — wake up, leave home, return home, sleep — with the time and the temperature on the same line.

Traces to Round 1, Theme 2: scheduling is valued but its interface confuses · survey's #1 recommendation
9:41▮▮▮ ᯤ ▬
Smart Report
Floor 1 Thermostat ⌄
Home Data Energy Savings
Daily Weekly Monthly
Energy Efficiency Score
Top
25%
Your household saves more energy than 3 out of 4 neighboring homes.
Runtime savings comparison
Your home16%
State avg10%
National avg8%
Home
Schedule
Reports
Settings
Reports
Pulling the best feature out of the inbox

Energy reports are the strongest behavior driver in the survey (51%) and simultaneously carry the highest non-use rate (15%). The old version emailed you a CSV — you had to leave the app to read it. Here it lives inside the app with a neighborhood comparison, and the clinical name “Data Reports” became “Smart Report,” a rename participants proposed themselves.

Traces to Round 1, Theme 5: energy reporting is a welcome surprise, buried too deep · competitive analysis: Honeywell's neighbor benchmark
9:41▮▮▮ ᯤ ▬
Troubleshooting
Having trouble connecting?
We'll help you get your device online. Choose the issue you're experiencing below.
COMMON ISSUES
QR code not working
Wi-Fi connection
Device not found
Try Again
Contact Support
Troubleshooting
Making the phone call the last step, not the first

This is the screen I care most about. The old app returned a code when connection failed — thermostat, router, internet, phone, and it never said which link broke. Here the failure is split into three symptoms a user can recognize as their own, and “Contact Support” sits at the bottom in the lightest possible treatment: still there, no longer the only way out.

Traces to Insight 02 · Round 1, Theme 8: every participant treats calling support as a last resort

What testing overturned

Round 1 produced 9 themes, 6 pain points and 8 design opportunities. These five are the ones that actually changed the design — not the ones confirming we were right, the ones telling us where we were wrong.

01
Almost nobody knew what “geofencing” meant

The most consistent finding of the round: nearly every participant failed to recognize the word. They tried Auto first, then scheduling, then settings, and eventually found it by elimination — it carried the longest task times in the study. Once explained, everyone liked the feature. The problem was never the feature; it was the label. We renamed it “Away mode” and gave it a scenario line.

02
The Bluetooth permission made a promise we didn't keep

Granting Bluetooth created a firm expectation that the device would now connect on its own. When Wi-Fi configuration appeared afterwards it felt jarring and disconnected from what came before. The sequence itself communicated the wrong mental model — so we moved Wi-Fi up to be introduced alongside Bluetooth.

03
Users go to Settings to troubleshoot, not to Help

When a device went offline, every participant's first move was Settings. In their model, Settings is where you manage the device and Help is where you find a phone number. We had put troubleshooting under Help; this finding moved it. Separately, the help button itself was too quiet — visually identical to its neighbors, and a stressed user is the least likely to search carefully.

04
The QR scan tripped up almost everyone

People's prior experience with QR codes is that scanning opens a web page, not that it searches for a nearby device. On failure they couldn't tell whether it was their error, the distance, or the app. The interesting part: the recovery flow itself was fine — once troubleshooting options were visible, nearly everyone resolved it. What was missing was expectation-setting before the scan.

05
Everyone skipped the optional steps

Anything marked optional during setup — scheduling, away mode, energy alerts — got skipped by every participant, with the same reasoning: it isn't needed to use the thing, I'll come back to it. They don't come back. So we moved the explanation to the moment of use: the app now surfaces a short, dismissible introduction the first time someone actually opens a feature — so skipping it during setup no longer leaves them stuck later.

Round 2 · what actually happened

Remote and unmoderated on the high-fidelity prototype through Optimal Workshop — 10 tasks, numbered to match Round 1.

5
Participants
15:13
Average session
10
Tasks
2
Parts: new / returning
Resolved
The rename worked, almost too well

In Round 1, not one participant understood “geofencing.” In Round 2, before they ever saw the screen, 5 of 5 named the feature “Away” or “Away mode” unprompted, and 5 of 5 found the label immediately clear once they reached it — one describing it as better than expected, another as exactly what they thought it would be called. The cleanest before/after in the dataset.

Partly — and the useful one
I fixed the word and left the place alone

Same feature: 3 of 5 still went hunting through Settings first and only came back to the home screen after failing; 2 of 5 missed it entirely on the first pass, one of them detouring into accessibility options. One called it clearly the hardest step of the session — it simply did not click. A rename solves a vocabulary problem. It does not solve an information-architecture problem — and I had assumed the label was the whole failure.

Not resolved
Pairing is still the worst task in the study

QR scanning failed or was unavailable for 3 of 5 — in one session no QR code appeared at all. When the device wasn't found, 4 of 5 expected the app to walk them through recovery. It didn't. 3 of 5 retried in a loop rather than looking for in-app help, and 2 of 5 showed open frustration. The troubleshooting screen I was proudest of does work — once it is found. One participant only got there because an alert pushed them.

What did land
Wi-Fi setup — the cleanest task in the study 5/5
Interface behaved as expected, labels clear 4/5
Went straight to Reports for energy data 3/5
Persistent “?” icon recognized and valued 3/5

Worth noting: we changed nothing about the Wi-Fi step. It was the smoothest flow in Round 1 and stayed smoothest in Round 2. It became the ruler — the level of clarity every other flow was measured against.

Two results I can't call yet
1
Scheduling: the data contradicts itself

In the same report, 3 of 5 described schedule setup as clear and intuitive while 3 of 5 hesitated or backtracked at event creation — one cycling aloud between “create event” and “create schedule,” unable to choose. The honest read: improved enough that everyone got through it, not enough to call it resolved.

2
Swipe to set temperature: 4 of 5 rejected it

Four participants abandoned swiping for tapping, citing imprecision. But I won't write this up as a finding: the study ran on desktop with a mouse — judging a gesture designed for a thumb by how it feels under a cursor proves nothing. This one needs a re-test on a real device.

Back to the original question
Would the app reduce the need to call support?

This was the project's starting point — Round 1's central insight was that when something fails there is no path but the phone. We asked everyone at the end of Round 2. Three of the five gave specific, attributable reasons: clear labels, being able to find features unaided, and in-app troubleshooting offering enough options to handle it themselves. One described support as a last resort for drastic hardware failures only, with the app handling everything else. No participant expressed the opposite view. The one reservation came from another participant, who named scheduling as the place he might still want help.

One note: Optimal Workshop's auto-generated summary claims all five, while the itemized evidence beneath it covers three. I report three. A tool's AI summary is a lead, not a finding — copying one straight into a report is a habit this year taught me to distrust.

The limits of this data

n = 5, unmoderated. That size validates whether a specific fix landed. It does not discover new problems — with no moderator to probe, you see the hesitation but never the reason behind it.

The two rounds tested different fidelities. Round 1 was lo-fi; Round 2 was hi-fi. Every cross-round comparison therefore carries fidelity as a confound — we cannot separate how much of the improvement came from the design and how much from it simply looking real.

The planned quantitative comparison never materialized. We intended to compare success rate, time on task and drop-off against Round 1 by task number; what came back was qualitative observation and session counts. Every x of 5 above is a session count, not a task success rate — and it is the thing I most want to fix about this round.


Built on the brandbook, not around it

Core palette · 2024 Braeburn Brandbook
Shadow#000000
Midnight#0D254B
Electric Blue#3A609C
Cool Blue#39A1DA
Light Gray#E5E5E5
White#FFFFFF
Semantic tokens · light / dark
feature/heating#C2410C · #FF9A5C
feature/cooling#007C8A · #49D3DE
status/success#0C8850 · #4FD19A
status/error#DD1111 · #FF7B7B
Approved gradients (these six only)
Midnight → Electric Blue
Shadow → Midnight
Cool Blue → White
Cool Blue → Electric Blue
Electric Blue → White
Shadow → White

The constraint is the point. The brandbook defines six core colors and no status or feature colors at all — so heating, cooling, success and error are tokens we added on top of it, each with a light and a dark value and a contrast check. What the client received was therefore not a new visual language competing with their own, but a legitimate extension of an existing brand asset — which is what determines whether it actually gets adopted.


What this project taught me

Ask the right question, not more questions

The client had extensive market research, all of it answering why people buy. Our 103 responses asked what happens after they buy, and when they give up. Sample size was never the constraint — the framing was.

Knowing which method to skip

We deliberately dropped the cognitive walkthrough. With a full redesign already decided, two weeks validating a flow we were about to delete would have come straight out of the design work. Methods exist to answer questions, not to prove the process was complete.

Give the client room to choose

The mild / medium / spicy format was the most effective communication move of the project. It reframed “can you accept this” into “how far do you want to go” — the bold option made the middle one feel safe, and the client volunteered their own resource constraints as a result.

Great support is a bill, not a feature

Users could name Braeburn's support reps and cited them as the reason for their loyalty. It reads as a strength, but every one of those calls corresponds to something the product failed to resolve on its own. I learned to read what users praise separately from what the product owes.

Let's talk

Let's build something good

miragew13@gmail.com
Work SoftSignal Contact