[plan] Determine process for big UX changes

Could do worse than adapt some version of the double diamond process. I find that everybody can understand this and that it makes sense. It is clear about when to explore and diverge and when to hone in on the one plan or spec to execute on. And it makes it clear that this has to happen for both the plan and for the build phase.

Quick summary. The flow is

1. Initial insight
2. Discover
3. Define
4. Plan
5. Design
6. Develop
7. Ship

The insight is the initial trigger, the problem or opportunity that tells us we should do something about it. These can be findings from usability testing or the rationale behind core initiatives or priorities set by Dries :-)

The discovery focusses on answering "Why?", in three parts: Market, customer and product. For market, you look at what the competition is doing, how they differentiate themselves and what the general trends are. Customer is about finding out what your persona are and what they are trying to achieve. From there, you can outline a very global but already prioritised outline of the features the product should have. This part is an exploration, research, collecting multiple pieces of input to inform the context we're designing in/for.

The definition phase is about answering "What?", designing the concept and architecture of the solution we choose to build. This phase is clearly about converging: filtering all research and ideas and boil down to a single plan or spec. We also document what succes means, so that we can test for that later in the process when we have built (part of) the solution. This would be where at least the bikeshedding about the overall approach ends.

Design phase is the explorative phase of answering "How?". Based on the plan, the design generates multiple options for how to best solve for the problem. This is where we prototype/measure/learn in order to once again arrive at the best possible solution.

Develop then is executing the "How?" in specific, concrete detail, ending up with shippable design and code.

---
This flow can make it look like code is just an afterthought :-) It's not, but what it does is outline the need to first be strategic about why we would want to do something and formulate a plan for what to build before diving into the specifics of "How?".

Thanks for sharing, yoroy.
I strongly agree to let the "Why?" drive the "How?" and "What?".

I feel the double diamond diagram nicely lists all things we can do to get to a decent solution for every UX challenge.
At the same time I feel it's overwhelming.

It would be good if we could visualise the quick summary you wrote down with a bit of the explanation.

Thanks. Yes, it looks overwhelming if you do all the things always. This won't always be necessary. That you're picking up on the importance of Why before What before How is the main point. If we can somehow manage to move consciously through that sequence, that would be a lot of win already.

Couple of things to think about or clarify:

