Design pipe processes and feeding into the dev pipe

Product Development Process
1

Hey folks,

I’ve had a couple of conversations about this with some individuals but want to put this out there to the wider network of folks who work on, and are interested in how the product evolves and is improved.

These suggestions (more to come!) is mostly gained from my time as a designer in other OSS orgs and learning as a ‘custodian’ of Open Source Design.net

I’d like to propose adding in a ‘design pipe’ into GitHub and for more design work to be captured in GitHub.

By having design issues in GitHub it signals to designers that want to contribute what’s been done in the past, what needs to be done and what kinds of issues they could raise themselves as design issues (under the same criteria as bugs -> design bugs, features, spikes and/or paper cuts etc.) This allows another way of onboarding open-source designers that aren’t as ‘hands-on’ as the current process of a 1-2-1 conversation and ‘closed’ work board document invites etc.

It means that designers can pick up smaller design tasks than large, inception based discovery and perhaps things like: ‘Design an icon/illustration for different kinds of produce for producers to use when they don’t have a photo’ (just an example!)

It also allows for better transparency for the product and dev teams too, to see how design tasks are estimated, do discussion in GitHub comments, opens up how we do the design process at more stages, and allows for design work to move into the dev pipe.

So concrete actions:

  1. 3 new columns in our pipe: Design Ready, In Design and Design Sweep (or Design QA)

    • ‘Design Ready’ means that this has gone through a feature template or story template and is being ‘incepted’ either here on discourse or through discussion.

    • ‘In Design’ means there’s actively some design work being done, whether it’s research, UX, UI or user testing.

    • ‘Design QA’ means that it’s gone through the dev and testing pipe and ‘Design QA’ is part of the testing process where we also observe whether the PR meets user/design criteria.

  2. Design labels beyond ‘Design’

  3. Updates to the .readme .contributing (on GitHub and on Git book)

Possible actions but may over complicate things:

A note about having design in ‘projects’ vs ‘design pipe columns’. Projects are good for exactly that, projects. Design generally isn’t a single project, it’s part of the way products get delivered and this is why I would like to include some design process in the pipe. The closer that design is to the dev pipe the more consideration everyone across the team gives to user centred design. Could it be a bottleneck? yes it could like most pipe processes but if we can see it then we can ease the bottleneck. We currently can’t see it.

3 Likes
2

Oh! other things I’ll be looking into is how design do demos. @Mario has done a great job of doing screen recordings for Network work so I expect it’ll follow that process but I’m also thinking about doing ‘Design office hours’ where I’ll sit in a video rooms for around 2 hours at a set time each week so people can ‘drop into my office’ if they have anything they need or want to ask.

3

These are great suggestions @Erioldoesdesign. Once those columns are well established and we’re happy with how they work, we might also want to update the software improvement process pages in Gitbook to explain the process to design contributors too.

Good stuff :+1:t2:

1 Like
4

I’m gonna go ahead and tag some of the dev & testing team as I’m keen to have their insight on this suggestion too.

@luisramos0 @sauloperez @maikel @Matt-Yorkley @sigmundpetersen @Rachel @filipefurtado

I feel like doing that is like doing @here or @channel in slack though which is very unpopular :see_no_evil:

5

Not sure if I’m understanding this correctly, but if I am I’m wondering about whether having a different repo for design issues might work better than adding more columns into the dev zenhub board - just re. overwhelm in that board. With zenhub is straightforward to choose which repos you are including in your view, so people can have both design and dev or one / other. Then the design issues can be displayed in the same ‘pipe’ columns as the dev issues, on their own for say a ‘design curation’ meeting or not viewed as necessary? @Rachel might have better insight into whether what I’m suggesting makes sense?

1 Like
6

I completely hear what you’re saying and this was raised by other people re. complex dev pipe already. I’m very happy to create another repo for design and pull through on zenhub but I think there are two things that I want to be sure we limit if we do this route:

  1. That design is seen as ‘separate’ from the dev pipe and is treated as such. (Could be solved with just conversation and you know, design adoption!)

  2. That OSS designers will look in the dev repo first and see no design labels, issue etc. and bounce. (Could be solved by having a good docs/wiki)

A pro point for a separate design repo means that we can track design tasks that aren’t going into the dev pipe which is chefs kiss perfect in my opinion. That way once OSS designers are in the repo they can use github in a similar way as devs and we could do burndown’s for sprints etc. etc. accountability!

7

:sunglasses: This looks awesome. Pretty much alligned with this presentation @lin_d_hop & I attended to in February: FOSDEM 2020 - Gitflow Design

Maybe you were there as well @Erioldoesdesign ? What did you think about even storing the files on github and track versioning there?

Here on discourse we do it when we want to be sure to get feedback. Otherwise it’s hard to keep track. So don’t feel bad, tag tag tag :slight_smile:

2 Likes
8

