6.4 KiB
| title | sidebar | showTitle |
|---|---|---|
| Working with Design | Handbook | true |
Design is currently a shared resource at PostHog. This explains what we do, our design process, and how we can assist across the PostHog team.
Design's Role at PostHog
- Support Small Teams (and contributors) in building better versions of PostHog
- Enable customers to build better products (using PostHog)
- Communicate to prospective customers the value we provide
Tangibly, we:
- Initiate new projects to support the roles listed above
- Support Small Teams in completing their sprint tasks
- Iterate based on feedback from customers
Our Process
Design tasks are managed with our GitHub Org project, otherwise known as our Design Board. This aggregates design-related tasks from the main three repositories for the company:
- PostHog app - open source repo
- posthog.com - website + docs
- Internal - higher-level company strategy
How Our Design Board Works
Cards generally move from left to right.
- Backlog - Things on our radar, and where triaged requests will land unless they're urgent enough to pick up immediately
- This week - Equivalent of our sprint
- In progress - Tasks we've started but haven't completed
- Awaiting implementation - In development or in review
- Done - Shipped! 🚀
Design Request Process
Since design is currently a shared resource, the best way design requests can be handled is by creating an issue in the relevant repository, then adding to the Design project.
After triaging, the Issue will appear in our GitHub Org project where we manage our current design projects.
The following details will help us triage incoming requests:
- What do you need designed and why?
- What is the deadline?
Note: We may defer some design requests if we're planning a larger overhaul in the near term. For example, if a request is to create an icon, we may suggest an alternate solution (like pulling an icon from The Noun Project) if we have a larger plan for revamping all icons in a section in the near future.
When to Loop in Design
Because we hire self-starters, there is no expectation that every project should start by running through design first.
Depending on your preferred workflow, there are different ways we can get involved.
When looping in design, be sure to reference a GitHub issue so we have full context of the problem. Threads should primarily be kept on GitHub. (If an Issue is time-sensitive, mention the Issue on Slack in #design-feedback.)
The scenarios below largely pertain to work on the main PostHog app.
If you built something and just need some polish...
Feel free to share a link (or screenshot) of what you've built. We can provide UX or design feedback for your consideration.
If you built something and realize it needs some UX love...
Share a link (or screenshot) of what you've built. Depending on the state of the project, we can either go back to the wireframe stage to rethink some things, or figure out a phased approach to incremental improvement.
If you designed your own wireframes or mocks...
Sometimes if you have domain knowledge or have been thinking about a project for a while, it might make more sense for you to start the design process. Feel free to share with us for a second opinion, or if you think certain UIs or flows are suboptimal.
If you'd like some design help before you break ground...
More like a typical product development process, please share the high level goals or spec, or any other documentation you have about a feature or enhancement. Be sure to specify the line between MVP and nice-to-haves.
Need help brainstorming a flow?
Provide as much documentation about the goals of the project. Depending on the project, we may be able to sketch out some ideas and share in the GitHub issue.
In some cases, it may make sense to jump on a Zoom to sketch out some ideas together.
Sharing work in progress
We often share designs in early, unfinished phases. Since our audience is developer-friendly, we have a built-in audience to gut check our designs and solicit feedback.
When providing feedback, it's worth keeping in mind the level of fidelity of the mockup we're sharing for feedback.
Wireframes
If an early draft is being shared, we'll build a wireframe in Balsamiq. At this stage, we're mostly focused on laying out content, crafting messaging, and loosely tying in a visual hierarchy and layout. (Don't look too closely at fonts, specific colors, or visualizations - those come later.)
Note: Balsamiq uses its own Comic Sans-style font. Don't get hung up on this!
Mockups
Once a design is laid out, we'll move into hi-fidelity mockups built in Figma. This process usually takes a few rounds to perfect, and we often iterate up until the moment the design is passed off for development.
Providing feedback
We typically share links to mockups in the relevant GitHub Issue.
When we share a design, we do our best to explain the type of feedback we're looking for. (Ex: Overall visual aesthetic, flow, if a design communicates to our developer-focused audience, etc.)
Our main design tools, Balsamiq and Figma, both have built-in commenting. If your feedback is specific to an element on the page, please leave a comment inside the app's comment system. This helps us review and take action on comments later.
If your feedback is higher level, summarize your feedback in the GitHub Issue itself for a higher-level discussion.
Slack
We often use the #design-feedback Slack channel to share updates when we're particularly interested in feedback. We'll always link to the relevant place for discussion. (It's best to keep direct feedback off of Slack.)
This Slack channel isn't limited to the design team. If you're looking for a second opinion on the UX of something you're building, we encourage anyone to share screenshots and a link to Figma or wherever the mockup was produced so we can provide useful feedback or assist in iterating on a design.
If the design requires further collaboration, create an Issue.