- Why? I agree we need a process for good design. Lets make it clear why that is, what (doesn't) work today, what we want to achieve with this.
- How flexible the first half of the process should be. Does it always have to be based in validated research or can we start with documenting our assumptions too in some cases?
- How to balance working in small teams and keeping everybody who wants involved up to date. When do we have to make conscious efforts to get feedback? Does that need to be timeboxed?

The need for an approach like this was reflected in other conversations I was in over the past few days. Great suggestion @yoroy.

Ok, I watched the video and was somewhat familiar with the work done during the usability study. All good stuff. What now? Is there a next step? Does a specific process need to be determined and, if so, who formalizes it?

Does the "Why?" portion need some fleshing out?

For market, you look at what the competition is doing...

Will we define who the competition is and create a standard list to use for checking each time? At universities which actual do this, but we call them fancy things like "aspirational peers."

Customer is about finding out what your persona are and what they are trying to achieve.

I know d.o went through the work to develop personas, and they've been very useful, does core already have defined personas? Is that work that needs to be done? Or is this something that needs to be developed uniquely for each UX change?

The issue is currently set to postponed. What is this postponed on?

I wrote up a high level retro of the content creation page redesign: http://yoroy.com/pieces/redesigning-content-creation-page-drupal-8

Links to the design and implementation threads/issues:

- Research: http://groups.drupal.org/node/214898
- Design iterations: http://groups.drupal.org/node/217434
- Usability test: http://groups.drupal.org/node/223959
- Implementation: https://drupal.org/node/1510532

## the lessons (not ;-) learned part:

**Good:** working with a small team. It allowed us to focus on what needed to be done and move relatively fast.

**Good:** Publicly documenting the research and sketching phases was a lot of work but worth it. Pulling a finalised glossy photoshop design out of the hat would not have created the same engagement and constructive feedback

**Good:** counter to the previous point but also a good thing was that the initial sketches and design mockups were shared only within the very small team of 3 to 5 people. This kept momentum up but more importantly allowed us to focus on the actual design work. A broader discussion would very likely have shifted towards discussing implementation challenges, which is not what you’re after when still exploring multiple options.

**Not so good:** we prototyped only one working version quite late in the process. Only after a lot of time invested did we get to see and feel a somewhat working version. This narrowed our bandwidth for subsequent changes, which were relatively small tweaks, keeping the basic paradigm intact. We never really pitted two or more radically different approaches against each other. This was mostly a time and energy issue: we only had the bandwidth to work through one design direction.

**Not so good:** Doing the design phases outside of the issue queue (where implementation happens). This was a necessary but difficult trade off. The issue queue doesn’t lend itself to explorative work with lots of ambiguity so the design work wasn’t tracked there. Many core developers did not closely follow the process as it happened on groups.drupal.org, so when we brought the design over to the issue queue with the proposal to go build this, much of the earlier discussion points got brought up again.

**Not so good:** Not having a primary code architect as part of the team. We could have prevented at least some of the rehash in the issue queue if we had had a knowledgeable core developer on the design team. Having somebody who could answer to the technical implications of the design and help break down the work into manageable tasks the would probably have gotten us off to a better start with implementation.

A quick tally of the number of comments across the main discussion threads and issues for this project: more than 1200. And that doesn’t even include huge additions like the WYSIWYG editor and the improved previews. Not to say that this doesn’t happen in other initiatives, but you can see how demanding it is for anyone who wants to keep track, especially if you want to make sure that the big picture doesn’t get lost in the myriad of details.

## How to get better, faster?

The nature of design changes like these is that they touch many aspects: backend & frontend, php & javascript, visual design & performance, accessibility & multilingual, etc. If we want to go faster we might want to consider replacing the research intensive work with building multiple (rougher) prototypes earlier and testing those for viability. That might lead us to a general direction and a plan for implementation faster. As for the actual core worthy implementation, we might win some time if we can provide a design spec *together with* an initial plan identifying the technical challenges and strategies to overcome those.

The amount of work will always be huge. I think the gains are in finding a better balance in:

1. Feeling free to write quick throw-away code in the initial explorations so people can get a feel of what might work and we can test it.
2. Reducing wasted efforts (in code and discussion) during implementation.

Understanding the distinction between these two, and being clear about when the first ends and the second begins will already be a big step forward.

Maybe 'redesign Field UI' is a good example to think through:

- Why? – What's the context, why is improving this interface a good idea? Not to convince people, but to be clear about the goals we want to achieve and to underline the importance of improving the situation
- What? – What would the ideal Field UI look like? What do we want to do to find and commit to a high level direction?
- How? – How would it work? How to break down the work in manageable tasks?

I read your write-up this morning, found it via Drupal Planet. Thanks for writing that! :)

While reading it, I found myself nodding along. We've had many of the same conclusions as the Spark team:

• Publicly documenting the research and sketching phases was a lot of work but worth it.
• yet… Doing the design phases outside of the issue queue (where implementation happens). This was a necessary but difficult trade off., which led to so when we brought the design over to the issue queue with the proposal to go build this, much of the earlier discussion points got brought up again.

Agreed with How to get better, faster? too.

A couple of takeaways I had reading @yoroy's writeup on how we could support this from the core queue side:

1. Have a "developer buddy" who is invested in the goal collaborate and be a resource during the design phase, so that that developer can help identify risks and field technical questions once it gets to the implementation phase.
2. Have plan issues for redesigns that are periodically updated with design work that state unambiguously that any implementation discussions are out of scope and off-topic. Enforce this.

Would those two things help?

(Filing against 8.1.x., since UX work will be initially implemented in the development minor branch).

I would add that once a design issue has been closed we don't discuss design anymore. If people want to rehash the design talk, they need to wait the next round of design update. If there is a developer buddy in the design issue there is no reason to reopen a design issue from an implementation issue. This back and forth is killing willpower during implementation too.

This, I think, is yet another thing that would benefit from the "Initiatives" solution that was part of the d.o content strategy redesign. https://www.drupal.org/node/1300972

Though it seems to have disappeared from the current version of the roadmap.

@xjm thank you.

1. Filling in the developer buddy role is a critical success factor methinks.
2. Those issues would probably only point to place where the actual design is happening. I don't see sketching sessions happening in here (yet). I don't think that's what you're suggesting either. Might indeed be better to be somewhat strict in enforcing a "no implementation talk" then just plain ignoring it (because it *will* happen :-)

@nod yes, time boxing the feedback window and being very clear about when it's time to focus on getting (prototype) code written is crucial. I agree that the back and forth between discussion and implementation can be very demotivating.

A post on groups.drupal.org outlining an approach and things that we want to change to make it work: https://groups.drupal.org/node/510551