hehe That’s the room that me and the rest of Opensourcedesign.net organise. Honestly, I helped behind the scenes this year and showed up for my talk. I was on booth duty all FOSDEM 2020 :(((

What did you think about even storing the files on github and track versioning there?
Yes! I love this and it’s such a good practice to get into. I’ve typically done a combo of uploading design files and also having a .md file to add in extra context to a new file version. I haven’t experiemented yet whether theres a way to hack PR’s to do design versioning but the design team can for sure experiment :smiley:

Sidenote: This also gives evidence for changing things at the Github/GitLab organisational level too! (I’ve been trying to push them both to include more design features)

1 Like
9

hehe sorry for going off topic but may I ask where do you suggest such enhancements? I would really love something like Zenhub for gitlab for example, but I’m struggling to find where is the best place to do it. It looks like there are forums everywhere :smiley:

10

I’ve been slipping into the DM’s of GitLab & GitHub staff or getting connected through folks I’ve met at confs. The infiltration/spy route!

I can ask the Gitlab staff where the best place to go is because they are more responsive to DM’s than GitHub :upside_down_face:

11

Hey @Erioldoesdesign, this is great. My only thought on the bits still unclear is how the above fits into the overall flow, and what needs to actually change to properly implement design into the mix.Let me see if I can explain what I mean:

Inception-based work

When things are approved in the roadmap and product/design/tech assigned to do the inception, during this time there aren’t any stories or the such, just a desire to come up with a solution. It’s at this point that we choose the best solution candidate, and then design the solution (interaction, wireframes) and break it down into stories in GH, and understand the technical design solution to make sure stories cover this work as well.

We don’t have a pipe process with columns for this work, it’s all mostly done outside of GH and the results are added when the stories are scoped/designed and ready to be developed.

→ So many we need a home for this work, where the elaboration and design is collated/and there’s an appropriate set of steps/columns showing progress?

Feature delivery

At this point the stories are driven through the build phase epic by epic. We don’t have a place specific step/column within the process where the epic once built is checked by design. It happens occasionally, such as with Mobile UX where Yuko did a design sweep post-release, where the stories had been done and live, and the epic was then reviewed by her to determine whether it was “done” or final tweaks were required. These final tweaks were listed within the epic and that epic was moved across the pipe to then be considered “done”. Note: this process was ad-hoc and spontaneous and depended on how much time was available to do the sweep. The fixes to the tweaks were managed by me once Yuko had compiled them, again due to time constraints.

→ So maybe we need to be thinking at 2 levels about how design fits in - firstly at the story level (eg search has a clear icon) and then at the overarching epic level (eg search & filter redesign)?

Bugs

When bugs are logged the logger usually adds a view on how the problem should be solved (ie. expected behaviour). Sometimes there expected behaviour isn’t easy to do (the incorrect price due to decimal points comes to mind), and design is required before dev work can commence. At the moment this discovery/inception/elaboration process doesn’t happen anywhere in particular, we have an S3 bug backlog and then they go to dev ready > onwards.

→ So maybe we need a better approach to elaborating on bugs, where at the point of triage we understand if this is a no brainer, or if it needs more technical/design consideration?

Papercuts

These are managed in a GH project, and again, there’s no visible discovery/inception/elaboration step within the flow.

→ So maybe we need to also have a better approach to elaborating (and even selecting?) papercuts that heavily involves the designer (rather than the product person?) given these changes are all user-centred and touch on interaction or visual design?

I’m skeptical that a separate repo for design will actually work, given the above, because design is heavily embedded within the overarching process and therefore needs to be incorporated in amongst the product and dev stuff. Maybe having a separate elaboration or inception repo may work, the place where everything gets figured out before it goes into dev…but moving stories across from one repo to the other feels clunky and like it’d probably be a nightmare to do and add complexity we don’t need.

In terms of the actions you’ve noted @Erioldoesdesign:

  • ‘Design Ready’ means that this has gone through a feature template or story template and is being ‘incepted’ either here on discourse or through discussion.

I wonder whether we can be prescriptive about this, and how epics fit in? Because I would see design actually working at a higher level, and it’s later on that stories get broken down ready to be built. Designers would need to be providing an overarching design view of how the change works in its entirety, and this then gets broken into the stories - do you see work being required at a story level by a designer for features, or would it already have been done?

  • ‘In Design’ means there’s actively some design work being done, whether it’s research, UX, UI or user testing.

Same curiosity as the above statement, how would this column work for epics vs stories and within the inception/elaboration process?

  • ‘Design QA’ means that it’s gone through the dev and testing pipe and ‘Design QA’ is part of the testing process where we also observe whether the PR meets user/design criteria.

This feels more like we need a definition of done, for a story and also for an epic/feature. If a designer must check every (relevant) story/PR that goes through the pipe as part of this definition then having another column makes sense. we have a dev-test column, that only gets used if a dev only can test it. How do we define what types of stories/epics must go through Design QA vs doesn’t have to?

Super happy to be having this conversation btw, I think we’re going to end up with a FANTASTIC first attempt at a new flow, that will then be refined till it’s solid. Yay :tada:

2 Likes
12

I like the idea of making the design work more visible and creating issues that can be picked up by the community. It’s working great for dev tasks.

I’m wondering why we want to separate the design and the dev tasks. Why don’t we rename our columns to have both int here?

  • Dev Ready -> Ready
  • In Dev -> In Progress
  • Code Review -> Review

We can separate tasks by labels. It could also improve the dev process to use skill labels. So a task maybe labelled “design” or “illustration, css” or “sql, ansible” so that people can pick up tasks according to their skills or what they want to learn.

I also think that those tasks don’t have to feed into dev tasks. A dev task may depend on a design task but your example of designing some example images could feed into updating the user guide to share the collection. We have dev “spikes” already which are inception and doesn’t always lead to dev work.

1 Like
13

Just a quick feedback: I’m using this extensively on other projects. You have this button on each issue (bottom right):

image

Which allows to move an issue from one repo to the other in one click :ok_hand:

Even with a new repo, we will need to rename the column, good point :+1: The only thing I’m afraid with having everything on the main repo is that our columns will become very crowded. And it’s easier to select the repo that you want to see more than selecting labels?

2 Likes
14

Hello, we could move more stuff to a separate repo to make the current pipe cleaner.
What if we move all feature epics to this project and use the project not only for design but to map out the full product wishlist-inception-etc process? :heart_eyes:

1 Like
15

Seems Zenhub has come to the rescue :tada:

image
image1220×738 70.5 KB

(Thanks @Kirsten for the heads up on this on Slack)

1 Like
16

Sharing notes of the conversation Eriol & me had on design pipe and how this fits in the overall flow

Where do we create & discuss issues, that are not design ready, when problems/desires are stated but maybe not entirely clear yet, more research is needed etc.

-> This could be just one more column in the design-pipe, like ”inception” (con: column overload) where issues from multiple sources - wishlist, user research, instance managers, analytics - find a home for early discussions

We might need a new template to define what is needed for an issue to move from this Inception column to Dev ready?

First draft of info needed

  • what is the problem / desire?
  • indication beyond opinion, that this is is needed (where does the problem come from, based on research?data?..)
  • where in the product will it affect (e.g. unit prices affect front office and admin, on which pages/features…)
  • where to focus on
  • are there different versions of the solution, what would be V1 V2…

Other things to be discussed:

After things are ready designed and before they go DevReady, they should be reviewed

  • is it feasible? (tech)
  • does it solve the problem (product)

-> How and where do we include this in the process?

What kind of issues need design work (re effective use of limited resources and our discussion on papercuts)?

When do things need user testing?

  • If there is a disagreement if a proposed solution solves the problem
1 Like
17

@Jana @Erioldoesdesign I just would like to add something to the cons:

Today, you can only see the column if you install the Zenhub extension, which a lot of our community devs are not doing. They are supposed to all pick up from good-first-issue label but this is not always the case. I think we would need to add something else than the column to be sure no devs starts to work on the issue while it’s still being incepted.
I think this was one of the main reason to move feature requests and inception to discourse and out of the main repo.
@Kirsten @lin_d_hop I wasn’t around when this decision was made - is this a correct assumption?

There is also the topic of creating a lot of issues on the main repo : we are over 500 currently. I’ve already heard devs saying there are a bit depressed by this number never going down (no satisfaction in delivering work), plus there is also this outside-github-world image of seing issues as bugs, and then having the feeling OFN is really far from stable (I’m not saying it is, just how people can draw conclusion from quickly navigating github).

So if we do add a column, maybe a cleanup of old issues should be done before?

1 Like
18

Okay, folks! thanks for this discussion here I think it’s really moving forward with some valuable questions to refine and interrogate the design placement and process :bouquet:

Just flagging there meeting 1 of ? meetings today at 08.00am UK time. I’ve made the agenda and notes open on the notion page here:

What I hope to do after this meeting with the designers + some PM reps is synthesize our perspectives and needs into a ‘proposal’ that we can approve/tweak and then move forward with to test.

Emphasis on test! we can always be agile and pivot :smiley:

We’re making great strides on how we include design not only from a regular paid worker perspective but especially when @maikel suggested they be part of the main repo and labelled. This is like, design + dev OSS collab utopia for me, but it might not be realistic right now (which is a sad reality of designers knowledge/comfort levels generally with how dev’s do github processes generally, 100% not a reflection of anything other than needing to softly softly bring designers into dev practices.

1 Like
19

So I still think some more discussion can be had on design pipe specifically but please note there’s a lot of discussions and a proposal/experiment happening on the product, inception and design pipe here too: Product Discovery / Inception Pipe