On Tue, Oct 8, 2013 at 3:55 PM, Jared Zimmerman
<[email protected] <mailto:[email protected]>>
wrote:
*Thomas*, looks great, I'll start
https://www.mediawiki.org/wiki/Design/Team this week.
*Arthur*, Yes, please work this out with your Primary designer
specifically. In your case Kaity. The reason we're attempting to
have all designers on the same schedule for Focus & Explore is so
they can work and brainstorm together if they prefer.
*
*
*
*
*Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman
<https://twitter.com/JaredZimmerman>
On Tue, Oct 8, 2013 at 3:50 PM, Jared Zimmerman
<[email protected]
<mailto:[email protected]>> wrote:
Yes, *Steven*, do you have a specific place you'd recommend it
go on office wiki, I'd be happy to post it there. As far as the
audience, the design group has many "clients" within the
organization and I didn't want to accidentally omit any. As with
any other thread that isn't relevant to you Gmail's mute feature
<https://support.google.com/mail/answer/47787?hl=en> is great.
Correct, *Arthur* while gmail excels in muting, it fails in
search and replacing. Flare = secondary
*
*
*
*
*Jared Zimmerman *\\Director of User Experience \\Wikimedia
Foundation
M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | :
@JaredZimmerman <https://twitter.com/JaredZimmerman>
On Tue, Oct 8, 2013 at 3:30 PM, Steven Walling
<[email protected] <mailto:[email protected]>> wrote:
Can we put this in a document somewhere, like Office Wiki,
instead of via wmfall email?
I am not sure this email was relevant to all 150 staff
including HR, finance, and others who almost never work with
designers.
On Tue, Oct 8, 2013 at 3:14 PM, Jared Zimmerman
<[email protected]
<mailto:[email protected]>> wrote:
Meetings are the mind killer. But collaboration can set
us free.
I've been thinking a lot lately about how Design works
in tech, what works well and what is broken. How Design
can use Agile methodologies to its advantage, and how
the proliferation of meetings in agile can be a serious
detriment to the creative process.
I'm rolling out a few changes to the way Design will
work with the teams and functional groups at the foundation.
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.
Primary— 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.
Secondary— Secondaries support Primaries when it comes
to making the work happen. While each group will have
one official Flare, 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.
Focus
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.
Explore
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.
Collaborate
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 Spark, when
planning larger meetings (quarterly kickoffs, roadmap
planning) invite both your Primary and Flare,
communicate project needs and timelines directly with
your Spark.
Everyone else? Come to Explore Wikimedia Design brownbag
to get inspired, and understand what the Design team is
working on.
Feature Areas and Project
Key:
Design area
Primary
Secondary
Analytics tools
Pau
Kaity
Core Features
May
Brandon
Growth
Pau
Vibha
Language Eng.
Pau
Kaity
Mobile
Kaity
Vibha
Multimedia
Vibha
Pau
Platform
May
Kaity
Visual Editor
Vibha
Kaity
Global Profiles
Brandon
Vibha
Affiliations/Groups/Campaigns
Brandon
Kaity
Questions & Answers
Q: What if my team or project isn't mentioned?
A: Try as I might I can't always be aware of every
project that’s going at all times, if I've missed your
project or feature please get in touch with me and I
will make sure I do my best to make sure we provide
design coverage for you.
Q: How will you handle new designers being added to the
team?
A: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.
Q: Does this mean I'll have the same designer(s) for the
length of a projects?
A: This is the goal, especially for the Spark, 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.
Q: What is the analogy between agile terms and Primaries
and flares (for instance, is a Primary a scrummaster? a
design tech lead? and a flare an engineer?)
A: I had to do a lot of thinking about those roles and
how they fit with design, if you mustdraw 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.
Q: Will Primaries sit with their teams?
A: Maybe, this is up to the individual designers, I'm
not going to mandate it, 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.
Q: What is the schedule?
A: Designers have blocked out on their calendars
Wednesday for Focus, and Friday for Explore, starting
the week of 10/14
Q: When is Explore Wikimedia Design?
A: Monthly, dates TBD.
Q: How will explore projects be built?
A: 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.
Q: Is there a possible consensus/collaboration-driven
way of handling designer/team assignments in the future?
A: I can see this happening for future projects, but
right now my focus is good coverage on projects that are
already underway. I'm certainly open to individual
designer mutually agreeing to swap roles for projects as
well.
Q: Will weekly design critiques go back to being design
only? How will other teams hear about the decisions and
discussion?
A: Yes,Design reviews will be designers only going
forward, they way they were originally, we've tended to
post the feedback/notes, on a per project spaces, but we
can also have a more general place to post these notes
as well.
Q: What if the days for collaborates for a team don't
leave this flexibility in the schedule (no single match
point)?
A: This new schedule may alter the team velocity,
however I think it will also increase quality and team
happiness. Therefore it is in line with the tenant of
"Do less, better
<http://www.markramseymedia.com/2013/09/do-less-better/>" I'm
ok with this. Are the other teams?
Q: How do we determine how well this arrangement is
working? or "What does success look like?"
A: 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 with me for
the future of our projects, they don't feel that now
because much of our work is reactive to all the things
that feel like they need to be done right now.
The other major factors for success to me are a backlog
full of designs that are interesting to foundation and
community engineers. A clearer vision of the design
roadmap. Elevation of the WMF as a place where great
designer and designer flourish in an open (source)
environment. A clear direction for where we want to be
with design for the projects in 6 mo, a year, 3 years.
Q: What does failure look like?
A: Designer 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.
Q: What is the role of Primary & Secondaries when
interacting with the community?
A: 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 I believe it
works well.
Both roles will be in contact with their PM & CL to have
the CL to do community research, and outreach. I don't
see this part of the process changing much, I'm not
aware of any issues with the current state of things in
this regard, let me know if there are issues I'm unaware
of.
Any questions don't hesitate to contact me.
*
*
*
*
*Jared Zimmerman * \\ Director of User Experience \\
Wikimedia Foundation
M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | :
@JaredZimmerman <https://twitter.com/JaredZimmerman>
_______________________________________________
Wmfall mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/wmfall
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
_______________________________________________
Wmfall mailing list
[email protected] <mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/wmfall
_______________________________________________
Wmfall mailing list
[email protected] <mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/wmfall
_______________________________________________
teampractices mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/teampractices
