Example Miro Design Pin-up board
Building software with design at the center.
How we organized our work and got things done.
Agile, 2 week sprints
As design lead, and later interim product manager, I had a big hand on where the team was directing its efforts. In general, I attempted to keep design efforts just slightly ahead of dev efforts. In some cases where features were more complex, the design cycle for a single feature might have extended to four weeks, primarily due to the research and requirements gathering phases. In those cases, we generally also had smaller features or efforts we were working on concurrently. Dev resources were often in flux as well, and in the first two years especially, it could take up to four sprints or more to get through a feature/epic with a lot of moving parts.
I also was responsible for selecting/guiding research efforts, which in most cases meant looking ahead to features on the road map that would benefit from closer examination. Sometimes that meant unpacking functionality, sometimes that mean a deeper examination of the existing state of affairs. For example, how moderation was used currently among staff, or the idiosyncrasies of how service hours were communicated to the public.
Github: All sprint related activities were tracked on Github, including meeting agendas.
Google docs: Extensively used to track research efforts, desk research, as a source-of-truth for micro copy, content models, and to document sprints
Miro: Used extensively for design pin-ups and as team collaboration space
Slack and Teams: Communications channels
Adobe and Abstract: Primary design tool and version control
Axure: Used for prototyping of most usability tests where a build was not available
Team process for new content types
One activity I spearheaded with the team was an examination of how we developed a new content type. As we endeavored to reach parity with the current Drupal platform, new content types comprised a fundamental, and reoccurring, effort that consumed the majority of the team’s time. I had noticed that things were repeatedly falling through the cracks between teams, or that delays would occur that I hoped might be avoided.
For example, from a design perspective, I tried to make sure we always designed with real content. In the case of a new content type, however, that meant that someone on the content team needed to access the current content and create a least a rough draft from which we could work. We might have already decided on the content model and elements the type required, but I felt it was necessary to have at least draft-level content in our mocks so that the content type could be effectively evaluated during pin-ups. Micro-copy and translation considerations were additional elements that also frequently overlooked.
In this exercise, I asked the team members to document each individual activity they did for new content types, and put them in roughly linear order (seen here from left to right). Each discipline had its own swim lane and sticky color. Then we discussed as a team. Action items, represented in the photo as yellow stickies, were changes each team felt they could make right away to improve the process.
We referred to this artifact many times in the coming weeks as we continued to streamline our collective process.
Adapting design collaboration to remote working
We used Miro as a virtual collaboration space, "pinnin up" designs, research, and other documents.
Abstract, a design versioning tool, is pretty new and a tiny bit buggy, but we found it invaluable in our work. To reduce coding effort, our objective was to use the same design library across the internal CMS tool and the external website.
The "branch" style versioning also is great solution to the long-standing final_ final_ final.design problem.
We established a method of tracking within Abstract, too, like putting issue numbers on designs, and using a few icons to establish a quick view of status.