App Design in Washington

Because the regional standard is high and those teams expect to implement a system rather than interpret screens. Seattle and Eastside engineering teams have typically worked with proper design systems and will find a folder of static comps frustrating and ambiguous — and reasonably so, since it forces them to infer rules from examples and guarantees inconsistency by the fortieth screen. What they expect is design tokens for type, spacing, colour and elevation, every component specified across all its states including loading, empty, error and disabled, documented interaction behaviour, and an interactive prototype demonstrating intent rather than describing it. Engineering should also be involved from the flow-mapping stage, because these teams have strong opinions about what is expensive to build and ignoring that produces designs that get quietly rebuilt during implementation.

Design decisions for wet screens and low light, which are the opposite of what bright-sun markets need. Rain makes capacitive touch genuinely unreliable — wet screens register phantom taps and miss real ones — so primary actions need large, well-spaced targets and destructive actions need to be somewhere a spurious touch will not find them, ideally with confirmation. Low ambient light for months of the year means the interface must be readable without being harsh in a dark environment, which is a different contrast problem from surviving direct sun. Gloved use is common through the wet season too. None of this appears in a usability session held indoors in summer, which is why we test outdoor products in the conditions they will actually be used in.

As full offline operation for extended periods, which is a stronger requirement than intermittent connectivity handling. Washington's outdoor recreation, marine, forestry and rural operations put products in places with no signal for hours or days rather than minutes — so the product has to function completely without a connection, not merely queue a few actions. Practically that means all necessary data pre-fetched before the user leaves coverage, with an explicit and honest indication of what is available offline; every action completing locally; and a sync process on return that handles a large batch of accumulated changes including conflicts. The failure mode we see most is a product designed for intermittent connectivity that assumes reconnection within minutes and behaves badly after eight hours offline.

It raises the value of testing rather than reducing it, because the competitive bar is higher and users have more alternatives. Five users per distinct user type before engineering remains the right investment — severe usability problems are common rather than rare, and five testers will find issues affecting a third of users with high probability. What changes in this market is that stakeholders are frequently more familiar with product process and more willing to fund it, so getting prototype testing into the plan is usually an easier conversation than elsewhere. The caution worth stating is the same everywhere: five users gives you qualitative signal about severe problems, not quantitative confidence about which of two layouts performs better, and treating it as the latter is a genuine misuse.