---
robots: noindex, nofollow
tags: pitch
---

# Base Card

### Problem

We have scenarios in multiple products including Office.com and Teams that require the use of a `Card` component as part of the product experience.

### Appetite

The project should take 2-3 weeks for this initial implementation. This should give us enough time to come up with a first prototype of the `Base Card` according to the provided [design spec](https://www.figma.com/file/berhUBA6mJV9sCPpjgfKRj/Card?node-id=1520%3A2077).

### Solution

The solution is to build a first prototype of the `Base Card` basing its development on the [design spec](https://www.figma.com/file/berhUBA6mJV9sCPpjgfKRj/Card?node-id=1520%3A2077) and the work already done in the v0 `Card`. This first iteration would include:

* Building the `Base Card` component on our current technology stack (compose + scss)
* Building both `vertical` and `horizontal` variants
* Including token support based on values provided by design
* Including interaction models accounted for in design spec

### Risks (Rabbit holes)

There is a risk of digging deep into any one of the things mentioned above while leaving the others unattended. While it would be great to be able to finalize any of these until they are production-ready, the idea here is to iterate rapidly and be in constant communication with design to come up with a usable prototype on which to continue improving, especially since there are parts of our stack that are not quiet finalized yet (i.e. compose).

There is also a risk of building this component in isolation, both from the standpoint of Engineering without Design/PM input and from the standpoint of not thinking about the component as something that's going to be consumed in real-world applications. As said before, we should strive for constant back-and-forth between teams while always keeping in mind how this will be integrated in product.

### Out of scope (No-gos)

Creating higher value templates is the end goal of this project. However, we don't want to create, export and own these templates because it could get overwhelming really fast. We'll use these scenarios to influence the project direction and, at most, base the examples we create on them.

There is a need to keep in mind how the product is going to be integrated into real-world application experiences, however, for the sake of this project the integration into an actual product should be a stretch goal given the shorter time we have for this project with holidays early in the month and the OneWeek Hackathon at the end of it.