“{children}”
{who}
{translation ? {translation}
: null}
“{children}”
{summary}
: null}{summary}
: null}{summary}
: null}{summary}
: null}{summary}
: null}{summary}
: null}
Completing a chapter drops a traditional Miskito tale into the Galería. Each tile carries its Miskitu title above its Spanish one, the bilingual rule held even at thumbnail scale.
Inside an unlocked tale, the Miskitu original runs alongside its Spanish translation, never stripped, never hidden, the layout Scott Woods asked for explicitly. The same page, transcribed:
Tilam pirka kum kan, ai aisan pram. Kan, kan, kati naha tasba ra. Tilam ba kumi pri taim, kumi pri taim, lalka pruna ai aisan kaikbia.
Tilam ba taim, taim, kati ai upla nani ra wal aisan: “Yang ba pâs lula, yang ba sa.”
Upla nani ba pain laikan; tilam ai aisan ba kaiki sin.
Había una vez un sapo muy orgulloso. Vivía, vivía, en esta tierra. El sapo, cuando saltaba una vez, cuando saltaba dos, levantaba la cabeza para que su voz se escuchara.
Cuando el sapo cantaba, cantaba, le decía a su gente: “Yo soy el primero, yo soy.”
La gente lo miraba con paciencia; al sapo le bastaba ser escuchado.
Miskitu is spoken by roughly 190,000 people in the Moskitia, a region spanning eastern Honduras and Nicaragua. UNESCO loses an indigenous language every two weeks, and Miskitu is on that trajectory. The few digital tools that exist for it, a community-built dictionary and a Bible translation, haven't been updated since 2021 and don't support structured learning.
I wanted to design something better. But the more I tried to research the language, the more I realized how invisible it is online.
Search "Miskitu dictionary" or "Miskitu online course" and you find almost nothing. The dictionary itself exists, written by Professor Scott Woods and used in Honduran schools, but a dictionary teaches you words, not how to actually speak. There's no Duolingo equivalent, no YouTube curriculum, no Reddit thread breaking down grammar.
That meant almost everything I learned about the language came from people, not from the internet. Specifically two people: Wildres Woods, a Miskito biologist and cultural promoter from the Moskitia, and Professor Scott Woods, the author of the dictionary that essentially defines how Miskitu is taught in Honduras. The project lives or dies on those conversations.
What drew me to Duolingo as a reference was its gamification. Streaks, points, unlockable content, bite-sized lessons; it's the most successful language learning loop ever built, and ignoring it would have been a mistake.
But early in the project, Wildres said something that reframed the entire design problem:
Miskitu was never meant to be learned through written drills. It's transmitted through oral storytelling, mostly animal fables passed between generations. A pure Duolingo clone would teach the vocabulary and miss the language.
The real design problem became: how do you keep what makes Duolingo work, the gamified loop that gets people to come back, but build it around oral tradition instead of around streaks and points?
With almost no online material to work from, the research happened in three places: two long conversations with Miskitu experts, a comparative teardown of Duolingo and Miyotl (a Mexican app for indigenous Nahuatl), and a focus group with five people who had real personal or professional reasons to want to learn the language.
Wildres Woods grew up in the Moskitia and works in conservation biology in the region. A few things she corrected me on immediately: the language is properly written "Miskitu," not "Miskito" (Miskito refers to the people). The alphabet doesn't use C, Ñ, Q, or O; words written with C or Q in Spanish become K in Miskitu. And most importantly, the language is taught through animal stories, fables passed between generations, not through structured grammar lessons.
This is the insight that ended up driving the entire reward system in the app.
Wildres connected me to Professor Scott Woods, who wrote the canonical Miskitu dictionary used in Honduran schools. His teaching method is progressive: words first, then phrases, then sentences. He recommended against starting with grammar, that any Miskitu content be presented bilingually with Spanish alongside it, and that traditional stories be included as part of the learning, not as decoration.
Three concrete design decisions came directly from that conversation: lesson hierarchy, bilingual story layout in the Galería, and the decision to use story unlocks as the core reward loop instead of points or streaks.
I tested the prototype with five participants: a shark conservationist working in the Moskitia, a nutritionist who runs medical brigades there, and three people interested in indigenous language preservation more broadly. The clearest signal was about tone. Multiple participants compared the aesthetic to Animal Crossing unprompted, and described the app as calming rather than pressuring.
That comparison mattered. The other reference loop works through urgency (the streak, the owl, loss aversion). The Miskitu project couldn't take that approach without breaking the cultural mood. The unprompted Animal Crossing reaction told me the aesthetic was doing what I needed it to do: feel inviting and unhurried, the way oral storytelling itself is unhurried.
The strongest single design decision in the project is one I almost don't want to call a design decision: I chose not to commission or generate new illustrations. The entry screen uses an 1894 engraving from Popular Science Monthly, "Indian hut at mouth of Rama River," in the public domain. The story covers in the Galería are from Cuentos Misquitos, Miskitu Kisi Nani, a 1985 storybook published by CIDCA, a Nicaraguan research institution, as part of their project El rescate de la tradición oral y la narrativa miskita.
Using these materials wasn't a shortcut, it was the point. A 1894 ethnographic engraving, a 1985 community preservation effort, and a 2025 digital revitalization sit in a single visual line, and the case for the project is essentially: this work has been ongoing for over a century, and digital is just the next medium for it.
The palette (cream and olive) and the typography (a heavy display sans paired with restraint everywhere else) were chosen to do as little as possible. The voseo Spanish ("Descubrí," "Aprendé," "Accedé") is a small but deliberate localization choice; this is a Central American product for Central American users, not neutral pan-Latin Spanish.
The six lessons (Saludos y Presentaciones, Familia, El Cuerpo Humano, La Naturaleza y El Clima, Salud y Emociones, Vida Cotidiana) follow Scott Woods's recommended sequencing for new Miskitu learners. Each lesson contains chapters, and each chapter contains questions that progress from single words to phrases to full sentences, exactly the order Woods uses in his classroom teaching.
This is the part of the project that most directly inherits the gamified-learning structure, and that's deliberate. The lesson-chapter-question hierarchy is one of the things gamified apps actually get right; it's familiar to anyone who's touched a language app. There was no value in being clever here.
The prototype includes five question types, each doing different pedagogical work:
The decision worth naming is the inline correction model: when you get an answer right, the screen confirms with a short bilingual explanation ("Yamni sna significa estoy bien"). The dictionary teaches you words; the inline correction teaches you what the words mean in context.
This is the design move the whole project is built around.
The reference loop works on urgency: streaks, daily reminders, the mascot, the dread of losing your XP. Extraordinarily effective, and the obvious thing to clone. But the source material refused it. Miskito oral tradition is unhurried, conversational, intergenerational. A streak-based product would have pulled against everything the cultural research surfaced.
So the reward isn't a streak. It's a story.
When you complete a chapter, you unlock a traditional Miskito tale from CIDCA's 1985 collection: El Sapo Orgulloso, La fábula del Tigre y el Conejo, El Relámpago y el Trueno. The stories live in your Galería, and you can return to them anytime. The gamification loop, complete a unit, get a reward, want to come back for more, is still there. What's changed is what counts as a reward: the cultural content the app is trying to preserve. The reward IS the mission.
Guest mode. The Inicio screen offers "Iniciar Sesión," "Registrarse," and "Continuar como Invitado." Email access is uneven in the Moskitia; gating the app behind an account would have excluded part of the audience the project is supposedly for. Guest mode means anyone with a phone can use the app, full stop.
Bilingual story layout. Inside each unlocked story, Miskitu sits on the left, Spanish on the right, side by side. Scott Woods recommended this explicitly: never strip the Miskitu, never hide the translation. The two languages should be visible to each other on every page.
Audio everywhere. Every question type that involves a Miskitu word includes audio playback. Miskitu has phonemes Spanish speakers haven't been trained to hear, and visual transcription alone won't teach pronunciation. The audio module is currently a placeholder; in the real version, recordings would be done with native speakers from the Moskitia.
The testing was with learners, not native speakers. Five Spanish-speaking adults with reasons to learn Miskitu, not five Miskito speakers from the Moskitia. That's a meaningful limitation. The app is designed for, and validated by, non-native learners. Whether a native Miskitu speaker, especially one strengthening their own language rather than acquiring it, would experience this app the same way is genuinely an open question, and the most important thing to test next.
The audio is a placeholder. Every "Escucha el audio" screen currently uses stand-in audio. A real version needs recordings with native speakers from the Moskitia, ideally with regional variation. Both collaborators offered to continue; the practical next step is going back to them to record.
The story library is finite. The Galería currently draws from CIDCA's 1985 collection of six stories. That's a starting point, not a corpus. A sustainable version of this app would partner with community elders to record and add new stories over time, the way the language itself is transmitted: as a living tradition, not a closed archive.
The Miskitu-first version doesn't exist yet. Everything assumes the user is coming from Spanish. The harder and arguably more important version of this app would invert that: a Miskitu-first interface for young people in the Moskitia who already speak the language at home but lose it in Spanish-medium schools. That's not a redesign, it's a different product, and it's probably where the real preservation impact would happen.
The prototype is a prototype. A Figma file with a clickable flow, not an app you can download. The budget and roadmap for a real build are documented in the thesis. Turning this into a published iOS or web app would need either institutional backing (UNESCO, an NGO working in the Moskitia, the Honduran Ministry of Education) or open-source contributors.
The hope is that this prototype is useful enough to invite that next step from someone better positioned to take it.
This project would not exist without them.
Wildres Woods, biologist and cultural promoter from the Moskitia, was the first voice in the research. Her insistence that Miskitu is learned through animal stories, not through drills, reframed the entire design problem.
Professor Scott Woods, author of the canonical Miskitu dictionary, spent an hour walking me through his pedagogy and validating the lesson structure. Every decision about progression and presentation came directly from that conversation.
Adriana Padilla, Ángela Chávez, Ana Paola Arita, and Daniela Valerio participated in the focus group and saw the prototype early. Their unprompted comparison to Animal Crossing was the aesthetic validation the project needed.
The Centro de Investigaciones y Documentación de la Costa Atlántica (CIDCA), and the anonymous community archivist who uploaded their 1985 storybook to Internet Archive, made it possible to source existing cultural materials instead of creating new ones.
Lic. Diana Echeverría, my thesis advisor, kept the project grounded in research and pushed me toward collaborators when I wanted to work alone.
Deaf creators make a lot of video content, but reaching hearing audiences usually means depending on auto-captions that miss tone, nuance, and signed-language register entirely. Voxally turns that into a marketplace: creators upload videos and pay for human captioning and voiceovers; interpreters in ASL and BASL pick up jobs and get paid per minute of work delivered.
The product launched on both app stores in mid-2026.
Voxally was built fast and built unusually. Darrell, the client and CEO, had already scaffolded a working version of the front-end with Claude Code before the Acklen team came on. When the project kicked off, Monique, the dev team, and I all started at the same time, around a codebase that already existed. The product was live in code from day one.
That meant my role wasn't "design the app from scratch." The app was being shipped in real time, by a founder who'd built the first version with AI and a dev team taking it the rest of the way. My role was to be the person reviewing what was being shipped, catching what a fast-moving team would have missed, redesigning the flows that were broken, and authoring the new screens that hadn't been touched yet. Less authorship, more stewardship. Less Figma-first, more "open the live build and tell me what's wrong with it."
This is a working pattern I think is going to become much more common, and Voxally was a useful place to learn how to do it well.
The shipping rhythm at Voxally was daily standups, weekly refinements, and Trello cards moving fast. There was rarely time to mock something in Figma, get feedback, iterate, then hand off. Most of my contribution looked like this: review the live build on a real device, find the thing that didn't work, write up the fix with the reasoning in a Trello card or a Slack thread, and either hand it back to the devs or design the replacement screen if it needed one.
A lot of that review happened in BrowserStack and TestFlight rather than in Figma. I tested every shipped build across iOS and Android phones, plus iPad, because the app needed to work for interpreters using whatever device they had on hand. Most of the issues were caught by actually using the build on a real device, not by reviewing screens in isolation. Tooling matters: a flow that looks fine in a Figma frame can be broken the moment it meets a real screen rotation, a real keyboard, or a real screenshot of a vertical video.
The recording screen, where interpreters record their voiceovers while watching the source video, was forcing every video into a landscape frame regardless of how the creator had shot it. I redesigned the screen to detect orientation and adapt. This is the kind of thing that's easy to miss when you're scaffolding a UI in code without testing it on real content from real users. Exactly the kind of thing a designer is in the room to catch.
The Sign Language Preservation Contributor Project was a feature Darrell wanted in place for a later phase: collecting consent from creators to allow their videos to be used as training data for ASL/BASL AI models. The flow had to be unambiguous (creators needed to clearly understand what they were agreeing to), respectful (the language of preservation matters here, not just compliance), and skippable (creators who didn't want to participate had to be able to use the app normally).
I designed it as a multi-step bottom sheet. The consent step is the only one with a "deny" path; the others are informational. The flow lives outside the main job creation experience so creators who don't engage with it never see it again. This was the most "designer-from-scratch" piece of the project. Everything else was reviewing or fixing; this was a net-new flow.
Two smaller pieces of craft that still mattered for launch. The Voxally logo arrived to me as a PNG, which is a non-starter for app store submission. I vectorized it, then adapted it for the technical requirements of each store: Apple's three-layer Icon Composer format (which renders with the glass material effect on iOS 18+), and Google Play's adaptive icon system.
I also designed the transactional email templates: forgot password, email verification, and job rejection. Trust signals matter most at the moments when users are giving you something. Badly-designed transactional email is one of the fastest ways to lose that trust.
Voxally needed a way for creators to specify what kind of voice they wanted for a voiceover, and for interpreters to indicate what kind of voice they had. The first version of the app used Masculine, Feminine, and No Preference.
My first instinct was to make this more inclusive. The categorization is really about pitch and timbre, not gender, and the gendered framing assumes a binary that doesn't map cleanly to real human voices or real interpreter preferences. I proposed switching to non-gendered descriptors: Lower Pitch, Higher Pitch, Mid Range, No Preference. The same functional groupings, without the assumption.
Darrell pushed back on accessibility grounds, and his point was strong. (See pulled quote above.)
This was a real conflict between two values I care about: inclusive language that doesn't impose gender on voice, and accessibility that meets users where they actually are. Both are correct. They were in tension on this specific feature.
I proposed a compromise: keep gendered options on the creator side (where Darrell's point applies), use inclusive pitch-based language on the interpreter side (where interpreters can self-identify by voice characteristics they actually have access to), and map between them in the backend.
Darrell's final call was to keep gendered language on both sides for now, and revisit during beta testing once we had real feedback from interpreters about what felt right to them. His reasoning was practical: launch with the clearer mental model, gather data from actual users, decide later. The risk of confusing creators at launch was higher than the risk of needing to update copy in a future release.
I disagreed, and I shipped what he asked for.
I think this is worth including in the case study for two reasons. First, because Darrell was right that accessibility for the actual audience has to win over abstract inclusivity. I learned something from being wrong about which value applied. Second, because being overruled by a client isn't a failure mode in senior consulting work; it's the job. The decisions that matter most are ones where smart people disagree, and the discipline is being able to make your case clearly, lose, and ship the better version of someone else's decision without resenting it.
The right time to revisit gendered voice categorization on Voxally isn't in a portfolio essay. It's in the beta data, with real interpreters and real creators saying what works for them.
The UI could have been more distinctive. The app works, it shipped, and the things I changed measurably improved how it feels to use. But if I'd had more time and a different starting point, I would have pushed for a stronger visual identity. The current product feels functionally correct and visually basic. That's defensible for a launch ("ship something legible, iterate from there") but it's not what I'd call the work of someone with strong taste. Voxally needed to ship; that's what it did. Distinctiveness is a v2 problem.
The working pattern is the real story. Going in, I thought a project where the CEO had pre-built the front-end with Claude Code would feel constraining. It didn't. It felt grounding, actually, to see a client this close to the code, and to be in a working rhythm where decisions could happen in a Slack thread and ship the same day. The trade-off is less room for the slow Figma-first design work I love. The reward is that the work that does happen, ships. I came out of this project thinking that "AI-scaffolded codebase with a designer brought in to steward" is going to become a much more common shape for product teams, and the senior design skill on those teams isn't authorship. It's reviewing fast, articulating clearly, and choosing the right hill to die on.
The lost argument mattered more than the wins. The vertical video fix, the icon system, the SLPCP flow: these are the things hiring managers will scan for. But the gender-versus-pitch debate is the thing I'll remember about this project. Not because I was right or wrong, but because it taught me to check whether my instinct for inclusive design is actually serving the user I'm designing for, or whether it's serving a more abstract idea of what inclusive design should look like. Sometimes those are the same. Sometimes they aren't. The discipline is being able to tell which one is happening.
Darrell Utley, founder and CEO, was the closest-to-the-code client I've worked with. The willingness to ship the first version himself, sit in daily standups with the team, and make calls in real time (including the ones I disagreed with) is what made the project move as fast as it did.
Monique Stigter (BA) and Heath Nichols (AM) kept the project organized while the rest of us moved through it. The reason the Trello board functioned at all was them.
Paul Somarriba, Mynor Funes, and Andrés Flores built the app. Most of the changes in this case study are things they shipped from a Slack message or a Trello card; the speed at which design feedback turned into working features on real devices was entirely on their craft.
Acklen Avenue brought me onto the project.
OnePointPartitions sells commercial bathroom partitions: the walls, doors, and hardware that make up restroom stalls in offices, schools, restaurants, and public buildings. Their customers are mostly contractors, facility managers, and distributors who need accurate quotes fast.
The company had an existing quoting tool on their website. It worked, but it looked like it had been built a decade earlier and maintained by a single developer. The flow was long, the interface was cluttered, and 62% of users were trying to use it on their phones, where it barely held together.
Acklen Avenue was brought in to rebuild the tool from scratch. Not a reskin. A full redesign: new information architecture, new design system, new front-end, and a real-time 3D layout builder that would let customers see their partition configurations before requesting a quote.
The project had two distinct phases under separate contracts.
Phase 1 was the quoting tool itself: the customer-facing flow where users select a layout, enter stall dimensions, preview their configuration in 2D and 3D, choose materials and colors, and submit their information to receive a branded PDF quote. This is what most of this case study covers.
Phase 2 was the order management system, and it was bigger than Phase 1 in every way. Where the quoting tool is a single linear flow for one type of user, order management had to serve two audiences (customers and internal sales reps) across a much wider set of tasks.
The core of Phase 2 was a management table where sales reps could track every order by status, with color-coded indicators showing where each order sat in the pipeline. From there, the system branched into a series of specialized forms: delivery information (addresses, unload methods, delivery contacts, installation locations), billing information (with Braintree credit card verification and a separate wire transfer path where customers could upload receipts for manual confirmation), and a drawing review process where sales reps could submit partition drawings for customer approval and signature.
Sales reps could also create orders from scratch, from templates, from blank forms, or for specific needs like hardware-only or payment-only orders. The range of entry points and form types made the information architecture significantly more complex than Phase 1.
I was design lead for all of it. Fernando had left Acklen between phases, so the design direction was mine to own. The foundation we built together in Phase 1 (the design system, the component library, the interaction patterns) is what made it possible to scale into Phase 2 without starting over.
I joined the project from day one alongside Fernando Guevara, another UX/UI designer at Acklen. Together, we ran the discovery workshops with the client, audited the existing tool, and built the new design system, style guide, and full set of Figma flows from scratch.
The work was traditional in the best sense: discovery, audit, information architecture, wireframes, UI design, prototyping, handoff. The dev team built while we designed, and we iterated based on what worked and what broke on real devices. The UX audits of the existing website were primarily my work, and they shaped the structural decisions that carried through both phases.
Everything visual in the new quoting tool came out of the design process Fernando and I ran. The original site had a design language, but it was inconsistent and dated. We kept the brand colors (blue primary, with a secondary palette) and rebuilt everything else: typography, spacing, component library, iconography, interaction patterns. We used ShadCN/UI as the component foundation, built on Tailwind CSS, which kept the design-to-code translation clean and fast.
We restructured the flow into a clear linear progression: select toilets, choose a layout, enter dimensions, review a summary, then submit. The stepper at the top of the screen shows where you are and what's left. Each step does one thing. The goal was to make the tool feel closer to filling out a short form than to navigating a complex application.
We also added an alternative path for customers who already had architectural drawings: a manual upload flow where they could select materials, enter their information, and upload their plans directly. This acknowledged a reality the old tool ignored, that many commercial buyers already know exactly what they need and just want a price.
With 62% of traffic coming from mobile devices, the tool had to work on a phone, not just technically function, but actually feel good to use. This was my specific responsibility on the project.
The hardest part was the dimension entry step. On desktop, you have room for a 3D canvas, input fields, and labels all on one screen. On a phone, that same information has to be sequenced and layered carefully. The 2D and 3D views needed to be toggleable without losing context, and the input controls for stall widths, depths, door swings, and ADA compliance had to be reachable with a thumb.
The material and color selection screens were also challenging on mobile. Partition materials (powder coated steel, laminate, solid plastic, phenolic black core, stainless steel) each have their own color palettes, some with dozens of options. On desktop, this is a grid. On mobile, it needs to scroll cleanly without feeling like a paint store exploded on your screen.
I'm proud of how the mobile flow turned out. It reads as a real product, not a shrunken desktop app.
This was the most interesting design problem on the project. The quoting tool isn't just a configurator; it produces a deliverable. After a customer submits their information, the system generates a branded PDF that serves as the actual quote: room layouts in 2D and 3D (captured as screenshots from the live canvas), material specifications, pricing by room, and customer details. The PDF is emailed to the customer and to the sales team simultaneously.
Designing for print from a web tool is a specific kind of challenge. The UI for the web experience and the layout for the PDF share data but serve different purposes. The web flow is interactive, progressive, designed to guide a user through decisions one at a time. The PDF is a reference document, something a contractor prints and carries to a job site or forwards to a client. It needs to be legible, branded, and dense with information without feeling chaotic.
The first version of the PDF matched the clean, modern look of the web tool. It worked, and it looked professional. In Phase 2, the client requested a redesign of the PDF to match a different visual direction: denser, more information-forward, closer in spirit to a wholesale catalog than a tech product. We delivered what they asked for. The result was functional, but I preferred the original.
Phase 2 was where the design system Fernando and I built in Phase 1 had to earn its keep. The order management table is the center of the experience for sales reps: a single view of every order, color-coded by status, with the entire pipeline visible at a glance. From any row, a rep can branch into a delivery form, a billing form, a drawing review, or the customer-facing approval flow.
The challenge wasn't any single screen. It was making the dozens of screens feel like one product. The component library held up: forms, tables, status indicators, modals, and bottom sheets all carried through from Phase 1 without redesign. Where Phase 2 needed new patterns (the multi-path order creation flow, the drawing approval signatures, the wire transfer receipt upload), they slotted in as extensions of the system, not exceptions to it.
The client had strong opinions about the interface. In particular, he wanted prominent red call-to-action buttons throughout the quoting flow: on continue buttons, checkout steps, and key decision points.
On a product whose entire brand palette is blue, a red button reads as a warning or a destructive action. In most interface conventions, red means stop, delete, or cancel. For a continue or checkout action, it works against the user's instincts.
I pushed back on this multiple times, explaining the convention and proposing alternatives that would be equally prominent without the negative connotation: a high-contrast blue, a larger button size, a different position on the page. The client's concern was valid (older, less tech-savvy users need clear, unmissable CTAs), but the solution he wanted conflicted with the design language we had built.
Some of those battles I won. Others I didn't. The ones I lost, I shipped.
This is a pattern I've seen across consulting work: the client's instinct about their users is often correct even when their proposed solution is wrong. He knew his customers would miss a subtle button. He was right about the problem. We disagreed about the fix. When you're the contractor, you make your case, present alternatives, and then execute whatever gets decided. The work is better when you fight for it, but the relationship is better when you know when to stop fighting.
Every industry has interface problems worth solving. Before this project, I would not have guessed that bathroom partition configuration was a design problem anyone was thinking about. It is. The customers are real, the constraints are specific (ADA compliance, material properties, stall dimension standards, freight weight calculations), and the stakes are commercial. A contractor who can't get an accurate quote on their phone loses time and possibly the job. The domain is unglamorous, but the design work is the same work: understand the user, reduce friction, make the information legible, get out of the way.
The 3D configurator taught me to direct without owning. The Three.js layout builder was primarily an engineering effort. I didn't write the code for the 2D/3D rendering, the camera controls, or the screenshot generation. What I did was direct the visual decisions: colors, angles, label placement, how the models should read at different viewport sizes. This is a mode of design contribution that doesn't produce Figma frames, but it shapes what the user sees. Learning to contribute meaningfully to a technically complex feature without needing to own the implementation was a skill I used again on Voxally and will keep using.
Going from co-designer to design lead changed how I think about ownership. In Phase 1, Fernando and I shared every decision. The design system, the flows, the client presentations: all of it was collaborative. When he left and I took over Phase 2 alone, the scope was bigger, the complexity was higher, and there was no one to check my thinking against. I had to trust the foundation we built and make calls faster. The transition taught me that design leadership on a consulting project isn't about having better taste than your teammate. It's about being willing to hold the entire system in your head, make a decision when the team needs one, and stand behind it when the client pushes back. Phase 2 was where I learned that, and I've carried it into every project since.
Fernando Guevara designed Phase 1 alongside me. The discovery workshops, the style guide, the initial Figma flows: none of that was solo work, and the foundation we built together is what carried the product through both phases.
The development team, scrum master, and BA at Acklen brought the design to life across a complex stack (React, Three.js, NestJS, PostgreSQL, AWS) and kept the build moving through two contract phases.
Acklen Avenue brought me onto the project and gave me the room to grow from co-designer to design lead between phases.
This entry is reserved. The case study template above renders the MiskitApp story in full. The same template will hold this project's content, dropped in section by section, when the case study ships.
The system is content-agnostic, sections can be added, removed, or reordered without breaking the layout. Reusable visual components: full-bleed, side-by-side, three-up, gallery, pull-quote, bilingual two-column.