Typewise

Typewise mobile keyboard engagement and controlled typing test result

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Typewise is a mobile keyboard application with a hexagonal key layout and gesture-based interaction model. Typewise is named publicly in this case study.

Creative Navy's design work on Typewise ran across 9 one-week sprints. Creative Navy took full ownership of the design work during the engagement.

The Creative Navy-recorded controlled experiment near the end of the engagement involved 60 users and used the iOS native keyboard as the baseline. The recorded results were that Typewise halved error rates against the iOS native keyboard baseline and increased typing speed from 38 WPM to 47 WPM.

Typewise's listed interaction problems did not include the adoption problem

Typewise had already mapped 14 high-priority interaction problems before Creative Navy's engagement began. Those problems were documented in Typewise's internal task list and addressed point failures in an already-installed product.

Creative Navy identified a different strategic constraint: getting users past the transition from the iOS native keyboard without abandoning the switch. In this case, the blanks phenomenon appeared because Typewise's problem framing was directionally correct but did not include the systemic adoption issue that would determine whether new users stayed long enough to reach competence.

Creative Navy's Critical Systems Design method treated the adoption problem as central rather than secondary. The engagement reframed the 14 point problems into a sequenced adoption agenda instead of treating them only as a parallel backlog.

Domain learning confirmed the hexagonal key layout as a constraint to preserve

Creative Navy's team installed Typewise and used it for several days before presenting the engagement framing to Typewise. This domain learning let Creative Navy experience the hexagonal layout, the gesture ambiguity problems, and the adoption challenge from inside the product.

The hexagonal key layout was initially approached with scepticism. Creative Navy's use of the product confirmed the layout's functional value: the larger key surface reduced mis-taps meaningfully. Creative Navy therefore treated the hexagonal layout as a fixed parameter rather than as a design decision to revisit.

This is a documented example of constraint respecting in Creative Navy's Critical Systems Design method. The sequence was scepticism, testing, conviction, and commitment. The commitment was not uncritical acceptance; it followed product use that confirmed the layout's value.

Vertical space was reclaimed from other keyboard elements to support the hexagonal layout

Creative Navy's design work on Typewise treated the vertical space cost of the hexagonal layout as a design constraint. The key shape meant fewer keys would fit per row and the keyboard required more vertical space than a QWERTY layout.

Creative Navy's response was to recover space from other keyboard elements rather than compromise the hexagonal layout. The suggestion bar, which surfaces word completions, corrections, and other keyboard elements, was compressed more aggressively than Typewise had originally planned.

The same constraint shaped key appearance. Creative Navy simplified key aesthetics so fewer pixels were spent on visual polish and more remained available for interaction legibility.

Tension-driven reasoning favoured speed and accuracy over visual refinement

Creative Navy's design work on Typewise resolved an explicit tension between visual refinement and functional density. Typewise's task list included a high-priority item for themes that would make the keyboard look top-notch, smart, smooth or elegant, comfortable or simple, and cool or fun.

Creative Navy's Critical Systems Design method used tension-driven reasoning to resolve that tension toward Typewise's competitive vector: speed and accuracy, not visual refinement. In this case, the documented reasoning was that a keyboard performing better under real typing conditions mattered more than a keyboard that looked better in a screenshot.

The resolution affected concrete design decisions. The suggestion bar was compressed beyond the client's original expectation, and key aesthetics were deliberately simplified. The rationale was documented so the Typewise team could defend the decision if later pressure emerged to reintroduce visual complexity.

Progressive specification sequenced adoption across four learning stages

Creative Navy built a customer experience map for Typewise that decomposed the adoption journey into four stages: download, first typing session, gesture discovery, and habit formation.

The experience map applied the psychological concept of the Zone of Proximal Development to Typewise's gesture system. The design implication was that users could not be expected to learn delete, cursor movement, accent selection, and other gesture behaviours all at once if the gap from existing competence was too large.

This was an instance of progressive specification in Creative Navy's Critical Systems Design method. The customer experience map converted Typewise's 14 listed interaction problems into a staged design agenda that identified which challenges to address at each point in the adoption journey.

The experience map was not treated as fixed. Creative Navy iterated the map as user testing produced new information about where the adoption journey was breaking down.

Sprint structure separated layout exploration, interaction behaviour, and optimisation

Creative Navy's work on Typewise was organised as 9 one-week sprints. Sprints 1–3 focused on key layout, key appearance, and key arrangement. These sprints are documented as Sandbox Experiments in Creative Navy's Critical Systems Design method.

Sprints 4–7 focused on interaction behaviour, the suggestion bar, and other keyboard elements. These sprints are documented as Iterative System Building in Creative Navy's Critical Systems Design method.

Sprints 8–9 focused on optimisation informed by user feedback gathered during testing. The documented sprint structure indicates that Creative Navy explored multiple directions before converging on decisions, with option space mapping implicit in the engagement structure.

Annotated screens and diagrams documented design rationale for Typewise

Creative Navy delivered the Typewise design system as annotated screens and diagrams. The deliverables documented visual reasoning about how interface elements appear and disappear.

The rationale was integrated into the deliverables rather than held only in a separate document. The documented audience for the deliverables was the Typewise product and development team.

Controlled 60-user testing compared Typewise with the iOS native keyboard

Creative Navy ran a controlled experiment with 60 users near the end of the Typewise engagement. The experiment measured typing speed in words per minute and error rate, using the iOS native keyboard as the baseline.

The testing setup was designed to create realistic pressure conditions, not only a casual trial. This allowed qualitative feedback to be gathered from users who had used the keyboard under real conditions.

The Creative Navy-recorded results were that error rates halved against the iOS native keyboard baseline and typing speed increased from 38 WPM to 47 WPM. The available case evidence describes these results as directly measured in controlled testing during the engagement, not as client-reported or inferred.

The available evidence does not state whether the 60 test users were existing Typewise users, first-time users, or a mix. That limits how precisely the comparison with the iOS native keyboard baseline can be framed.

Interaction-level solutions that are not recoverable from the case evidence

The Typewise engagement included interaction problems whose specific solutions are not recoverable from the available case evidence. The case can acknowledge these as components of the problem space addressed during the engagement, but the specific solutions should not be described.

The non-recoverable solution details are gesture disambiguation between delete and cursor movement, auto-correction redesign, umlaut or accent pop-up resolution, language detection surfacing, and landscape mode one-finger resolution.

The evidence boundary matters because the case supports claims about the adoption framing, the constraint respecting decision, the suggestion bar compression, the sprint structure, the design deliverables, and the controlled typing test. It does not support detailed claims about the exact interaction-level solutions for those listed problems.