Our team at MetaLab is piloting this new thing when we start on a new project, and it’s working really well. At the very start of the project—once we have a rough idea of what this product or feature looks like—our team block off a full day. Then we each go away individually and design the whole product in one day, solo. No wireframes, no user testing, no iteration, no feedback or sharing.

If this sounds wrong, it’s because it is. Good product design work is done by doing the exact opposite: starting broadly and exploring lots of potential solutions in really rough fidelity (sketching, wires), working collaboratively and getting feedback from each other early and often, and testing and validating our assumptions with users.

The reality is that after we do this exercise we regroup, share our designs with each other, and then go back and do everything again, the right way, over the course of a few months. So why do we do this? Well, there’s a few really exciting things that happen with this exercise:

1. Blank slate syndrome: Starting on a net new product or feature is hard. The more ambiguous the idea is, the more daunting this first step is. The beauty of the Tarantino is it puts a forced constraint on you and leaves no time to waver over how to approach things and makes you just DO it. For me, it’s the same clarity of thought and creativity that comes with procrastinating on a task and leaving it to the last minute.
2. Throw down the dumb idea: I love getting the bad ideas out of the way. Just like crazy eights, the interesting solutions often come after the obvious, boring ones. A Tarantino lets you get those top of mind ideas out, and lets you see where (or if) they break down in execution.
3. Pinpoint the hairy problems: Doing a Tarantino is like doing a test run of a ski slope. You get to see which part of the product or feature you vastly underestimated complexity of, and need to allocate lots of time and exploration to in order to nail all the gotchas. Now, when you go to design the product for real, you can plan accordingly.
4. Get aligned: Because we all go away and work in silo before coming back together, everyone’s vision for how the product should work and be designed is different. I love seeing how each of us has interpreted the problem differently, and this lets us having fruitful conversations around the benefits and drawbacks of each approach. Doing this early, and with something tangible in front of us means we have a really solid alignment on the problem.
5. Get a wealth of explorations to start from: Since our full team does their own executions, we effectively get a variety of ideas to draw from that are usually quite different from each other.
6. Keep the good ideas: Every time I’ve run a Tarantino, some nuggets of really great product ideas come out of it. Take these and develop them further.

There’s a lot to be gained here, and I think it’s a great investment of one or two days time. Give it a shot on your next project!

P.S. Oh, why is it called a Tarantino? It’a a witty name Brandon_Arnold came up with because Quentin Tarantino movies are known for their non-linear (time travelling) story structure.

P.P.S. Prior art: I’m sure we are not the first to have adopted this approach. I know many other design teams have “discovery” phases, but I haven’t heard of ones this short. For further reading, there is also this great post by Stuart Eccles on a related topic of designing into the future with some great ground rules.

The Tarantino: how to do product design the wrong way and learn from it was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few weeks ago I was chatting with my coworker about a health app her team was working on. She was certain that one screen had too much copy but when she used the prototype herself a funny thing happened: it felt really great. That screen with too much copy was actually the result of a test telling you all the things you didn’t know about your body. It was exciting and insightful so the length felt just right. The lesson: using something yourself — for real — is an easy and powerful way to validate (and innovate on) a product you’re working on.

Dogfooding in product is fairly commonplace. But it kind of falls short when it stops at catching bugs and validating how useful a product is. We can use that amassed empathy using a product to inform more significant design activities such as a big product redesign, a new nav/IA structure, interaction model, onboarding, or a new feature.

Ok, so what if it’s hard to be your user? Let’s say they’re a doctor using an app to treat a patient. That’s when you talk to real doctors and step into their shoes to understand how to use the app and, most importantly, why they take those actions. It’s like method acting; you try to take on the mentality of your user (based on the research you’ve done) so you can understand meaning behind the actions they take.

