Design updates: week two

This is the second weekly call for updates for those contributing to design, as outlined here.

The idea of these it to keep all designers connected. If you are contributing to design please add your reply as a comment to this post by Thursday 23:00 UTC. All comments will be combined into a weekly update post on Friday for the design team.

Not a designer but you have something you’d like us to work on? No problem, you can also leave a comment. Just tell us what it is, if a specific team or skill also tell us that.

Just reply to the following:

  • What did you work on this past week? Anything completed (don’t forget a link to show us the amazing work!)?
  • What are you currently focusing on?
  • Anything you need help with? Got a tricky project? Are you looking for a task? Perhaps you know about a task that needs a designer or need a buddy to work on something (lets support each other)?
  • Any links for inspiration you want to share (doesn’t have to be WordPress design links)?

Everyone is welcome to comment, adding names of all that commented last week and were at summit – your name will be added to list as you give an update (so we can include everyone).

cc: @melchoyce, @michael-arestad, @folletto, @mapk, @sonjaleix, @saracannon, @liljimmi, @joen, @empireoflight, @joshuawold, @rileybrook, @celloexpressions, @joyously

#weeky-updates

Design contributor story and tasks

At the Community Summit, we took a bit of time to chart the story of a contributor. We did this to find our problem areas, where in the contribution cycle we lose contributors, and how we could improve. Our focus was on the issues, and getting actionable solutions. Each action item was assigned an owner. We also all agreed to some tasks, which we’d like to encourage all design contributors to join us in.

Each task has one or more person leading it, however, more contributions are welcome in those areas. Some are larger and may grow into bigger projects. The idea of assigning tasks was just to make sure someone takes ownership, so these tasks are actually completed.

Step one: Awareness

This is the start of the journey. We looked at ways we could reach more people, to show them that design is happening in WordPress. We also realised we had a lot of designers involved, but very little support for those designers.

Everyone

  • Blog more about WordPress and the work we’re doing on it
  • Speak about WordPress at non-WordCamp conferences

People specific tasks

  • Look into PR/beyond our community: @mapk
  • Bring more WordCamp designers into the core community: @liljimmi@sonjaleix,
  • Get community members to design cool new WordPress swag: @karmatosed
  • Think about planning a “WordCamp for Designers” or WordPress designers retreat: @michael-arestad
  • Introduce “design challenges” as a way to encourage new contributors to get involved: @folletto
  • Create a design pattern library, starting with Gutenberg: @karmatosed@joen

Step two: Onboarding

Once someone discovers the team, we discussed how we could better retain them.

Everyone

  • Make tutorials on how to get started contributing as a designer.

People specific tasks

Later tasks

  • Look into finding a gather interest via emails, and send out introduction emails to help new design contributors know where to start.

Step three: Once contributing

Once someone is contributing, the story doesn’t end there. We need to work to not have them drop off. We need to be constantly mindful of their experiences.

Everyone

  • Support each other.
  • Monthly design hangouts to discuss various topics, TBD in advance.

People specific tasks

Later tasks

  • How can we create more recognition for design contributors?
  • How can we get more designers to take ownership over projects or problem areas of WordPress?

Step Four: Design leads and reps

Being a design lead can create a range of issues, and lead to problems like burn out. We all agreed we had to support and do our best to avoid this. We concluded design lead shouldn’t mean a solo mission, that way leads to issues in itself. We have been supporting each other unofficially, but that should be more transparent.

People specific tasks

Step Five: Bouncers

Whilst we had no specific tasks, we discussed that some people bounce in and out of contributing. This is actually not unhealthy, we should allow for life to happen and be OK with this. It is important to welcome back in and check just to see if people are OK when they’ve been gone for a while.

Step Six: Leavers

We looked finally at why people leave and stop contributing. How can we help that?

People specific tasks

Follow along and join in

To track and address these issues, we’ve created a design team Trello board. We can iterate, but for now this is where we can get an overview of what is going on. Want to help?

  • Keep an eye on the board.
  • Got an area you want to help with listed above? Add a comment, and we’ll pass your details onto the leads in those areas outlined above.
  • Is there an area or task you are helping design not on the Trello board? Add a comment and we can get it added.

Thanks!

Design updates week one

This is the first weekly call for updates for those contributing to design, as outlined here.

The idea of these it to keep all designers connected. If you are contributing to design please add your reply as a comment to this post by Thursday 23:00 UTC. All comments will be combined into a weekly update post on Friday for the design team.

