GitLab Static Site Editor, 24 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Static Site Editor Weekly - Product & Design Focused - 2020-08-24

Description

Weekly sync call of the Static Site Editor group focused on product and design efforts

A

Hello, everyone: this is the static site, editor product and design weekly call for august 24th 2020.. um We can jump right into it. I really only have one topic that I wanted to bring up and that's to share some work. I've been doing on some formal jobs to be done and I have them in a google doc linked. I will save for this call for the purposes of time.

A

Reading through every single one there's quite a few, they are definitely a work in progress. Michael likes, all your feedback and your it's great feedback. I haven't made changes, but I will I intend to tighten them up.

A

Based on your suggestions, I think they're right on and really um the format I was going with here is- is something that, as I've been thinking about it more more closely aligns us with a direction where we are called the static site editor, but really we have three sort of, or maybe four super sets of, user journeys and jobs to be done categories.

A

So the the editor itself for for editing existing content is where we've been focused mostly right now, and we knew that there's going to be workflows and jobs to be done around creating new content, there's also a lot of known work in our backlog around the publishing flow, but I think the this is the first time we've formally committed to jobs to be done around site configuration and creating new jam stack sites or static sites from scratch, and what that might mean for the for the user's journey through um configuring, from the project template or from scratch, and enabling the editor configuring it to behave the way they want it to making it tightly integrated with their other products or their projects of choice, whether it's a static site generator or maybe they want to host on cdn things like that.

A

Those jobs to be done are something that we haven't as a team explored as extensively, but I think we'll need to um really think about. So I don't want to read through each one of them the links in the doc, it's open for feedback um and I'll just uh I guess turn it over. If anybody has any thoughts on uh what I just said as a summary or if you've read them in more detail, if you want to talk about a specific one,.

B

um I guess with the jobs to be done, one um would we back some of this, so normally jobs to be done is like derived from user interviews and stuff. Like that, I know, we've done a few and partly from there I think you're pulling the jobs to be done, but maybe this one's more for cat. Do we need to back up our jobs to be done with more formal research to validate this, like you know, like the drugs to be done.

B

Framework has like this whole, like interview process of like important satisfaction and the whole like timeline thing um so like would we need to go through some kind of more qualitative research to back up some of these jobs to be done, or would this be part of that other epic, that we have where we're trying to look at the scope of the aesthetics that editor beyond the handbook like with that like? Should we focus that issue around kind of do more validation,.

C

Yeah, so so this was where my brain was going. It's a little tricky. I would say the things that have resulted from internal research studies. You've already done so maybe you kind of verified certain workflows um and needs that came out of those interviews.

C

Then that's kind of like the research process, feeding into your job to be done, but for things where it's like it doesn't exist as a focus for the static site editor. Yet you would want to validate them with the target user. So I think it almost all ties together.

B

C

How there's an open issue for design defining a persona and then there's also editing opportunities behind beyond the handbook and then now there's this validating concept. I almost think it could be one set of user interviews where you're exploring the workflows and needs and motivations that user group has so that helps you define the that helps you define the persona, but also will probably result in a list of jobs to be done, but we could also bring in some established jobs to be done, that we want them to like validate themselves and like talk through.

C

Does this kind of uh reflect in your workflow and that sort of thing so it can be a combination of efforts. So that's what I'm thinking after seeing these different things.

A

Yeah, that makes a lot of sense, and these are definitely more informed by internal interviews, that we have done um competitive analysis and where, where we know, we want to move and and sort of what jobs are being done by our competitors. What what problems that are being solved there and then also.

A

Very few actual interviews and more anecdotal uh user assumptions, we'll say so yeah definitely validating these with external users and and refining those personas that that we want to interview would be a great next step.

B

B

All right that sounds good.

A

So uh you've got a few topics, michael so I'll just run it over to you.

B

Yeah, um so on my side, I have three points at the moment, so the first one is editing in front matter. I think um I'm in a pretty good state with that, um I'm going to put together a prototype and the script so expect something to review um by tomorrow. um So since commit is that the conference is happening tomorrow. A few people that were in our you know, persona group that we're trying to target in product marketing and sales would be kind of focused on that.

B

So I'm going to schedule the meetings um more on thursday and as early next week and to get some validation through that. um So that's good. uh The category charity scorecard uh slack recruitment's good. We got some people raising up the hands and we probably have enough uh for two uh use groups: uh two persona groups again and yeah.

B

My one question there for you uh around that eric was like our one job to be done is like uh when I want to edit uh a contributor edit to a static, a page on the stacks site. um I want to make it easily and quickly and like within context and yeah. I just wanted to make sure that if that's the only job to be done, that will focus on right now. The session's like really quick is this, so I don't know if we should sneak in more stuff in it to make that session.

B

That, like that, feels like one question on the top of another thing, or do we try to stretch it out to like the 20 minutes or something and try to sneak in some some other stuff?

B

So one approach was like: do we add more jobs to be done to the thing, or should we try to validate some other parts that haven't been validated, um which kind of like led me on to number three? It's like you know. We still have to do the follow-up solution, validation on the workflow and associating changes to the previous. Mr, so, um and that's on my kind of like radar again, I kind of let us step for the last week, but yeah.

A

Yeah, that's a good point. uh I mean, I think we should be more or less holding ourselves accountable and grading ourselves on that one job to be done, but I think, since we have the volunteers, we can pick a couple that we feel like. Maybe we solved or are partially solved and see how they feel about them and then, if we can't come up with those, I think mixing it with some solution. Validation sounds great.

