Taking the “Design Challenge”
10 learnings from when a product guy tackles design
With the recent relaunch of peakery.com, a hiking website for the world’s mountains, I challenged myself by trying my hand at leading design for the first time… the “Design Challenge”. Needless to say, it was hard, I made a bunch of mistakes, but I also learned a few things (let’s say, 10) as I stumbled through the product design process:
- Set design goals around gems and aspirations to get where you really want to go.
- Go straight from sketching to Sketching.
- Design along decision trees.
- Choose colors based on legibility, prominence, contrast, and brand.
- Use cards to solve tons of responsive design challenges.
- Create spec sheets (and don’t buy a new laptop).
- Use Invision FTW.
- Always be sharing.
- Design is an evolution, not a destination.
- You can do this.
- Set design goals around gems and aspirations to get where you really want to go.
OK so how to begin? I found it useful to form design goals around 2 categories: gems and aspirations. Gems are existing things in your product that are popular with a significant subset of users. Aspirations are things that expand your product in new directions or take it to the next level.
In the case of peakery — an existing, user-centric site — an obvious first step was to analyze how people were using it now. Did peakery already have some “gems” that could be polished to make things grow? To help answer this I turned to Nir Eyal’s Habit Testing framework from his popular book Hooked:
Who are the most engaged users?
Are there any recognizable patterns in their engagement?
Is this group at least 5% of active users?
Based on Eyal’s rule-of-thumb, if your product has at least 5% of active users engaged in a distinct, repeated engagement pattern then you’ve got something to work with — a gem. My analysis revealed that 6% of peakery’s active users had logged 20 or more of their climbs in the past year — sweet, I’d found a gem!
These same 6% of users also contributed missing peaks, data corrections, and peak photos at rates 7.3x, 4.4x, and 2.4x, respectively. Basically they were the lifeblood of the site. Which leads to a goal:
peakery design goal 1: Get more users to log more climbs, the key habit defining the most engaged users of peakery.
Outside of encouraging the central habit of logging climbs, additional analysis revealed other areas that needed attention. Most of the 70,000 summit logs so far were extremely low quality, i.e., 75% with no photos and 56% with trip reports less than 22 words. I wanted peakery to aspire for better.
peakery design goal 2: Improve the content quality of new summit logs.
Another area where the site fell down was featuring the great photos that users were adding on a daily basis. Most of them were buried under several navigation layers and weren’t given enough prominence on the screen. The thousands of photos from people’s mountain adventures were a clear gem.
peakery design goal 3: Surface and more prominently feature photos throughout the site.
Last, the analysis revealed a huge desire for users to contribute peak data to the site. What peakery allowed users to improve was limited to only a few data fields, but even so some users would contribute every day for months at a time! At the time, peakery was mainly a site to log your climbs, not a place to find the info needed to go hike a mountain, such as route info, GPS tracks, difficulty ratings, etc. If peakery let users contribute these new types of content, would they add them? The opportunity to grow peakery into a valuable hiking resource was too compelling to pass up, leading to the aspirational goal:
peakery design goal 4: Transform peakery from a ‘check off your summits’ site to a full-blown hiking info resource by allowing users to contribute new types of content.
Reaching out to top users (directly and through a quick survey) was also a good idea to do a gut-check on these redesign goals:
2. Go straight from sketching to Sketching.
That’s right, skip the wireframes. I found that sketching in a notebook (preferably grid-ruled) was the quickest way to dump ideas out of my head and escape any urges to waste time pretty-ing things up on the computer. We’re talking probably over 100 pages of crude sketches of rapid UI experiments.
After that, I dove right into pixel-perfect Photoshop mocks, skipping the wireframing stage, for 3 reasons: 1) the sketches in my notebook were good enough for me to get the basic layout going, 2) very quickly in the mocking process I could usually sense if things were heading in the right direction and actually coming together well on the screen, and most importantly, 3) in the actual process of mocking I’d be able to quickly try many different layouts and iterate in real-time.
I used Photoshop to create almost all of my mocks on this project — 942 of ‘em! As I created more mocks, I felt a lock-in effect with Photoshop as I’d copy/paste elements into new PSDs and create different versions. Also I started to get really facile with it. But encouraged by designer friends, late in the process I forced myself to use Sketch instead (to design peakery’s emails). WOW. It’s so much easier and unbelievably lightweight. Positioning and aligning elements is much quicker than Photoshop. Also for development, love that everything you see on the screen can be expressed in code (and it generates all the CSS and slices for you at the press of a button). Often with Photoshop it was impossible to match the PSD comps exactly. Sketch is a game-changer for quickly creating mocks that can actually be built.
3. Design along decision trees.
After some initial spiraling around, I stumbled into a structured way of designing the UI that resembles a decision tree:
- Map out all of the things the user needs to see and do on a page.
- Group them into logical areas (navigation, sub-navigation, stats, long-form text, etc.).
- Tackle each UI challenge with conventions.
- If stuck try some crash-and-burn experimentation.
- Sleep on it.
- Cherry-pick your design wreckages.
- Keep going!
I once read that for every UI decision, Apple would create 7 pixel-perfect mocks featuring completely different concepts and then take the best ideas from each. I ended up doing a mini (mini) version of this for each UI issue I was trying to solve. For example, the first page I designed was peakery’s “peak page”. In my dropbox I count 182 PSD versions of the peak page! That’s some mind-numbing iteration. Often I’d hit a wall trying to solve a UI problem and then it’d be time to try “experiments”: whacky ideas that probably were going nowhere. But the amazing thing is most of the time these “insane” versions would shed light on better ways to solve the challenges. Creativity was key to keeping the design moving forward.
4. Choose colors based on legibility, prominence, contrast, and brand.
I must have spent hours in my mocks flip-flopping nav/subnav/filter bar/header/footer elements from dark-with-light text to light-with-dark text. Sometimes I made a decision and moved on only to then take a quick look back at the opposite and change my mind. Maddening (and annoying to keep changing like that using Photoshop).
I now realize that I was flip-flopping so much because I was continually assessing colors for 4 things: legibility, prominence, contrast, and brand. Here’s what I ended up with for peakery and why:
Content text: #fff background with #333 text to make it the most legible. #000 for text is too intense on today’s screens!
Top navigation and outer background: #333 background to frame the body content but #666 text for the links to not grab too much attention away from the body content.
Subnavs: #fff background to separate visually from the top nav and #999 link text to not grab too much attention away from body content.
Buttons and links: the impossible to ignore #f24100 with #fff text for key actions and its complementary color #00b1f2 for less prominent actions. These 2 highly saturated, attention grabbing colors also supported a new modern brand image that I was seeking.
5. Use cards to solve tons of responsive design challenges.
When I think back about this whole design process there was one breakthrough day that stands out. I’d been iterating on the desktop design for 3 long months and finally had something I thought would work while conveying a good emotional design. But when I tried to apply it to mobile or tablet, all hell broke loose. Photos and text just wouldn’t fit well across the full width of each device.
The next day, I tested the waters with a card UI paradigm throughout the design. And right away everything started to flow and snap into place: turns out cards were so well suited (ha!) to show all the disparate pieces of content throughout the site because:
- Cards naturally separate different chunks of content well with high contrast between.
- Card headers and footers can house titles and important ‘more’ links elegantly and consistently.
- Card bodies can easily feature text or photos across the full widths of screens, especially important for phones that have limited horizontal screen real estate.
- Cards can fit any height of content easily.
- Card bodies can easily be divided into grids. The peakery design quickly evolved into a 4/3/2 card grid layout across desktop/tablet/mobile.
6. Create spec sheets (and don’t buy a new laptop).
Since mocks only present one possible visual option at a time, I also needed a good way to show all of the variations of what happened when a user did X and Y and Z.
Turning layers on and off in Photoshop doesn’t do a great job of presenting these interactions holistically. And using Basecamp and Google Docs was just too text heavy. Ideally I wanted to see all of the variant mocks together at once with textual specs explaining all of the different scenarios.
Enter what I call the Spec Sheet, also known as a Redline. This is a huge canvas doc (I had to distribute them as JPGs because that proved to be the only manageable format). It contains info like:
- color palette and patterns found in the mocks
- responsive threshold screen widths
- sizes of elements in points and pixels
- mocks for desktop, tablet, and mobile
- detailed spec notes for each feature (with arrows pointing to the mocks)
- interaction & exception case UIs (like Forgot password)
Again, I really wish I’d been using Sketch for Spec Sheets (both for creation and distribution)… I actually ended up buying a more powerful laptop just because these PSD docs were grinding my machine to a halt. Don’t do that!
7. Use Invision FTW.
There was life before Invision and life after — it perfectly fills a needed part of the design process. It’s so dialed for creating clickable prototypes that you can easily share to gather feedback along the way. Once I had draft designs in place for a large portion of the site, I took a deep breath and shared them via Invision with friends and 50 top members for feedback.
Nice! The initial reaction was highly positive but more importantly people shared a ton of specific feedback for improvements. One valuable Invision feature is the ability to tie feedback to specific parts of any page. Often this led to focused, actionable discussions about specific elements on the page.
8. Always be sharing.
Many times in the design process when things got stuck in a rut the answers lay outside of myself. Sometimes you’re just too close to it to see things with a fresh lens — you need other people’s thoughts to move things forward. It’s hard to always have an opinion about each and every possible design element option — you need to show them to people and see what they think.
Every time I shared with people, new issues came up that I hadn’t thought of: usability yes, but also interaction and emotional design issues. It’s amazing to think that pretty much anyone can take a quick look at what you’ve been working on so intensely and immediately provide new insights on problems lurking within. Share often, this is not a time to keep secrets or go “stealth”.
9. Design is an evolution, not a destination.
Looking back through the design evolution of peakery is striking. My first tries were complete amateur hour and didn’t address a host of UI/UX issues. But after months of working hard at it, the latest-and-greatest versions started to really excite me and were just begging to be built. They factored in user flows, interactions, and emotional delight. They scaled well on any screen size. And they provided clear solutions to each of the 4 goals I’d defined at the start of the project. You can see some screens and read about the new features here or just go to peakery.com to see it in action.
All of that said, there’s still a long list of outstanding design improvements that didn’t make the cut before launch — little inconsistencies, UI issues, inefficiencies in user flows, etc. I’d love to work through these. But more importantly, after a bit more time it’ll be possible to see how key metrics have responded to the new design. Analyzing these will inform new goals that will lead to a whole new slate of UI and UX improvements. There’s really no end to the design, just stops for new directions along the way. Design is a constant evolution, not a destination.
10. You can do this.
Trying my hand at design on this project was a huge challenge. It was never easy but along the way I picked up some actionable learnings from things that worked and things that didn’t. I hope some of what I’ve shared helps you to take the Design Challenge too.
If a n00b like me can get there — so can you. It takes an intense persistence to keep improving and a constant openness to trying new ideas. It takes as much feedback as you can get along the way. It takes a “nothing is sacred” attitude and an understanding that no design is truly ever done. Dig in and you’ll find what it takes.
But it doesn’t stop there; time to build!
This post covered the first part of making the new peakery. The next part — the development phase— provided a host of learnings as well. I’ll save that for a 2nd post (after we fix some more bugs!).