Not a designer but you have something you’d like us to work on? No problem, you can also leave a comment. Just tell us what it is, if a specific team or skill also tell us that.

So, lets start the first design team individual updates! Just reply to the following:

  • What did you work on this past week? Anything completed (don’t forget a link to show us the amazing work!)?
  • What are you currently focusing on?
  • Anything you need help with? Got a tricky project? Are you looking for a task? Perhaps you know about a task that needs a designer or need a buddy to work on something (lets support each other)?
  • Any links for inspiration you want to share (doesn’t have to be WordPress design links)?

Everyone is welcome to comment, adding names of all summit attendees first – your name will be added to list as you give an update (so we can include everyone):

cc: @melchoyce, @michael-arestad, @folletto, @mapk, @sonjaleix, @saracannon, @liljimmi, @joen, @empireoflight

#weeky-updates

Welcome Ben as a new design rep

As of today we have a new design rep, @empireoflight! Ben brings a different area of design focus to the rep team, so please join me in saying congratulations to Ben.

Notes from community summit design session

Props to @empireoflight for notes. This post is just the notes, in the second post later today we will include the actual tasks broken down.

Props to @folletto for the sketch during our discussions and @saracannon for the photograph.

  • We did an icebreaker: What’s your favorite breakfast, what animal are you?
  • Discussed the current state of the design meetings on Slack. Expressed concern over not enough structure.
  • Maybe an identity crisis: are we a team, or are we support for other teams?
  • We tend to discuss topics that could be or have been discussed on other team channels, leading to a sense of disconnection.
  • Seems to be a lack of leadership in the team.
  • We should establish what’s happening/weekly updates, like summaries.
  • Proposal: a monthly meeting focused on a specific topic.
  • Onboarding is challenging when there isn’t a regular meeting with active participation.
  • Maybe once in awhile (weekly?), do a live hangout/discussion with the team reps instead of always relying on Slack for communication.
  • Office hours could consist of or be replaced by a triage of tickets.
  • This would give new members an idea of what to do.
  • Also need to help participants remember what they did. Many people lose track of how they participated.
  • We discussed mentorship/buddy system to help onboarding, where an established team member would help a limited number of new people (but not too many), as this has proven to fail, so maybe 4 or so).
  • Mentorship should be structured, possibly with outside help (not sure why I wrote this).
  • Can we find easy tickets for new designers to work on? Often they are more difficult than they appear on the surface.
  • This might not be a bad thing. The goal isn’t to find easy tasks that they can complete, it’s to get them excited about something that feels relevant to them, even if it’s complicated. Don’t worry about failure.
  • We discussed difficulty in communicating with other teams about their design needs. Although we could be more proactive about determining their needs, likewise, other teams should be coming to us. BuddyPress was brought up as an example of how design has worked with other teams (successfully, or as an example of the problems we experience? I wasn’t quite sure during the discussion).
  • There are a lot of “abandoned” design tasks on trac. E.g., Dashicons. (Could we review these as potential tasks for new designers?).
  • Gutenberg was brought up as the most active current project for designers.
  • What about a meetup/happy hour/some kind of outreach pointed specifically at WP designers?
  • It’s possible that WP isn’t a designer-friendly space. JQuery Foundation was mentioned as something designers successfully participate(d) in.
  • “Design First” should be the goal, but often it isn’t; e.g. the customizer.
  • Guidelines for feedback need to be established.
  • Setting up a meta sandbox environment is challenging (if not impossible) for designers.
  • We talked about areas for designers to get involved: front-end design/development, marketing, and testing
  • WordCamps often showcase the work of talented designers. They represent a pool of resources for the project; how do we get them to participate?
  • The concept of team reps was discussed. There should be a scheduled meeting between team reps from all channels.
  • We need to define who our reps are, and leads. Leads is the tough part; designers don’t often want to lead.
  • Can we get designers from the industry, who would be granted time to work on the project?
  • This is the case for developers. It benefits their companies when they get “props”. But designers don’t get enough props. How do we fix that?
  • Possibly add a section for “contributing designers” to about page.
  • Possible remove the categories of contribution, e.g. “Core Contributors” or “Contributing Developers” on the about page.
  • This became a new topic for discussion to the summit and was discussed later in the day.

Design meetings new format