A

I mean they're, not exactly all going to be like this might not be the best group for the editing upfront matter, but it might, you might just want to show them like. How would you edit a title on this and see what they say? um uh Also?

A

Hopefully it goes without saying, but um as you're scheduling these, let me know or just feel free to offer my calendar out for for the this half of the world. People yeah.

B

A

B

Yeah I'll probably do the same as previously, where I'll put it towards, like your end of the day, um like.

A

Yeah, so I'm just you know, all of these jobs to be done are drafts and they're, not all written, equally tight, but I would say we could potentially, if there's, there's a job to be done around um not just making the edit but using familiar patterns and content tools. You know, content editing tools, so we can probably validate that at the same time, um there might be some further questions um for validating the actual job to be done, that we could ask about just what you know, what are their motivations around?

A

Not wanting or not not, writing and marked down, and not wanting to use the web ide and see if we can sort of flesh out that job to be done. At the same time,.

B

B

And uh catherine um looks like you added a fourth point, and did you want to verbalize that one.

C

Sure yeah, so, following up on the point we just talked about it'd be good. If we could decide on either the user groups, we should target for this first kind of iteration of persona research or the jobs to be done.

C

Slash tasks that they're responsible for so basically when we I'll give you an example so like when we did when we had a goal to create a product manager persona, we were doing our recruiting based off of certain tasks or like we want to target a product managers at mid-size organizations or some sort of thing who are responsible for these tasks, so that we can create a screener survey that they uh take and you kind of identify who fits into that group and who doesn't fit into that group.

C

It was a little bit more clear at that time since we already had product man, product management, offerings like issues milestones and whatnot, so we knew we wanted people who were responsible for things like um what is it like backlog, grooming or things like that, so that they could give us their perspective. But that's a similar thing.

C

I want to do here so that we can start thinking of how to recruit and then the interview questions we might ask, but it's a little tricky because I'm not it seems like. Maybe the task and jobs to be done might be what to focus on the most because different job titles could do those tasks.

C

But if you have thoughts on no, I think we should go with this people with job titles related to this role or something then that's another way to do it.

A

Yeah, I mean I've, given this some more thought, since we talked about this last time and thinking about personas, and I need to contribute this back up to the issue. But I think we have.

A

We do have that challenge that we talked about last time, which is we kind of want this to be something anybody can and wants to use regardless of job title.

A

So it's hard to nail down a specific persona, um and so for that point I like what you said just then about going for the task based um recruiting um because yeah really, we just want anybody to be able to edit the page edit, the content of the page, and we want anybody to feel comfortable making that edit and confident that it's going to be represented correctly and.

A

That's fine, but we do still need to talk about personas. If I was to pick user groups outside of the confines of like get lab job titles, I would look for people first of all in something like a um like a ux writer or something like that or even a tech writer.

A

Really anything has a writer content. Marketer roles like that are probably the ones I would focus on. So those are people who would potentially be frequently collaborating on content where they are not writing the front end code to populate the web page, but they need to insert their.

A

They need to have input on the content or write it from scratch and then put it in there and and know it's going to look. You know correct uh either through some some kind of workflow or previewing or reviewing or like a staging environment whatever they're using now, we would want to validate that that's kind of a user group. I do think the stakeholders product managers. However, you want to blanket like um around- like you know, small, to mid-sized companies that have leadership, that's very intimately involved still in day-to-day work.

A

You know they might be contributing content on a page or or running a handbook, or something like that. I think that's another user group. We would focus on and then sort of a tertiary group, but um and that we're not solving for right now, but that will be very interested as front-end engineers and we already have a percentage there, but specifically for engineers front end engineers who are configuring and setting up sites to be collaborative across these user personas.

B

Yeah yeah, so so just hearing some of this I feel like the focus, should should be on task because that's more general, but I think maybe a refinement of the personas is maybe introducing one internal persona like the content editor, because whenever I'm trying to like know that in an issue template they're like who is this for here's some personas and I'm like going through the list. Nope nope, nope nope and like yes, engineering managers and like their representatives senior stakeholders.

B

But we don't have one just internal one for someone who, like updates, content or works with product marketing or like updates stuff. So maybe, as a small iteration, it's like. We introduce one person to represent these people who are not developers and but are designers or product managers, but they're actually still within an organization, but they contribute in a different way through documentation through the handbook, because once you get into tech writers, they kind of live in the world of talks and blogs kind of live in the marketing world. So it's kind of like this.

B

This, like middleman of where we don't have a person. Yet so maybe we can just change, reduce the scope from like all these people to like someone, and that might just come out of the research that we do through tasks and then we can just create a proto persona around okay. This is a content editor. These are their goals and pain points um and then we'll commit that to the internal lists.

B

So I think task is the one to focus on just based on that.

C

Yeah yeah. That makes a lot of sense, and I, like that idea of first creating this internal uh content, editor persona. We might, I think, what I'll do is I'll review. uh Some of the research you've already create done so far to see what I can pull from it, and then we might do additional uh research if there's like still some ambiguities there and then the first iteration of the external one will probably still be content.

C

Editor focused, but it might have more variety because you know that the job, titles and responsibilities probably would vary a lot more. You know externally, so that sounds like a good idea awesome. Thank you.

A

Cool all right: well, that's it for the agenda. I look forward to continuing to refine both of these as we get more research. This is um it's going to be really helpful as we as we defined the next uh six to 12 months of our our feature and where we want to head so very excited cool yeah thanks again and I will stop the recording.