[doc] create getting started guide for designs
diff --git a/doc/ug/getting_started_design.md b/doc/ug/getting_started_design.md
new file mode 100644
index 0000000..e2cadde
--- /dev/null
+++ b/doc/ug/getting_started_design.md
@@ -0,0 +1,94 @@
+# Getting Started with an OpenTitan Hardware Design
+
+This document aims to clarify how to get started with a hardware design within the OpenTitan project.
+Design in this context nominally refers to a new [Comportable Peripheral](../rm/comportability_specification.md) but can include high level constructs like device reset strategy, etc.
+This is primarily aimed at creating a new design from scratch, but has sections on how to contribute to an existing design.
+It is targeted to RTL designers to give clarity on the typical process for declaring features, finding others to review, etc.
+We aim for a healthy balance between adding clarity while not over prescribing rules and process.
+There are times when a more regimented approach is warranted, and those will be highlighted in this document.
+Feedback and improvements are welcome.
+
+
+## Stages of a Design
+
+The life stages of a design within the OpenTitan are described in the [Hardware Development Stages](hw_stages.md) document.
+This separates the life of the design into three broad stages: Specification, In Development, and Signed off.
+This document attempts to give guidance on how to get going with the first stage and have a smooth transition into the Development stage.
+They are not hard and fast rules but methods we have seen work well in the project.
+
+
+## Concept and RFC
+
+The concept of a design might come from a variety of inspirations: a known required module already slated for future product need; a new design needed for a proposed product feature; an inspiration worthy of being discussed more broadly; perhaps even a new approach to an existing design (higher performance; more secure; etc).
+Regardless of the inspiration, the concept should be codified into a brief proposal with basic features.
+This is as opposed to minor modification proposals to an existing design, which can be handled as a GitHub pull request or issue filing associated with the existing design.
+This proposal should be in **Google Doc** medium for agile review capability.
+Ideally this proposal document would be created in the Team Drive, but if the author does not have access to the team drive, they can share a privately-created document.
+
+Design proposals should follow the recommended [RFC (Request for Comment)](../project/rfc_process.md) process, which handles all such proposals.
+If the RFC may contain certification sensitive material (guidance to be shared), it should be first sent to
+[cert-sensitive-priv@lowrisc.org](mailto:cert-sensitive-priv@lowrisc.org)
+for clearance before sharing more widely.
+The OpenTitan Technical Committee may be able to suggest other collaborators to help with early stage review.
+
+An example of a canonical RFC can be found *here* (TODO).
+
+
+## Detailed Specification
+
+Once past initial review of the feature set and high level description, as well as potential security review, the full detailed specification should be completed, still in Google Doc form.
+The content, form, and format are discussed in the [design methodology](design.md) and [documentation methodology](../rm/markdown_usage_style.md) guides.
+The outcome of this process should be a specification that is ready for further detailed review by other project members.
+The content and the status of the proposal can be shared with the team.
+
+An example of a canonical detailed specification is the pinmux specification which can be found in the TeamDrive under TechnicalSpecifications --> deprecated, for those that have access to that resource.
+(Google Docs that have been converted into markdown on GitHub are archived here).
+
+
+## Specification Publication
+
+Once the specification is published to the wider team, the author(s) need to address input, comments, questions, etc., continuing to hone the proposal.
+Other team members should also feel empowered to help address these questions and feedback.
+It is acceptable to keep an unanswered-questions section of the document and move forward where there is agreement.
+
+
+## Initial Skeleton Design
+
+In parallel with publication and review of the specification, the initial skeleton design can commence.
+There are many ways to get past this "big bang" of necessary implementation and get it through eventual code review.
+One recommended method is as follows:
+* Start with a skeleton that includes a complete or near-complete definition of the register content in .hjson format
+* Combine with a basic markdown including that file
+* Combine with an IP-top-level verilog module that instantiates the auto-generated register model (see the [register tool documentation](../rm/register_tool.md)), includes all of the known IP-level IO, clocking and reset.
+
+This is not mandatory but allows the basics to come in first with one review, and the full custom details over time.
+Regardless the first check-ins of course should be compilable, syntax error free,
+[coding style guide](https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md)
+friendly, [Comportability](../rm/comportability_specification.md) equivalent, etc., as indicated by the [design methodology user guide](design.md).
+
+A good example of an initial skeleton design can be seen in
+[Pull Request #166](https://github.com/lowRISC/opentitan/pull/166)
+for the AES module.
+
+As part of the GitHub filing process, the Google Doc specification must be converted into a markdown specification.
+(Tip: there are Google Doc add-ons that can convert the specification into markdown format).
+Once this is completed, any specifications on the Team Drive should be moved to the deprecated section of the drive, with a link at the top indicating that the document is for historical purposes only.
+This applies only for those specifications that originated on the Drive.
+
+
+## Full Design
+
+As the design develops within the OpenTitan repo, it transitions into "D0", "D1", etc., [design stages](hw_stages.md) and will be eventually plugged into the top level.
+Following the recommended best practices for digestible pull requests suggests that continuing to stage the design from the initial skeleton into the full featured design is a good way to make steady progress without over-burdening the reviewers.
+
+## Top Level Inclusion
+
+Once an IP block is ready, it can be included in the top-level design.
+To do so, follow the steps below.
+
+* Get an agreement on if and how the IP block should be integrated.
+* Ensure that the IP block is of acceptable quality.
+* Ensure that the top level simultion is not adversely affected.
+* Open a Pull Request with the necessary code changes.
+
+If it is not clear on how to proceed, feel free to file an issue requesting assistance.