The next few weeks are going to see a lot of posts as those of us that went to the Community Summit and WordCamp Europe update you all. This is the first of many, this time focusing on the weekly meetings and way we keep up to date with each other.

During the summit communication and support were strong themes, along with how we can all work across teams, making design better for the entire project. A few decisions were made and we would like to try them. As with anything, we should consider this something that can be iterated on.

  • Weekly meetings will cease to happen for now: over time attendance dropped on these. We tried a lot of methods but issues came from the time, format and nature of work we do. We all often have to attend meetings we focus on and meeting fatigue was an issue.
  • Weekly individual update post: each week a post will be made asking for an update as a comment from all designers who want to contribute – we want everyone to. Our goal is to automate this, but at least for a few weeks this will be manual. This will be posted every Monday and more details on that today with a delayed first post. We will also encourage in this post anyone to bring up design issues that are needed help with.
  • Weekly update post for design team: this post will come from the individual updates. These will be posted every Friday on the update blog, giving time for posts all week from people.
  • Monthly hangouts: we will have subject focused hangouts each month. The details of there will be worked out, but they will be announced with enough time to get involved. The goal of there is to keep the momentum of the summit and allow support and cross team working.
  • Weekly triage meetings of UI/UX feedback tag on trac: there will happen Mondays at 16:00 UTC, starting next week. @melchoyce and myself in #design on Slack will go through the queues. Everyone is welcome to join in, its a great way to learn about triage and also all areas of the project. We will begin with this being 30 minutes, but flexible to review that.

Wow that’s a lot we are going to do! The hope is this really gives options for people to join in. The #design on Slack is not going anywhere, you at any point can drop in there and ask for help or discuss design – please do!

As already mentioned, lets see this as an experiment and review in a few months.

Weekly meetings change

As of this week the weekly design meeting format is changing until at least July – we can evaluate after that. Instead of a structured meeting, there will be an office hours format. The first of these will be on Thursday 1st June 20:00 UTC. This means that if you want anything looked at or to discuss, just pop into the channel, but we will have no formal meeting.

This change will allow for upcoming travel and give us all time to focus on the core focuses and their design tasks. If we do need to discuss anything, we can always call a meeting.

As always, if you want help with something, or to contribute, the #design channel on Slack is always there. Feel free to drop in and join the conversation.

Testing the Gutenberg User Test

On 13th April 2017, I ran a user testing session at the Brisbane WordPress meetup to test out the Gutenberg editor. In the process, I also took the opportunity to reflect on the user test itself. Here are my notes on testing the test.

About the User Test

The user test, created during WordCamp London contributor day (a big shout out to @martinlugton, @j-falk, @lucijanblagonic, and @karmatosed for the hard work) consisted of 18 tasks. In my session, the set of tasks took around 21 minutes to complete on average.

The test was set up as an observational user test. The script gave the participants a task on each page, and asked them to rate the experience on a scale of 1 (bad) to 5 (good) scale. There was also an area for comments to be typed in. A sample question is shown below.

Image of the Gutenberg Test Script

In my session, I ended up with 3.5 hours of video footage, which took about 20 hours to process.

Observations

Wording of tasks

The tasks were very clear and unambiguous, perhaps with the exception of Task 2: You want to change the heading to a subheading. Some participants got hung-up on trying to make a heading, and inserting a sub-heading below it, but overall, this was a really minor issue.

Another minor suggestion is to remove the leading phrase “You want to…” from each task description. This is purely to reduce the number of words in the instructions, so that it takes a little less time for participants to process what to do.

Ordering of tasks

After running through a few participants, it became clear that the first few tasks were the hardest in the test. I’d suggest re-ordering the tasks to give a few easy wins for the participants, before throwing them into the more challenging waters.

Suggested task order: Task 1, Tasks 5-9, remaining tasks in order.

Processing video footage

The test was quite long, however, I don’t think this was an issue in the administration of the user tests… only in the video post-processing phase.

To make the video processing a little easier, it would help to make each question a different colour. This would make it a easier to find the right video segment when looking at each participant’s reel:

Image of participant reel

Survey questions

While it is always really tempting to include survey style questions to give us immediate feedback and nice, easy to graph results, I am not a big fan of including this type of question in observational user tests.

The reason for this is that there is often a big disconnect between how a user performs a task, and the rating that they assign to the task.

