-
CMS
Content management systems are software, usually running on a server, that helps create, edit, and publish (in our context) web pages; ex: WordPress, Wix, Webflow, Cargo. These separate your content from your HTML templates, for easy re-use and structuring, and generate/output pages dynamically.
Relatedly there are static site generators, which run locally to construct sites from content and templates; ex: Jekyll, Hugo, Gatsby, Eleventy. Any website past a single page can benefit from these!
-
Agile
A popular way to structure software project management. Many product teams will use Agile as a way of prioritizing tasks—working in so called sprints (often two weeks) to deliver features incrementally rather than all at once.
One way that Agile is practiced is with a kanban board (from Japanese), a visual way of organizing tasks into discrete phases of work so that team members understand where different stories (or tickets/tasks) are in the queue. Many tools are built around this methodology.
-
Redlining
Often a completed design in Figma isn’t enough for handoff to a developer for implementation. There can be ambiguities in your design that you may have thought through, but need more explanation than the visual on its own. This could be how you expect an element to behave responsively, or maybe you have a specific dimension in mind—some of this is handled by the Inspect panel.
Redlining (not to be confused with its other meaning) is the term for when you mark up or annotate your designs with information—key measurements or other important behaviors/traits. This forms the spec that a dev should implement.
-
Bus factor / bus count
On small product teams, certain individuals may be the only ones who understand how a certain feature works, or is implemented. The phrase bus factor (or bus count) is used in the lens of risk management—to make sure the product/team can continue if anyone gets “hit by a bus.”
Always try to avoid a bus count of one! Not just because of busses, but to distribute knowledge and understanding (and stress) among your team.
-
Technical (and design) debt
Very often, products have to make trade-offs between design or code quality to meet deadlines, or to handle scope creep. These decisions sometimes come at the expense of either side—sacrificing the most nuanced design, or giving up on the most pristine, sturdy code.
Technical debt (or the analogous design debt) are the accumulation of these short-term decisions—where you have postponed doing it the right way. Like other forms of debt, these often compound over time—if you don’t pay them down/address them as you move forward.
-
Dogfooding
Often the best way—or at least the first way—to make sure your product is up to snuff is by using and testing it yourself. This term is called dogfooding, or eating your own dog food. (There are debates on the etymology). An example is Apple, pushing desktop publishing in 1980, outlawing typewriters internally.