As part of our DrupalCon session, one of the major takeaways is we need to write down a process for making big UX changes in Drupal.

Here is where we can discuss that after the session.

CommentFileSizeAuthor
#2 double diamond.png166.77 KByoroy
#2 double diamond design process.pdf52.53 KByoroy
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

webchick created an issue. See original summary.

yoroy’s picture

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.

yoroy’s picture

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?".

webchick’s picture

That is a great starting point!

(Funny how much this general problem mimics the problems we've talked about in reference to Drupal.org :D)

PieterDC’s picture

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.

yoroy’s picture

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.

yoroy’s picture

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?

kattekrab’s picture

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

davidhernandez’s picture

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?

yoroy’s picture

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.

yoroy’s picture

Status: Postponed » Active
yoroy’s picture

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?

Wim Leers’s picture

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.

xjm’s picture

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?

xjm’s picture

Version: 8.0.x-dev » 8.1.x-dev

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

nod_’s picture

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.

davidhernandez’s picture

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.

yoroy’s picture

@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.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

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

webchick’s picture

@yoroy and I had a conversation today about how to solve the "goldilocks" problem of when to show prototypes/designs in the issue queue. Too early, and the issue might get derailed on people nitpicking small oversights, or chiming in with completely different, out-of-scope directions. Too late, and the spec is already "fully baked" before anyone but a small handful of people gets to provide feedback, which causes mistrust, as well as delays in repeatedly explaining why certain approaches were taken. We're running into this with dichotomy with #2724819: Create experimental module for place block on any page feature and #2732443: Finalize the behavior for triggering view/edit/build modes from the toolbar (and fix the "disappearing toolbar"). respectively. The former started "code first" and calls to put more design thought into the UI have been requested to be postponed until later, and the latter is starting "design first" and no code has been written yet; the designs have been shared in UX hangout a couple of times and are undergoing user testing, but there's (currently) no link to the prototype or archived discussion on what was demoed, meaning any feedback waiting in the wings from a broader audience has yet to be expressed.

Roy suggested, and I think this sounds pretty good, that for BIG changes (loosely defined as those that are "80% tasks" and scenarios for editors and/or site builders), the recommended approach would be:

- Iteration #1: Demo rough prototype during one of the twice-weekly UX meetings to get initial directional feedback / initial sign-off.
- Iteration #2: Demo more refined prototype during one of the twice-weekly UX meetings to get more detailed feedback.
- Iteration #3: Post to the issue queue (and optionally demo on UX meeting once again).

By this time, you have hopefully worked out some of the more obvious problems, so people can focus their attention on the interaction / design. You also have some initial buy-in from the UX team on the idea to help bolster it in front of the bikeshedding gauntlet. But you're not so far along that you feel completely invested in your solution, and there's still opportunity to refine it should something come up during user validation testing.

This workflow does necessarily add at least a month in advance of any UX improving patch making it into core. OTOH, it also hopefully obviates the need for 200+ comment issues to add experimental modules, as long as a designer is available to help. And we'd only recommend this workflow in case of "BIG" changes. (Another demo this week was of a redesigned admin status page, which is neither an 80% case nor a primary site builder/content author task, so would not necessarily need this workflow.)

Thoughts?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.