Looking at this particular testing session, here are some interesting discrepancies:

  • Task 2. One participant failed to complete the task, and gave it a rating of 2. Another completed the task successfully, but rated it as 2 as they got a little confused at the start.
  • Task 3. One participant rates a 5, but was evidently confused about the arrow interactions and movement of blocks. Another participant rates a 3, while providing all kinds of excuses why they failed to complete the task.
  • Task 4. Participant rates a 4 while articulating why they did not like the way the feature worked.
  • Task 11. Participant rates a 2 even though they completed the task successfully.
  • Task 14. Participant struggles, does not complete the task and rates it a 4.
  • Task 15. Participant rates a 5 even though they failed to complete the task.
  • Task 16. Two separate participants rate a 4 even though they fail to complete the task.
  • Task 15. One participant rates a 5 even they did not perform the task correctly. Another participant rates a 2, even though they did complete the task but found it fiddly.

Participants really hate getting things wrong, or disappointing the tester, so will tend to rate things higher. Although it is more time-consuming, I personally find that you get a lot more insight from observing, and really listening

“I would like to see the [heading] options go to H6 to be totally honest… in my experience, I generally probably only use H1 to H2… H3… very rarely will you go down to H6.”

It’s not unusual for participants to claim that they must have a feature, or can’t live without something, only to tell you a moment later that actually, they never use it!

Summary

Congratulations to the WordPress folks who put this test together. While I have some nerdy, fine tuning suggestions and changes, it is a really well thought out test and made for a great and enjoyable testing session.

Happy Testing, everyone! If you are new to user testing, or just getting started, check out my tips here.

This week’s design meeting agenda for May 18th

After a break we are back with weekly meetings. This week’s chat is happening today 20:00 UTC.

This weeks agenda is:

  • Open floor

Feel free to leave a comment and we can discuss anything people want.

See you in the #design channel in Slack

User Testing the Gutenberg Editor

Development on the new editor for WordPress is steaming ahead towards a big reveal at WordCamp Europe in June this year. Last week, I tested the Gutenberg prototype using the community-created Gutenberg testing script (a big shout out to @martinlugton, @j-falk, @lucijanblagonic, and @karmatosed for the hard work on this!).

Here are the insights from the analysis of the 3.5 hours of user test footage. Being a total UX nerd, I also took the opportunity to test the test.

Summary of findings

As the user test script contained 18 tasks, the detailed observations and video footage make this for a very long post. If you are after a quick summary, the main takeaways are that participants love the overall minimalist and modern direction of Gutenberg (kudos to all the WordPressers!) and they find the general concept of blocks and contextual menus really intuitive to use, confirming earlier user test results.

The main insights from this user test session pertain to perfecting the finer, detailed-level interactions:

  • Keyboard shortcuts, tooltips and search are a must
  • Inserting a new block is really, really hard
  • Inserting a new block is also a little confusing as new blocks lack definition and are not in-focus, making them easily confused for a whitespace
  • Moving blocks with the up and down arrows causes confusion due to displacement
  • Block drag-and-drop was expected
  • No conceptual separation between the block-level and content-level controls, which leads to some confusion
  • Fine-level interactions, such as when context menus pop-up,  are really important to get perfectly right

Although some of the things involve some re-learning, so to speak, once people see how to do something in the new editor, the uptake is almost immediate. I don’t think that being different, and involving a little re-learning, should be seen as a deterrent. It’s an interesting tradeoff. People are really excited about the new and modern changes, and I think they will absorb some re-learning.

User Test Setup

Participants were presented with the following setup and asked to complete the task as set out in the instructions were placed on the left. The changes were to be made in the Gutenberg editor window on the right. On average, participants took around 21 minutes to complete the 18 tasks in the instruction set.

A total of 7 (+2) participants took part in the test. All participants were WordPress users or developers with a wide range of experience. Two of the participants were in groups of two, the first group was a WordPress developer and his novice user client (both aged 30-50); the second group were two experienced WordPress developers (both aged 20-30). The remaining participants were a mix of WordPress developers (the first aged 20-30, the second also aged 20-30), experienced WordPress administrators (the first aged 30-50, the second 20-30), and a WordPress novice (aged 50+).

Detailed Observations

Task 1: You want to edit the heading to “1.0 Is The Starting Number”

Participants really liked the clean, modern feel of the Gutenberg block style editor. There were no observed barriers to using the editor in a general sense: participants were able to get in there and change text to complete task one without any major issues. They commented favourably about the contextual (floating) menus and were able to “get” these quite intuitively.