User interviews and user testing are super powerful, and par for the course when doing design research—but so should using the product yourself (or a prototype of it) for a meaningful amount of time. Doing so, you take in the pains, delights, and insights you heard from user interviews and experience them firsthand. This is not to say you should assume you can be a stand-in for the user; do user testing too! The difference though, is that you have the benefit of bringing the critical mindset of a designer. This is when magic happens. Features make sense because they solve your own problems, shortcomings are painfully clear, and you see opportunities that a user might not.

I was working on a community discussion product a while back. Up until that point, the design work was broken up into isolated design components, which led to some nice solutions for those discrete parts. The problem, though, was that the whole product experience never got considered. This is where being the user fit in. We hooked up a prototype and tried it, pretending to be a user reading posts in the community.

After a while we realized that we were spending a lot of time jumping in and out of different conversations, so we came up with an idea to change the interaction model to keep the conversation list always visible, similarly to a two pane email inbox. This introduced some exciting opportunities for animations that strengthened the user’s mental model of the app’s spaces, which helped usability. More importantly though, we created an interesting approach that deeply aligned with how we wanted to use the product — traversing different conversations quickly with less time spent switching views.

That’s the important part: by being the user you can actually be innovative. You synthesize the entire experience of using a product, and then instead of broadly (blindly?) exploring ideas in the hopes of finding innovation, you can use your experience with the product to guide you towards promising directions. You stop thinking about individual job stories or features and instead grasp the entirety of the product. Think about complex design problems like challenging a standard design paradigm, exploring a different interaction model, or introducing personality, emotion and delight. Good solutions to these problems hinge on thinking holistically and actually doing something to improve the product experience and deliver on user needs. Attempting to be innovative without understanding how a product is used leads to meaningless design that is flashy but shallow. Being the user helps you avoid that. You can create something new not for the sake of being unique, but to create a solution that is grounded in the user’s overall experience and change it for the better.

Let’s innovate by being users was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR — We Journeyed Into the World of AMP and Learned Some Stuff

We teamed up with Google to focus on The AMP Project and received a dream brief: create anything your heart desires, so long as it helps push the boundaries of what’s possible in AMP’s codebase and component library. As we share what we built and learned along the way, we’ll also give our take on AMP’s importance, who it’s for and where it’s going.

What is AMP?

AMP is an open-source framework for building efficient, high performance web pages. It’s currently used primarily for editorial content on mobile but is growing beyond this for wider usage across different markets (and screen sizes).

Seeing Both Sides

Before we go any further on our own experience, we’d like to acknowledge that we are well aware of the criticisms and aren’t going to pretend AMP doesn’t come with any; it does. We simply took this project as an opportunity to chart down our own path and make our own impressions. From our experience, there are some misconceptions we’d like to help clear up.

AMP allows site authors to host a static mobile-optimized version of any of their site pages which distribution platforms like Google cache and serve to users. Much of the AMP criticism is targeted at Google’s approach to caching the serving AMP pages from the google.com domain. What is worth clarifying is that the AMP page cache and the AMP HTML mobile optimization framework are separate products. A page built using AMP HTML can be privately hosted on any server, you can take advantage of all of the framework’s features without having Google host your content.

Don’t Let the Name Fool You

AMP stands for “Accelerated Mobile Pages”. In the simplest of terms, it blocks most of the elements which causes the web to load slower on mobile, like large amounts of JavaScript, third-party tracking scripts and bloated CSS. It allows content to almost instantly load. AMP was designed for cached pages, but it is now growing into a broader toolset to fix the mobile web (as the majority of users are mobile today, some site loads still can take minutes). Although the M stands for Mobile, AMP can absolutely help improve loading speeds on any device or browser type.

The Brief

In July, The AMP Project team came to us to push the limits of what’s possible in the framework, showcase its capabilities and help content creators realize how they could better use it to bring the web to life. We were essentially given free reign to use all of the tools provided by AMP to combine and implement them as we saw fit with the goal of creating an entirely new experience that had yet to be built with the framework.

What We Built & Why

While we still had to work within strict guidelines to ensure the code was valid AMP, we aimed to come up with the craziest possible concepts within those defined boundaries.

