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.
The project
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.
The process
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.
Conclusion
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.