Yes, I like this… the required tools up the top… so the tools are coming to me instead of me having to track them down.

Contextual menus make things easy.

Task 2: You want to change the heading to a subheading

In the second task, there was some confusion about the meaning of “sub-heading”.  We thought that it perhaps detracted from the task at hand. Some participants focused on creating a heading, and adding a sub-heading rather than changing the heading level of the existing heading, as was intended by the task.

Some participants noted (and were confused) by the H-zero label on the top level heading, while others took a while to understand that H0, H1, H2 corresponded to different levels of headings. One participant made the suggestion that these should be called Heading, and Sub-Heading as these terms have meaning to people who write blog posts (as opposed to designers and developers).

I’m not used to seeing H0… to me, you have H1, and your entire universe lives below that.

Does H1, H2 make sense to people? If you are in publishing or in web, it’s very familiar but for “my mum”, would she get it? NO. Sub-heading, heading are more useful terms than H1 H2.

The interactions in this task began to highlight the importance of getting the fine-level behaviors perfected. As an example, throughout the user test there were cases where clicking in the block, or highlighting text in a block, did not activate the contextual menus. This observation led a lot of participants to look for these menus in other places. We lost a lot of people down the “right click menu” rabbit hole – in my tests, the right click menu was the default Safari browser menu, which turned out to be the source of a lot of confusion.

A second example that can be seen if you look at the footage closely is that participants were not making the distinction between block-level menus (the dropdown that switches between block types) and the content-level menus (the buttons that apply actions to blocks). This is evident in the footage from this task when you look at how many people click on the drop-down list in an attempt to create a sub-heading.

Task 3: You want to move the subheading down below the image

This task proved to be surprisingly difficult. Almost all participants expressed that they were expecting the blocks to be drag and drop enabled. Many intuitively looked to cut and paste as a way to move blocks around (the expectation was that keyboard shortcuts and/or right-click menus would work).

I believe that overall, much of the difficulty in this task is attributed to the cognitive displacement that happened when the block-move arrows were clicked. Participants were quite confused as to what happened when they clicked the up and down arrow. It’s possible that the right kind of animation on block move will help to reduce the displacement and improve the move experience. Adding drag and drop, and keyboard shortcuts for cut and paste are likely also must have features.

Task 4: You want to add a new page heading at the top titled “Numbers”

As a general observation, block insertion was really hard for participants. In this task, participants were unable to insert a paragraph at the top of the page. When prompted, they alluded to wanting some kind of element that would let them insert a new block – either at the top of the page, or more generally, between blocks. A number of participants can be seen exploring the move block arrows to see if there is a way to add a block above/below the current block from this element.

I am looking for something up here [top of the page] to add it [new heading block] in… so is that the only way to add things in? To add them to the bottom and then keep pressing up, up, up?… that’s less than awesome.

For the participants who were able to add in a new block, a number can be seen to not notice that a new block has been inserted – to many it just looked like an extra whitespace, not a new block. Once again, the detailed level interactions of inserting a block, and possibly giving it a stronger default presence and/or animation on insertion would help to improve the issue.

Oh… the new block is not focused when added, so it just looks like an empty whitespace.

Task 5: Make the name Walt Mossberg in the first paragraph bold

This task was completed with no observed issues. There was an expectation that the keyboard shortcuts would work, which they did!

Task 6: Separate the paragraph into two after the ellipsis (…)

This task was completed with no observed issues. Only a few participants noticed that two returns created a new block. One participant tried backspacing to see if the blocks would join back up again – which they did, as expected.

Task 7: You want to link the word Apple to ‘www.apple.com’

This task was completed with no observed issues. Participants expected keyboard shortcuts to work. A few wanted the ability to test the link to see that it was correct.

Task 8: You want to center align the paragraph

This task was completed with no observed issues, however, all participants selected the text, then clicked align. No one noticed that “align” was a block-level action.

Task 9: You want to add the caption for the first image with the content “Snow mountains”

This task highlighted the power of the block editing concept. The interaction with the image block, complete with the placeholder text for the caption was totally intuitive to use.

There was a glitch that was noted by one of the participants in the caption field – when they tried to backspace, the cursor jumped to the end of the word.

Task 10:  You want to align the first image to the right

