This was such an eye opening feature for me. Several of my team members were discussing the the need to save drafts in the Customizer. I got pulled in and was able to lend UI/UX support to the project.
Over the course of about six months we worked on the issue. I learned a lot about the needs of an open source project, and the importance of understanding the priorities you’re working with. It’s a lot different than simply having a single stakeholder that you’re trying to design for.
Following are some of my sketches (just a few, there’s more!) showing the process we went through to try and create an elegant solution.
The project started for me when my teammate reached out with a sketch, proposing some initial ideas for where we could take the flow for saving and publishing. We hopped on a call together and talked through this flow. From there I created a sketch to followup and simplify my understanding of the interface.
This served as the launching point for several further iterations and discussions. The benefit of creating a simple sketch like this, as opposed to a finish prototype, is we could think through problems and have discussions before introducing a ton of extra time into finessing the interface.
From there I kept playing with ideas, based on feedback from the team, with attempts to simplify things and make sure that the flow made sense for a user trying to manage the status of a post.
The process got messy, as the above diagram shows. We played with a lot of ideas, and ended up scrapping most of them.
I began to create some flow diagrams to show how each part of the interface would connect with other parts.
Finally I shared an Adobe XD prototype (diagram above) with the whole interface worked out. We thought we were in a good place with this.
Until we received some feedback on needing to simplify things again. So, I went back to the drawing board. It’s critical to recognize in any project the need for returning to lower fidelity when confusion arises, or rapid changes are needed.
After this point I needed to return to client projects, so several of the Core team were able to improve the work here and push the project across the finish line. You can see the final work in the Customizer today within WordPress.
I spoke about this at WordCamp Seattle 2018, but I wanted to dive into a short post to talk about some of the contributions I’ve been able to make.
Since 2016 I’ve been involved in one way or another, helping out in a number of issues related to the WordPress admin experience.
Here’s the thing, you don’t need to be a developer to make a huge impact on this project. As a designer I’ve been able to help out on a number of issues and make a small impact on the project by being willing to jump in where needed. A few ways I’ve been able to help:
On November 11, 2018 I was able to speak at WordCamp Seattle on my experience contributing to WordPress Core as a non-developer. In 2017 I wrote about my initial experience, and now now I’ll be planning to expand on what’s happened since.
Let me tell you, it’s been an amazing ride! For years I’d had interest in helping out in the open source community and supporting the making of WordPress, but I wasn’t sure how to get started. That initial article highlighted the start of my journey.
Since then I’ve been able to help out across a few projects and make a different where I can providing design feedback and at times jumping in to do design work.
I shared my experience to encourage others to get involved. There are folks from all kinds of backgrounds with wonderful expertise that they could offer to open source projects. A lot of times it takes a little encouragement to figure out how to get started.
Jonas Downey, from Basecamp, shared an article this morning about his experience in creative work. I agree 100%. You can read his full article, which I highly recommend.
“Start thinking about productivity in terms of quality time instead of clock time. You might end up making the same progress with only 20 energetic hours that you would have made in 60 tired hours.”
In creative work I’ve found that 2-4 good hours is far more valuable than 8-12, if it’s the right time of day, and if you can set aside uninterrupted time for deep work.
“When you’re tired, distracted, or in the weeds on something, it’s usually better to stop working. Just admit (temporary) defeat and give yourself a chance to regroup. Do something else that’s less taxing, or call it quits and start again later.”
Agree 100%. Pushing through and slogging is much different than breaking through when you’re in the flow.
When you enjoy your work there can be a natural bent towards encouraging it to become all absorbing. This can also happen if things are going very wrong at work.
Last week I was really inspired by a book from the guys at Basecamp. This, along with the writings of Cal Newport, has given me the head knowledge to recognize the need for setting boundaries in my work and my life. However, an intellectual acceptance of something, and even at times wholehearted actions to take things in that direction, isn’t always enough. It’s easy to get busy, to get into your work and not come up for air.
Over the past two weeks I’ve gone back to practicing a separation. On Friday afternoon I stop my work, and I don’t check email or Slack until Monday morning. In addition, each afternoon after work I turn off Slack and email (notifications especially, I don’t have those anymore) and don’t check until morning. If previous attempts at this are any indication, the most likely culprit for falling back into previous patterns is an upcoming event or deadline.
My goal is to see if I can identify the things that trip me up and work to prevent them. If I’m able to stop thinking about work when I’m away from it, I can focus on other things I care about; leaving me fresh and ready to tackle work again the next morning.
A few months ago our team at XWP was tasked with the challenge of building AMP Stories in WordPress. We began working with the team at Google to come up with an initial minimum viable product.
Following are some of my messy sketches showing our process and what it took to move from the initial idea to a released product. I find sharing the process is as important as the final product as it shows the thought and deliberation that went into it, and helps open up discussions for further improvements.
We didn’t have an unlimited period of time to work on it, so we knew we’d have to work quickly to try out some ideas and create a shippable beta for sharing with users and stakeholders.
AMP Stories are a mobile format for sharing articles and content in a tappable way. They’re similar to how Instagram Stories function. The idea with bringing this format to WordPress is anyone using the AMP for WordPress plugin would be able to create their own stories without needing to code a custom solution.
At the start of the project it made the most sense to build the interface for AMP Stories using Gutenberg, a soon-to-be-released editor for WordPress. This gave us the opportunity to work with a new editor and pave the way for experiences that could improve Gutenberg as a whole.
My role on the project was to design the user experience. I worked closely with several of our team as we all brainstormed and looked at ways to make this happen. The initial problem was around AMP Stories themselves. At its most basic an AMP Story has several parts to it:
A bunch of pages
Layers inside each page
Elements inside each layer
An AMP Story can be as few as one page, and could easily number 10-50 pages. We needed to somehow match that to the block interface in Gutenberg.
Initially this felt right, like it should work. However, we weren’t quite sure how easy it would be for someone to build a story using this editor. We also didn’t want to introduce unnecessary complications for users.
If you’ve ever used a program that has layers built in, such as Adobe Photoshop or Sketch, you’ll be familiar with the concept of hiding and showing layers in a way that allows you to manipulate content. Below is a sketch showing the elements that might normally be shown in a layers palette.
We knew we’d need to make sure it wasn’t too complicated to edit pieces of one layer without overwhelming users with things on other layers.
With this idea of trying to match all the parts of an AMP Story to the available parts in WordPress, I began sketching ideas for the interface in collaboration with the rest of our team. Products like this often require lots of iteration before we can settle on a solution.
So, I tried out a bunch of ideas.
If you follow the initial conversation on Github, you’ll see that we started by wrestling with the concept of the story, the pages within the story, the layers, and elements in the layers. This first sketch, color coded accordingly, attempts to figure out what that interface could look like.
And here is another sketch thinking through that concept further. Please note that for the sake of brevity I’m skipping a few things.
From the first few sketches and ensuing conversations I was feeling like I had figured out the problem, and was itching to go from simple sketches into a more complete design (using Balsamiq wireframes).
As I’ve shared before, this is ok to do, but be cautious! The moment you go from a simple form of visual sketching into something that’s more detailed there’s some risk. This is called going from low fidelity to medium fidelity (and then eventually to high fidelity). The problem is you’ll sometimes get so stuck in something you’ve spent hours building that it’s hard to scrap it if things are going wrong.
I was thinking that the layers and blocks could fit into a tab interface right on top of the story. That sounded right in principle, but in reality it didn’t make sense when I shared it with the team.
I tried some other ideas, and we also agreed that pages shouldn’t be in a tab, instead they should just go down the page as linear blocks; reducing one extra user element, that’s good!
Well, after chatting with the team we realized this wouldn’t make sense, it was still too complex. I even created a bunch of screens and showed a video walkthrough of the user journey. It wasn’t working. So I went back to simple sketches again.
This is where we landed on a concept that made it into the final product. We knew we wanted a way for users to be able to select different layers and elements, and knew it’d be important to make that visually simple, so we added small layer cards next to each page. Viola!
We had further discussions to make sure we were on the right page, and decided we were headed in the right direction.
We started getting the idea of the layer cards a little bit more fleshed out. One design element I hoped to simplify with the card icons was the types of layers. Since a page can have several different layer types (fill, thirds, vertical, horizontal) I wanted to create different icons for each one.
At one point we had a discussion to make sure the selectability of the layer cards made sense. I sketched out the various selected states. Our idea was that if a bottom layer was selected all layers and elements above that layer should be hidden, to allow for easier editing.
That was a good idea, but we needed to make sure the layer cards helped with showing which layer was active.
We finally landed on an idea that felt right, didn’t get overly complex, and was worth building out for real world testing.
I then took the rough sketches and created a prototype and user journey for creating a basic AMP story.
From there our team was able to develop this into a beta feature for the WordPress for AMP plugin with Gutenberg as the platform. You can also view a clickable prototype of the work in Adobe XD.
This was a wonderful project to work on. The team was great to work with and we created a useful MVP within a short period of time. The work was built using our own expertise, best practices in UX in WordPress, as well as feedback from a handful of folks.
Projects like this are always challenging and fun and offer opportunity to figure out the best thing to build with as simple of a user experience as possible.
If you’re curious and want to try it out you can download the latest version, keep an eye on XWP’s blog for an updated post.
Tomorrow I’ll be turning 31. Instead of writing about being 30 at the start of the year, I want to share my thoughts on the last day of it.
I could speak directly to experiences in my life (I’ve had many wonderful ones!), things I’m thankful for (the list is long), or people who mean something to me (close connections have made me who I am). Instead of that, I want to touch on a few points today that have impacted me deeply:
Comparing yourself to others – It’s easy for me to look at others and compare myself to them. I could use another’s station in life to mentally push them down in order to lift myself up. I could look with jealousy at someone who, from my viewpoint, has it better. All of that is pointless, and damaging to relationships and my sense of self. Instead, my goal is to strive to be the best version of who I’m meant to be. If there’s to be any comparisons made, it should be between where I’ve come from and where I intend to go. My journey isn’t the same as anyone else’s, and to create comparisons isn’t healthy or accurate.
Leadership qualities – For me leadership has been an interesting thing to discuss and an odd ideal to pursue. We can talk about servant leadership, micromanaging bosses, or absent managers. In my experience a little book, “Turn the Ship Around!”, has been one of the best pieces of advice on the topic. A true leader looks to create leaders that think one level higher than their rank (in a naval context). Instill in others autonomy and guidance to make their own decisions, then back them up or gently steer them in the right direction.
Striving in your career – Without vision you won’t go anywhere. There’s an interesting point between going all in on an idea, fully invested, versus not caring or simply holding back. Over the past year I’ve seen opportunity to push the boundaries on things I’ve believed in. The results, while not what I expected, have still brought about answers that can move things forward. The takeaway for me then is: in the work you pursue strive to do something worth doing, go big, be daring. However, in the doing, don’t invest all of your being into that work, keep a part set aside for your outside of work life.
This life is a special one that we’re given. I want to use it to build relationships that matter, and help lift others up.
Anxiety doesn’t generally come from making decisions, but rather from the time spent deliberating on whether to make a decision.
At a certain point there’s enough information gathered, and a choice should be made. That choice isn’t always Option A vs Option B, but could include Option C all the way to Option Z.
If you’re struggling with a decision, use the best data you have now and decide (even if that means intentionally deciding not to act, just be direct about it). You’ll be wrong sometimes, but the anxiety of it will hopefully lessen.
You can tell someone what you’re thinking, and convey that in a way that you believe is correct. But that’s only a very small part of what it means to communicate something.
Communication happens through the words you choose to say, the words you leave unsaid, the way your words are shared, and the language your body is presenting (if you’re in person). You also communicate through the way you approach a project, how you talk to your team members, what you choose to share publicly and what is only said behind closed doors.
You also communicate through built up trust over an extended period of time. If a close friend tells you something that’s hard to hear, but says it in just the right way, it might have an impact. If a coworker with a bone to pick says something in a spiteful manner (even if they’re right), well you’re unlikely to take much notice.
All of this, and more, is important to keep in mind when trying to share your thoughts. It’s the responsibility of the sharer to convey what they mean to share.
Writing down an idea is a way to gather your thoughts and think through a problem. It’s also a way to decompress after a long day.
I’ve found over the years that I need to get out what I’m thinking in some form. Sometimes that comes down to sharing with a close friend how my day or week went and breaking down the pieces that occurred. Other times it means writing a daily update and sharing with my team.
Then, sometimes, writing means taking the idea or concept I’ve been struggling with and retooling it in a way that I can share more publically. Sure, this could benefit someone else reading this, but more importantly it’s an outlet for me to add some structure to my thoughts.
If you have found this helpful, or have any specific feedback, feel free to reach out!