After some brainstorming, we landed on the idea that online art galleries and museums are typically fun, abstract and don’t play by the rules when it comes to following conventional gridded web layouts. With that idea in mind we created a faux art gallery as proving grounds for redefining what was possible in AMP. We built a site that used the best of the initiative and built on its foundations. Our teams relied on the power of AMP to ensure the site was incredibly performant, while introducing new features and components into the framework including custom parallax experiences, hover states and more. We even had a little fun with the possibility of an immersive VR version done in AMP for consideration. Try our proof of concept in your phone here.

Next, we thought about more commonly used experiences on the web that could benefit from AMP’s capabilities. We ended up exploring what was possible in a travel booking app, allowing users to search destinations, filter by activities, and find things dynamically; all while maintaining the speed and performance AMP is commonly known for. We sweat the details on this one in delight — pushing the AMP framework as far as we could with micro-animations and hits of personality.

Who is AMP For?

Today, AMP is geared towards people on the go who are heavy into editorial style content (news and blogs on their phones) and e-commerce. Where we imagine strong adoption will take place is with sites that strive to be beyond performant or have a wide range of international audiences. Currently, the average mobile web page on a 3G connection takes roughly 19 seconds to load and almost half of the world is still running on it — this obviously needs to be improved and AMP can help. As the web continues to lean predominantly mobile, creating efficiencies here is both logical and essential. AMP can potentially provide a blueprint for improving access to information in developing countries.

Are We Living in The Future?

Not quite, but making progress daily! AMP sites found online today are still primarily media, news & editorial content (for now). The benefits are obvious, as being built on AMP provides a serious performance and discoverability boost. Is AMP and its aspirations the future of all web? Maybe. Maybe not. One thing’s for sure, the learnings and best practices the framework is helping establish are definitely here to stay. AMP is also building atop of the latest and greatest in the web in real time with rollout of its features. Its development community is constantly striving to keep up to date with new trends; proactively pulling in the web’s upcoming functionality and giving it to you today.

Development lessons based on our learnings from AMP

As it relates to developing within AMP, we learned some things along the way we thought would be valuable to share. Notable insights below:

1. AMP forbids custom JavaScript outside of an iframe, forcing you to rely on its library of optimized code. This is done to ensure that no poorly-optimized or nefarious code has the opportunity to hinder the user experience. We notice many, otherwise well-built sites, can become slow from the inclusion of megabytes of advertising and tracking scripts. The importance of optimization and careful vetting of any JavaScript code included on your site is a very important takeaway from AMP.
2. AMP prioritizes the content that is visible to the user. It knows what content is below the fold and defers loading or rendering it until necessary. Visitors to AMP pages will never have to wait as all of the loading images and ads block their access to the page. Additionally, if a visitor never decides to scroll down, none of their mobile data is wasted loading content that would never be seen.
3. AMP has solved “loading jank.” On an AMP page, every element must have a deterministic known height, whether it be an ad, an image or video, or a paragraph of text. You will never experience content shifting on your screen as elements above load in.
4. Ad performance: AMP sets the new bar for ad integration on sites. Ads must behave properly on the page and should comply with optimal user experience. Goodbye full screen takeovers and other obnoxious content you don’t want on the page. AMP enforces that ads behave like good citizens.

In Closing

This opportunity was challenging, fun and provided some fresh perspective. We were given a lot of flexibility, while at the same time had to find unconventional ways to adhere to set conditions within the AMP framework. We learned a lot more than what we thought we knew going in about AMP and uncovered some previous misconceptions. In working within the framework, we came away with an even stronger understanding of where the web is going and how it can learn from AMP. If you’re interested in building your next site within it, make sure to check our templates, which are completely open-source, free to use and downloadable at ampstart.com.

AMP’ing Up The AMP Framework was originally published in Making Internets on Medium, where people are continuing the conversation by highlighting and responding to this story.