diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b35e9b61f..54a258533 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -18,6 +18,7 @@ is via the [Vault Discussion Forum][2].
 ## Issues
 
 This section will cover what we're looking for in terms of reporting issues.
+
 By addressing all the points we're looking for, it raises the chances we can
 quickly merge or address your contributions.
 
@@ -63,6 +64,23 @@ quickly merge or address your contributions.
 
 ## Pull requests
 
+When submitting a PR you should reference an existing issue. If no issue already exists, 
+please create one. This can be skipped for trivial PRs like fixing typos.
+
+Creating an issue in advance of working on the PR can help to avoid duplication of effort, 
+e.g. maybe we know of existing related work. Or it may be that we can provide guidance 
+that will help with your approach.
+
+Your pull request should have a description of what it accomplishes, how it does so,
+and why you chose the approach you did.  PRs should include unit tests that validate
+correctness and the existing tests must pass.  Follow-up work to fix tests
+does not need a fresh issue filed.
+
+Someone will do a first pass review on your PR making sure it follows the guidelines 
+in this document.  If it doesn't we'll mark the PR incomplete and ask you to follow
+up on the missing requirements.
+
+### Changelog Entries
 Please include a file within your PR named `changelog/#.txt`, where `#` is your
 pull request ID.  There are many examples under [changelog](changelog/), but
 the general format is
@@ -85,6 +103,30 @@ You do not need to include the link at the end of the summary that appears in
 CHANGELOG.md, those are generated automatically by the changelog-building 
 process.
 
+### Vault UI
+
+How you contribute to the UI depends on what you want to contribute. If that is 
+a new feature, please submit an informational issue first.  That issue 
+should include a short description of the proposed feature, the use case,
+the approach you're taking, and the tests that would be written.  A mockup
+is optional but encouraged.  
+
+Bug fixes are welcome in PRs but existing tests must pass and updated logic 
+should be handled in new tests.  You needn't submit an issue first to fix bugs.
+
+Keep in mind that the UI should be consistent with other areas of Vault. Our 
+[README](ui/README.md) [has instructions for launching Storybook](ui/README.md#vault-storybook),
+which showcases how we use components. Beyond that, the UI should be user-centered, 
+informative, and include edge cases and errors— including accommodations for 
+users who may not have permissions to view or interact with your feature. 
+If you are not comfortable with UI design, a Vault designer can take a look at 
+your work— just be aware that this might mean it will add some time to the 
+PR process. 
+
+Finally, in your code, try to avoid logic-heavy templates (when possible, 
+calculate values in the .js file instead of .hbs) and Ember anti-patterns. 
+And most of all, if you have any questions, please ask!
+
 ## Setting up Go to work on Vault
 
 If you have never worked with Go before, you will have to complete the