Writing Guidelines

Writing is part of the product experience. It shapes how people understand Corvus, learn it, navigate it, and know what is happening as they work. Writing requirements establish how language should make Corvus clearer, more predictable, and easier to use.

Human

Writing is for humans. There is always a person on the other side of our words, and we should write with respect for their intelligence, attention, time, circumstances, and emotions. Whether we are naming a tool, explaining an error, documenting a feature, answering a support request, or writing the website, we should think first about the person reading it and what they need from us in that moment. Human understanding is our north star.

Terminology

Corvus should use clear, precise, and consistent terminology throughout the product. A concept should have one name wherever possible. Terminology inherited from existing software should be questioned rather than automatically adopted. The words we choose should reflect how people understand their work.

Naming

Names should make things easier to understand and remember. Features, tools, objects, settings, and concepts should receive names that communicate what they are without requiring unnecessary explanation. Cleverness, jargon, and historical convention should never come at the expense of clarity.

Voice and Tone

Corvus should communicate like a capable, thoughtful, and respectful collaborator. Its language should be clear, calm, concise, direct, and human. Personality should come through naturally without getting in the way of the work.

Accessibility

Corvus should communicate as plainly as the subject allows. Understanding the product should not depend on deciphering unnecessary jargon, insider terminology, or needlessly complicated prose. Technical precision and accessible language should reinforce one another rather than compete.

Interface

The words people encounter while using Corvus should make the product easier to operate. Buttons, controls, menus, labels, settings, prompts, and other interface language should communicate purpose clearly and concisely. People should rarely have to interpret what a control means before using it.

Commands

Commands should be concise, predictable, and easy to remember. Related actions should follow consistent naming patterns so that learning one command helps a person anticipate others. Command language should support speed without sacrificing comprehension.

Feedback

Corvus should communicate the meaningful consequences of a person's actions. Feedback should confirm what happened, reveal important changes, and help people maintain a clear understanding of the state of their work. It should provide reassurance without becoming distracting.

Status

Corvus should communicate important system activity without requiring people to wonder what is happening. Saving, syncing, processing, reconnecting, waiting, completing, and failing should be made visible when that information matters. The language should communicate state without exposing unnecessary technical complexity.

Warnings

Warnings should appear when a person is about to take an action with meaningful consequences. They should explain the consequence clearly enough to support an informed decision. Warnings should be reserved for situations that genuinely deserve interruption.

Errors

Errors should explain what went wrong in language a person can understand. Whenever possible, Corvus should also explain what can be done next. Error messages should help people recover rather than merely report that something failed.

Onboarding

Onboarding should help people become productive quickly without requiring them to study Corvus before using it. New concepts should be introduced in context and close to the moment they become useful. The product itself should carry much of the responsibility for teaching people how it works.

Help

Help should answer the question a person actually has and get them back to their work quickly. Guidance should appear in context when possible and provide additional depth when needed. People should not have to search through extensive documentation to understand ordinary product behavior.

Documentation

Documentation should provide a clear and trustworthy explanation of Corvus. It should describe how the product actually works, use the same terminology as the product, and remain current as Corvus evolves. Documentation should provide depth without becoming a substitute for an understandable product.

Marketing

Corvus is writing for a sophisticated, discerning, and often incredulous audience. Architects, designers, and engineers have heard ambitious promises from software companies before, so our marketing must earn belief rather than demand it. We should never sound salesy, breathless, exaggerated, or self-congratulatory. We should write with intelligence, specificity, restraint, and respect for the reader, making claims we can substantiate and allowing the strength of the product and our point of view to create conviction.

Support

Support should feel like a conversation with a smart, capable, caring human being. We should write naturally, respond to the person rather than the ticket, and show genuine empathy for whatever brought them to us. Our language should be easy, warm, conversational, and direct, with humor when the moment welcomes it. We should never sound scripted, bureaucratic, defensive, or artificially cheerful. Even when something has gone wrong, talking with Corvus should feel refreshingly human.

Join our waitlist.

You’ve already waited 49 years. What’s another two? AEC professionals have spent decades jumping through hoops and creating workarounds for convoluted software. No one dares to build something that will challenge the status quo. It's time for something fundamentally different and unapologetically human. Join the waitlist.