|This page is obsolete. It is kept for historical interest only. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date.|
- 1 New Roles : Primaries & Secondaries
- 2 Focus, Explore, and Collaborate
- 3 Questions & Answers
- 3.1 What if my team or project isn't mentioned?
- 3.2 How will you handle new designers being added to the team?
- 3.3 Does this mean I'll have the same designer(s) for the length of a projects?
- 3.4 What is the analogy between agile terms and Primaries and Secondaries (for instance, is a Primary a scrummaster? a design tech lead? and a Secondary an engineer?)
- 3.5 Will Primaries sit with their teams?
- 3.6 What is the schedule?
- 3.7 When is Explore Wikimedia Design?
- 3.8 How will explore projects be built?
- 3.9 Is there a possible consensus/collaboration-driven way of handling designer/team assignments in the future?
- 3.10 Will weekly design critiques go back to being design only? How will other teams hear about the decisions and discussion?
- 3.11 What if the days for collaborates for a team don't leave this flexibility in the schedule (no single match point)?
- 3.12 How do we determine how well this arrangement is working? or "What does success look like?"
- 3.13 What does failure look like?
- 3.14 What is the role of Primary & Secondaries when interacting with the community?
New Roles : Primaries & Secondaries
Each focus area will be assigned a Primary and a Secondary from Design, these are the designers who will be your primary contact for a project or feature area.
Invite the Primary to your standups and all meetings where design should have a presence. They will attempt to attend as many meetings that are relevant to design as possible. Invite Primaries to any project specific reviews and planning meetings, they will speak for design in these meeting. If they don't know the answer, they will find out. Primaries are responsible for working with PMs to define realistic schedules based on their own availability and that of the designers that will support them.
Secondaries support Primaries when it comes to making the work happen. While each group will have one official Secondary, they may not be the only design support on a given feature. You should invite them to meetings where entire engineering teams are present. When a meeting needs to happen ASAP look to the Primary first, if they are not available the Secondary can represent design in their absence.
Focus, Explore, and Collaborate
Sometime designer work best when they are juggling 10 projects at once, sometimes they work best when they can focus on a single task with no interruptions.
Going forward the designers will block off one day of their calendar every week for Focus, and one for Explore. The remaining days will be for scheduled work and collaboration.
Ideally we would have every designer have the same schedule for Explore, Focus, and Collaborate but this might not be possible due to individual and project team schedules. Designers will block out Focus and Explore on their calendars so externally it will be obvious which days are reserved.
In order to give their full attention to a design problem without having to context switch between meetings, Focus is a day without structured meetings. During Focus, designer may be in the office or they may be working from home, or a park, or a cafe, or in the office. Please do not schedule meetings with designers during Focus, or expect them to attend standups or other recurring meetings on this day.
During Explore designers can explore areas that they aren't assigned to, focus on projects that are important to them, and devote time researching new project that could shape the future of the Foundation and its projects. Please do not schedule meetings with designers during Explore, or expect them to attend standups or other recurring meetings on this day. Monthly the design team will host a 1 hour brown bag "Explore Wikimedia Design" that is open to the Foundation to attend, to showcase what designers have spent their Explore days focusing on as well as increase visibility for other projects that they are working on.
Mostly the same fun times you're used to, schedule meetings, write on whiteboards, have working sessions, etc. desk time doing design work.
What does this mean to me as…
... an Engineer? You should still feel free to bring designers into your discussions and brainstorms, approach them with your projects, and questions. In lieu of scheduling meetings with designers on Explore days, simply walk over (or ping on IM) and see if they are available to talk.
... a Product Manager? When you're planning small meetings and projects make sure to invite your Primary, when planning larger meetings (quarterly kickoffs, roadmap planning) invite both your Primary and Secondary, communicate project needs and timelines directly with your Primary.
Everyone else? Come to Explore Wikimedia Design brownbag to get inspired, and understand what the Design team is working on.
More Q&A on the talk page
Questions & Answers
What if my team or project isn't mentioned?
Try as we might we can't always be aware of every project that’s going at all times, if we've missed your project or feature please get in touch with the design team and we will make sure we do our best to make sure we provide design coverage for you.
How will you handle new designers being added to the team?
As you can see above, even with the Design team growing many members are doing double duty as both Primary and Secondary on for multiple projects. As new designers are added to the team we will load balance as needed. Mostly likely new designers will join a project as a Secondary to get up to speed before being assigned to a new project or iteration of an existing one.
Does this mean I'll have the same designer(s) for the length of a projects?
This is the goal, especially for the Primary, however as projects and resources change the Secondary assigned to a project may change if they are needed as a Primary on another Project, and vice versa.
What is the analogy between agile terms and Primaries and Secondaries (for instance, is a Primary a scrummaster? a design tech lead? and a Secondary an engineer?)
We did a lot of thinking about those roles and how they fit with design. If you must draw correlations between this framework and agile, the Primary is more like the Product Owner. In most teams both of those agile roles are already well covered and I'm not attempting to replace them. The Primary may also not be the one doing the most work on a feature area, but they are the main point of contact for other stakeholders.
Will Primaries sit with their teams?
Maybe. This is up to the individual designers. Since each designer is a Primary for multiple teams (for now) it might end up with a lot of moving around day-to-day. Also, the designers like to sit next to each other so they can bounce ideas off each other.
What is the schedule?
Designers have blocked out on their calendars Wednesday for Focus, and Friday for Explore, starting the week of 10/14
When is Explore Wikimedia Design?
Monthly, dates TBD.
How will explore projects be built?
In the case of Brandon and Pau, they may build their Explore projects themselves, in the case of the other designers, the monthly Explore Wikimedia Design brownbag share out will be a venue for developers to see things they are interested in building during their own time/20% time.
All of the Explore work will be on-wiki both for feedback and for the community to be inspired by. We can work with Quim/Sumana to see if there is interest/availability in the community to build some of the explore features as well.
Is there a possible consensus/collaboration-driven way of handling designer/team assignments in the future?
We can see this happening for future projects but right now the focus is good coverage on projects that are already underway. We are certainly open to individual designer mutually agreeing to swap roles for projects as well.
Will weekly design critiques go back to being design only? How will other teams hear about the decisions and discussion?
Yes, Design reviews will be designers only going forward, they way they were originally. We've tended to post the feedback/notes (on per-project spaces) but we can also have a more general place to post these notes as well.
What if the days for collaborates for a team don't leave this flexibility in the schedule (no single match point)?
This new schedule may alter the team velocity. However we think it will also increase quality and team happiness. Therefore it is in line with the tenant of "Do less, better." We're ok with this. Are the other teams?
How do we determine how well this arrangement is working? or "What does success look like?"
At its simplest level, success is a happier design team, where members feel like they can think further out in the future, and develop a creative vision for the future of our projects. We currently don't feel that because much of our work is reactive to all the things that feel like they need to be done immediately.
Other major factors for success include building a backlog of designs that are interesting to Foundation and community engineers, developing a clearer vision of the design roadmap, elevation of the WMF as a place where great design and designers flourish in an open (source) environment, and a clear direction for where we want to be with design for the projects in six months to three years.
What does failure look like?
Designers feel like they have too much work and spend explore doing assigned projects. Designers can't time-box themselves to focus on projects with the right balance. A lot of time is spent on Explore designs and no one in the community or foundation wants to build them. Explore projects don't feel like they form a cohesive vision for the future of design at WMF.
What is the role of Primary & Secondaries when interacting with the community?
Both roles will be responsible for getting designs on-wiki, and responding to user and team comments on-wiki this is the current process and we believe it works well.
Both roles will be in contact with their Product Owners & Community Liasons to have the Community Liasons to do community research and outreach. We don't see this part of the process changing much and are not aware of any issues with the current state of things in this regard.
Any questions don't hesitate to contact Jared Zimmerman.