This task was completed with no observed issues, however, a few participants raised questions about how this would work with themes. A few expressed surprise that the image changed size, but I suspect this was related to the terminology in the task instructions related to “alignment” versus “wrapping.”

I expected it [the image] to keep it’s size. It was simple to do [right align] but had an unexpected result for me

A number of participants noted that the image looked really strange when floated right next to a heading block, as this created a bunch of white space. One suggested that some blocks should be made “full-width”, i.e. not allow images to be floated next to them.

Although this was not directly mentioned by the participants, I suspect that they would have found image resize handles quite natural in this block.

Task 11: You want to make the second image full width

This task should have been quite trivial but raised a couple of interesting observations. Firstly, tooltips are needed on all buttons. Almost all the participants can be seen pausing before clicking on the full-width button. Some directly expressed that a tooltip would have been welcome.

…I wonder how this would work outside of this… how this would work with templating, most templates would have a wrap around the entire contents section… I don’t know how this would work with most themes, or anything with a side-bar as well. So I think that’s a pretty cool feature but I wonder how that would work in real-life templates

Some participants struggled with understanding what full width meant, in the context of the text being presumed as being full width already. I suspect that a slight terminology change could resolve this issue, perhaps full-bleed or hero image (we’d have to test these :-).

I guess that’s full width… it’s funny… I thought that this part down here kind of counted as full width, not the full page… so that was a bit unexpected

Task 12: You want to remove the caption for the second image

This task was completed with no observed issues. One participant pressed backspace twice and deleted the whole image, which raised the issue of keyboard shortcuts for undo.

Task 13: You want to change the quote to your favourite Steve Jobs quote, “It’s more fun to be a pirate than to join the Navy.”

This task proved to be a little hard as participants had trouble finding the quote that they were supposed to edit. For those that found the quote block, changing the text was not difficult.

This task highlights again the lack of distinction between block level and content level contextual menus – you can see participants exploring the block type switcher dropdown and the two quote type buttons and being unsure about what these are.

A number of participants also noticed a glitch in the link part of the quote block. Clicking into the link part of the quote did not always show the link button in its active state, and sometimes, did not display the URL in the add link dialog.

Image of Link and Dialog glitch

Task 14: The date for the Steve Jobs quote is now wrong. It should be 1982

This task was conceptually easy to complete, but without exception, proved to be really fiddly as editing the last digit did not include the edit in the existing link. This caused all manner of fiddling around by participants. Kudos to @spocke for implementing the new link boundary feature coming soon to TinyMCE which will (hopefully) eliminate this user angst forever!

Task 15: You want to update the quote attribution link to ‘en.wikiquote.org/wiki/Steve_Jobs’

This task was conceptually easy, but re-surfaced some of the glitches around link insertion. From observations of the user tests, it would be really handy if a first click in the attribution link section selected the entire link. This should be the case with the updated link boundary in the next release of TinyMCE.

Task 16: You want to change how the quote is presented. Change it to the alternate quote style

This task was completed with no major issues – most participants had already noticed the quote style buttons and changed the quote style easily. There were a few participants that did not get the quote style buttons, and proceeded to jump right into the right click menu rabbit hole. You can see some using the font menu to apply italic font, and marking their task as completed with success.

Task 17: You don’t just want to share quotes by Steve Jobs. Create a new quote block with the quote: “Your most unhappy customers are your greatest source of learning” from Bill Gates in 1999

This task should have been completed with no issues, however, it re-surfaced the difficulty that participants had in creating (inserting) a new block.

“Now this is where it will get more difficult as I still can’t see an easy way to get text [a new block] in…”

Participants liked the pre-defined structure of the quote, although found it tricky to click into the attribution section. Some managed by tabbing into the field.

Task 18: You decide that you don’t want this block to be a quote any more. Change this block to a normal paragraph of text

This task was completed with no observed issues. However, only two participants noticed that the conversion from quote to paragraph made them lose the text that was in the attribution field. One of the participants remarked that it may be a good idea to concatenate the text from these fields, rather than lose it.

As a side observation, this task raises the question of whether it makes sense to permit block transformations that can result in data loss? For example, converting a paragraph to a quote makes sense, but does the opposite (quote to paragraph) make sense, or will it lead to unintended angst over data loss?

 

If you’d like to conduct your own user testing session, follow these setup instructions from the Make WordPress Design team. To learn more about how to conduct user tests, and what pitfalls to avoid when testing, check out my post here.