(Works best on a larger screen.)
Working with a live prototype gave me confidence in several decisions:
The slider’s minimum value should be 1px, and the maximum should be either the column width or the uploaded image’s original width—whichever is smaller.
If you resize an image from 500px wide to 300px wide, and then drag it from a 600px wide column to a 200px wide column, the image needs to scale down from 300px to 200px to fit. But if you then drag it back to the wider column, you don’t want it to stay 200px wide or reset to the original 500px. You want it to revert to the 300px that you manually set it to.
If you then drag that image to a 400px wide column, resize it to 400px—the maximum allowed in that column—and then drag it back to the 600px column, it should reset to the original image dimensions. To make this behavior more explicit, I made it so that when an image was resized to fill the column width, the value displayed as “Full width” instead of the pixel width and height.
If you give an image a fixed width but move it to a column where it takes up the full width, the fixed width is still remembered in the background. Only if you explicitly change an image to full width does this behavior reset.
As I have just demonstrated, these behaviors can be hard to explain and understand in writing. So the prototype would later prove useful when communicating with the engineers and testing the final implementation.
Playing with the prototype, I also found that it would be useful to add keyboard support to the slider, to make it easier to make precise, pixel-level adjustments.
Ultimately, skipping the heavy plugin experience and providing a live and immediate resize control made it much easier to find the right size for each image.
For image cropping, my job was not to reinvent the cropping interface, but to integrate a familiar tool in a way that saved our users time and effort. If you’d ever cropped an image before, you should be able to use this tool too.
Unlike resizing, it turned out not to be feasible for cropping to happen in context, since the constraints of email design didn’t allow for easy control over position, aspect ratio, size, and what was actually in the crop region, all at once.
Instead, I opted for the crop tool to transform the email builder interface into a cropping workspace.
Building on the existing structure, and using animations to transition between modes, helped maintain the context.
When going back to crop an already cropped image, it would open the original image file, but with the last selected crop region active. This made cropping non-destructive, as the user could always go back and keep tweaking, without the risk of losing their work.
Like with resizing, I decided to build a realistic prototype of the cropping interface to get a better feel for the finer points of the experience.
Play with the cropping prototype
(Works best on a larger screen.)
Compared to Aviary, there was less friction (time, effort, and risk) involved in cropping an image. But you still couldn’t see how the final image would look in the email while you were cropping it.
Prompted by a comment that came up in a review session, I came up with a split-screen solution, showing a live preview of the image in-context next to the cropping tool.
Play with the split-screen cropping prototype
(Works best on a larger screen.)
With the split-screen added to the prototype, it was clear that seeing the result live while editing would take most of the guesswork out of getting the crop just right.
Our improved image resizing and cropping both went live before Adobe pulled the plug on Aviary, so there was no interruption for users. For cropping, we initially launched an interim version without the split-screen to make sure we made the deadline.
We barely got any complaints about removing the low-use tools. Overall, the customer response has been overwhelmingly positive.
I love the new photo cropping and sizing. That saves me an enormous amount of time. Thank you for making that feature so much better.
Email builder userCustomer Effort Score survey feedback
Although we removed 8 of 10 image editing tools, the two tools we kept were brought to the forefront and made considerably more usable.
As a result, usage went up by 20%, from being used by 38% of all active users, to 46%.
The approach we chose also leaves a lot of leeway for further iterations.
Some of the ideas from the prototype, we dropped from this release, such as an exploratory “suggested crops” concept which would analyze the image to suggest good compositions and areas of interest.
Our customer interviews also sparked other ideas for the future. For instance, letting designers apply and lock “styles” for images (aspect ratio, color tint, etc.), so when their clients use the template, they can change the image content but not the image styles.
By dismantling image editing into individual tools, we’re not locked into a third party and their way of doing things, but free to solve the customer’s problems with precision.
(Works best on a larger screen.)