Skip to main
Article
Early design concepts for OddBird's new site

Open Design for OddBird.net

We’re re-building our website in the open, and writing about our process along the way. We hope you’ll follow along and even get involved!

This post is part of a series on Open Design:
  1. Open Design for OddBird.net
  2. Defining Goals, Exploring Possibilities
  3. Auditioning GitHub Projects
  4. Behind the Scenes: OddSite Brand Process
  5. How to Choose Engaging & Accessible Typography for Your Website Brand
  6. How to Choose Beautiful & Accessible Brand Colors for Your Website

It’s time for a major overhaul of the OddBird website, referred to internally as our OddSite. This will be more work than we can handle in one pass, so we’re going to take things slow and re-design our site in the open – sharing our thoughts while we work.

At OddBird, we are very familiar with open source collaboration, and daily client feedback, but designing a site in the open is new to us. Luckily, we’re not the first to do it. There’s a broad range of open design practices, so we’ll mix-and-match to see what works for us.

We decided to re-design our live site, rather than starting from scratch on a private staging server. That means we’ll be taking live traffic while we work, and using continuous integration to make updates on a regular basis. It also means we needed a usable first draft, so the site would work publically from day one. We’ll post more about that drafting process in the next week or two.

You’ll be able to see the site live as it develops, but we’ll also post articles along the way – capturing screen shots of the site at different stages, sharing artifacts from the design process (such as sketches and planning documents), and telling stories about our process and decision making. We also have our source code available on GitHub, and will talk about the open source tools we use, and share any tools we build.

These are the rough stages we expect to go through:

  1. Planning and Rough Drafts – You’re looking at a first rough outline of the site contents and organization. Miriam and Sondra put together this draft based on conversations with the team, as a proposal to discuss. At this point everything is still up for debate.
  2. Information Architecture – Before we dive into the fun design work, we want to make sure that all our content is in place, visitors can find the information they need, and we’re telling the story we want to tell. We need to spend some time looking at it, playing with it, sorting out exactly what user stories are most important, and planning how those stories can be achieved.
  3. Code Architecture —  With a better view of our own content, we’ll spend some time improving the data structures, views, and templates that drive the site. We’re using rstBlog – a powerful but poorly-documented Python static-site generator – so it will take some customization and a lot of documentation to make sure we have a maintainable site going forward. We want to encourage regular updates, so it’s important that we get the development flow right.
  4. Design and Interaction – We save most of our graphic design work for the end of the process. In reality, our designers are involved at every stage, guiding the planning and architecture from the start. Sondra made a few photoshop sketches to get us started on this first draft, and we’ll generate more sketches to help us understand the architecture and flow as we move forward. But once everything is in place, we will be able to make much more clear and informed decisions about the final visual details.

The steps can be listed like a numbered waterfall, but that’s not how it will happen in practice. The site goals will get broken down into distinct user stories, and each story will reflect a microcosm of the larger process. Changes to architecture will affect how we think about user stories, and “final” changes to design will affect the architecture. The process is flexible, and we can move around as we need to, but having a general order reminds us what is most important to focus on at each stage of the process.


  1. The OddFriends Slack channel is no longer available. ↩︎

Recent Articles

  1. A chain-link gate in black and white with a sign that says closed indefinitely, and a smaller warning with gruesome icons for entrapment (a person being smashed) and pinching (a hand going through gears)
    Article post type

    How do we move logical shorthands forward?

    There are several proposals, but one major road block

    We’re trying to make progress on shorthand syntax for CSS logical properties. But the path forward depends on where we hope to be a decade from now.

    see all Article posts
  2. block-size, inline-size, size?
    Article post type

    Support Logical Shorthands in CSS

    Can we get this process unstuck?

    The CSS Working Group recently resolved to add a size shorthand for setting both the width and height of an element. Many people asked about using it to set the ‘logical’ inline-size and block-size properties instead. But ‘logical shorthands’ have been stalled in the working group for years. Can we…

    see all Article posts
  3. A hand with painted nails placing a white square of paper into a 9 by 9 grid.
    Article post type

    Better Anchor Positioning with position-area

    It’s not just a shorthand for anchor()

    position-area might be my favorite part of the CSS Anchor Positioning spec, with a ton of features packed in to make things just… work. But there’s no magic here, just a few key parts that work well.

    see all Article posts