Wow, loving the feedback that came in about the welcome screen. Thanks everyone!
I’ve got another design challenge for ya. What (if anything) can be done for the “add new” buttons?
They don’t really look like buttons to me. I tried simply adding the new default button style, but I wasn’t a fan. Thoughts on how these could be improved?
Mockups welcome… 🙂
What we talked about today:
- Briefly touched on @lessbloat‘s post about an advisory group. We should discuss that more right there in the comments of that post, especially if you are linking to resources. Basic consensus is that it’s a great idea.
- The things we’ve observed and learned from the three user tests that have been done so far. @lessbloat is also going to run some tests focusing on the CMS-type tasks. We discussed low hanging fruit as well as bigger things we can approach, whether for 3.5 or 3.6. More details on those will come in follow up two separate discussion posts. We need to be disciplined about being data-informed rather than data-driven (especially in these small sample numbers), the prioritization of tasks, and being realistic about effort levels and commitments.
- Pre-flight checklists for things that should always have eyes on them before a release, or rather, before a cycle nears beta. This includes things like the about page and welcome panel as well as process lists for things like patch review/testing. Ideally we’d formalize a few of these. As @jane said, checklists save lives, really!
- A very quick discussion about the process of UI in WordPress core, from design-y side things like graphics and mockups to turning them into Trac tickets and code/plugins/patches. We need to get back to the way things were/supposed to be and dig up an old post on the process. Briefly, this means that design iterations can happen right here on Make UI rather than Trac, as Trac can be intimidating for some folks and often does devolve into linear discussions about details and code. As a team rep, I (@helenyhou) will be happy to summarize for #wordpress-dev chats or on Trac as crucial points are hit. For those who aren’t as comfortable with code and/or SVN, we should buddy up in pairs or small teams and work together to get working code and then turn that into a patch. For example, a design and front-end type can work with a dev proficient with SVN to get their idea turned into a nice clean patch, or a design-type can work with a dev who’s still learning about contributing along with a seasoned contributor. Again, I’ll facilitate folks getting set up to work together as needed, but since we’re all very friendly, there’s a good chance it’ll happen naturally. There are also going to be clearer paths for discussion and review.
I would like to note here that we encourage plugins for proposals that involve UI changes because not all people (or realistically, the minority of people) know how to apply a patch or have an environment in which to do so. A plugin, whether or not it’s actually in the .org repo, is a better way to get non-coding types to have a go at testing. I think this is sometimes not well communicated or understood and can come across as a brush-off, so I thought I would write it out here again.
Things to do:
- Discussion posts here on Make UI – coming shortly. These are going to function sort of as writing prompts.
- Yet another survey post about contributors so we can have a reference point for teaming up.
- We should write up some documents like “Getting Started with Contributing to the UI Group”, guidelines for things like QA/testing, RTL, and accessibility, and some of those checklists mentioned above. Remember that we strongly encourage iteration 🙂
I’d like to propose the idea of an official “WordPress UI Advisory Group”.
As you may have already guessed, I’m a big fan of data informed design. You’ll notice that I didn’t say “data driven” design. There is a difference between being data informed and being data driven. If you’re data driven, you are being lazy by allowing the data to make decisions for you (bad). If you are data informed, you are using the data to help you validate your hypotheses and make informed decisions (good).
Let’s say your gut says you should move a signup button from the right side of the page to the left. In testing the button on the left, the biggest thing you should be looking for is to ensure that having the button on the left doesn’t completely tank signups. Even if the data tells you that having the button on the right is slightly better, you should trust your gut.
Summing it up
Use your existing knowledge to make a hypothesis. Use user testing as a safety check. As long as your change doesn’t sink the ship, trust your gut. Use data to help you make informed decisions, but don’t let data bully you around.
How does this “Advisory group” fit in?
Core WP provides a unique challenge, in that there isn’t a super easy way to gather usage metrics. We can’t just slap KissMetrics or Google Analytics into core to see how users interact with the software (and for good reason). We’ve got to be a bit more creative.
I’ve been trying to think of a few ways that we could get feedback from users throughout the design process. I’d like to start with a simple email list.
Why would people sign up
I’d like for this email list to be a venue for people to contribute (thus shaping the direction of WordPress) without having to commit to spending any specific amount of time. They’ll simply:
- Add their email to the list
- Receive emails periodically with either 1) short 1-3 question polls, 2) simple click tests, or 3) requests for feedback about a certain design
- Participate when they have time, and unsubscribe if they lose interest (or get too busy)
Where would we promote it?
Wherever we can get away with promoting it. 😉 But to start, we’d just add the subscribe field to the top of this blog (keeping it simple to start things off).
Where will the list live?
I’d likely just set the list up on Campaign Monitor (unless I hear objections to that idea).
Note: I do know that it’s holiday time in the US. However, I think it would be best to have this discussion this week rather than next week on the day before the dev chat so we have some time to absorb and think thoroughly.
In anticipation of the dev chat for 3.5 scoping on July 11, let’s take some time to discuss the findings of the user testing @lessbloat so wonderfully ran and then see what that means in terms of things we can actually accomplish, or “actionable items”, if you will. Not everything we discuss has to be with 3.5 specifically in mind, and they can be both enhancements and dream features, but we should aim to come out of the meeting with some items that we can confidently propose to accomplish within the cycle, or even better, early in the cycle.
We should also take a little time after that discussion to talk about the actual process of iterating designs, the code to power said designs, cross-browser and accessibility issues, code testing and review, and submitting patches for core. For those of you who aren’t comfortable with SVN/patches/the code-y bits, don’t worry one bit. We’ll be talking about how we can combine our collective strengths to get things done together.
P.S. CSS coding standards have not been forgotten. In fact, they are available for you to see and comment on, if so inclined.
It’s summary time.
We’ve run 3 users through the same set of scenarios (via usertesting.com). You can review the results here, here, and here.
Now… What exactly are we trying to accomplish with all of this?
It’s important to note that we have to think about these discoveries in the context of the typical WP user. But to be honest, I’m not entirely sure I know what the “typical WP user” looks like (but I hope to dig into that over the next couple of months ;-)). Sure, I have assumptions, as I’m sure you do, but my assumptions aren’t backed by any sort of data.
The important thing to keep in mind here is that these 3 people were paid to perform a list of tasks. While we can benefit from watching their interactions (and looking for patterns of complexity/confusion), we need to recognize that the flow they follow is prescribed, and likely different in some ways from an actual user.
Overview of discoveries
Here’s an unfiltered list of observations across all of the tests:
- Had trouble figuring out how the color selector worked (x3)
- Unsure what “QuickPress” was
- Unsure where “1 post”, “1 page” came from under “Right Now”
- Had lots of trouble finding a link to view their site
- User clicked “Select files” when they actually had a URL to paste (and should have used the “From URL” tab). (x3)
Post Add New
- Lost all changes when she clicked a link taking her away from the new post page (after already making some changes)
- Didn’t notice “Insert into post” button when adding an image in the media modal
- Clicked “Preview” button, but didn’t realize a new tab had opened (causing confusion)
- Doesn’t appear to be a clear path for users that just wish to post a photo
- Had trouble knowing where to go to change her site title (x3)
- User didn’t notice links in toolbar (x2)
- User never noticed “+ new” dropdown (x2)
- The blog dropdown menu is completely different when in the admin vs. on site (should it be?)
- Confusion over why the header image was changing (x2)
This is where I need your insight/input.
1) First, is there anything that you noticed that’s not on this list?
2) Next, which of these do you think we should attempt to address (are there any quick wins that would benefit all WP users)?
3) If you had to prioritize your list, what would you tackle first?
I’ll hold off for a day before I post my thoughts. Don’t be shy! 😉 I’d love to hear what you think.