Designing Wildcard 2.0

Designing Wildcard from the ground up for a major 2.0 release

Last week we released a brand new version of Wildcard into the App Store. You can download it for your iPhone here. A week after launching I am very proud to say that Wildcard was featured in the App Store and shot to #1 in the News Category!

Wildcard.app featured in App Store

Being recognized by Apple was not without a lot of hard work—nearly 7 months of it—with by far the most talented team I’ve had the pleasure of working with. If anything, the design of 2.0 has taught me what it means to truly design a premium experience. In essence the value design can deliver, once communicated to the team, will only resonate with the folks who download your app. Here are some of my favorite reactions to Wildcard 2.0:

While it is great to see comments from folks who are really enjoying Wildcard there is much to be done. You could argue that post-launch is an even more difficult time to design in. As it goes, we are receiving all sorts of feedback over email and we’ve been proactively monitoring networks like Twitter, and forums like Designer News for more responses. That said some folks are bringing up reasonable concerns like this one from Cemre which is in regards to our animations.

With all of this happening so quickly I thought that it would be a good time to look back and briefly reflect upon what it took to get 2.0 to where it is today.

Design matters

As I mentioned above, releasing Wildcard 2.0 was not without many hurdles. The hardest of which—though the one I’m proudest of—was building a culture that values building great user experiences. Each feature and initiative we take on at Wildcard begins and ends with deep design and product thinking. That said, while our engineering prowess is certainly core, and paramount to the experiences we build, each consumer facing feature starts and stops with deep product design discussions which involve team members from all disciplines.

These product discussions really help to push both our design and engineering teams to new heights, sometimes forcing us, as a company, to make tough decisions—especially when the team is split on a feature. For instance, if we are not confident that we are moving our own needle, if we lack the ability to shout “this is awesome, this feels great” then we must continue to iterate before releasing. Generally these tough decisions come down to votes, it’s an easy way for us to move forwards while respecting everyones opinion.

That idea may come off as callous, and understandably so. However we have all worked hard to ripple this mantra throughout the company as it helps keep us true to our values. It is only with the best intentions that we might hold back on releasing a feature or product offering.

Now that we are on Apple’s radar after a very successful launch, this will never be truer. Holding the design bar to a premium will require sharper eyes, and even tougher decisions.

Our Process

Let me make this simple, we do not have a specific process.

There I said it. But truthfully, it all depends on the problem at hand. Sometimes we jump right into Sketch and then make a clickable prototype in Marvel. Other times, we fire up Pixate and drag rectangles around the screen only to eventually replace them with real assets down the road.

If we need to talk through something we do our best to meet in person—it is usually the most effective. We’re all in the same office (most days) so grabbing someone and talking through a problem in real time is the most effective way of getting shit done. Of course, we use Basecamp and Slack for the majority of our online communication as these tools help people from around the company weigh in and provide more detailed feedback which, in turn, helps us as designers.

If anything I would say that our design process is considered. Meaning, we take our time and make decisions with intent. What I mean by this is that we are sure to make decisions that will have a positive impact on a users experience. We weigh many scenarios, edge-cases, technical considerations, etc. when evaluating design problems in order to deliver meaningful, user-focused solutions.

So again, our process depends on the task at hand. If it is something we hold confidence in, our process is quick and swift, while other times it may be slower and more considered.

Feeling

There are many things that need to be felt when designing an experience such as Wildcard. That’s to say that we almost always design with real assets and data. Very rarely do we actually wireframe—per say. Apps like Sketch make it very easy to copy objects from one artboard to another, so in turn our designs always feel real. But we don’t stop with static design tools, nearly every animation and transition was prototyped using a design tool before we prototyped in code.

Ahh, prototyping, we do it a lot. Not always, but very often. Again it really depends upon the project at hand and what we need to accomplish. But prototyping is the simplest way in which we can feel a design out. Thankfully there are a ton of tools available so finding one that works for you is just a matter of trial and error.

By my best guess I would say that 90% of the prototypes we built for 2.0 were done with Pixate. That is really for two reasons:

  1. Pixate is incredibly intuitive and easy to use
  2. Prototypes built in Pixate feel native.

I can’t stress enough how important obtaining a native feeling is. If a prototype feels rough, if the scrolling is janky, it won’t work for us—Pixate passes this bar with flying colors.

Below is an example of one of the prototypes I built using Pixate. If you’d like I’ve made the source file which was built in-house here at Wildcard available below.

Wildcard + Pixate Swipe to Go Back Prototype

Download Pixate prototype source file
View Pixate Prototype

Viewing prototype requires Pixate.app iOS / Android

While I personally am a huge advocate of prototyping tools they do not solve all design challenges.

As I mentioned above we are always looking to feel a design out, and sometimes prototyping tools do not allow us to reach the level of fidelity we need. This is why once we’ve designed a feature we immediately try and implement a first pass with real code. Building a culture in which we can get to code quickly has been critical, and informative, to our design process. Static mocks, prototypes and conversations only help us to get to code more quickly.

Marketing

Wildcard landing page design

Designing our app was only one piece of the problem—albeit the biggest one. Once we had a design language for the app we moved on to focus on our marketing materials. The halftone pattern that Khoi had designed for the app ended up having a huge impact on how Wildcard felt. With time we realized that this design language could become a powerful piece of the Wildcard brand.

To make it really sing however we needed to push the effect even further than we had in the app. For lack of a better term we needed some “pop” This really helped to make our landing page and social advertisements pop off of the screen.

What’s next

Well, there is a bunch of work ahead of us. While there are many new initiatives and experiments underway now is a time for critical focus and fast iteration. To that note, we as a team are working hard to improve the user experience for all of our users, while also focusing on designing and testing many new initiatives. Outside of our iPhone app however we also have a lot of work to be done for the traditional web. That means not only our landing page and documentation sites but more specifically how cards work on the web, plus improving our editorial and engineering tools—the pages that power Wildcard.

Thanks for reading about the design of Wildcard 2.0. This project has easily been one of the most rewarding and challenging design projects of my career thus far. We have much work ahead of us, don’t forget to download Wildcard in the App Store today!