Posts About Sparks
Posts About Sparks
The Foundation team has cut your development time in half again. Today we're thrilled to share Foundation Building Blocks with you- a comprehensive, open-source library of coded UI components you can drop into any standard Foundation project to give yourself a massive head start in your projects.
Hundreds of Coded UI Components for Your Foundation Projects
The Foundation Building Blocks library has been rebuilt from the ground up with over 100 code snippets in six categories including Navigation, Status, Control, Media, Containers and Form components. Built by the ZURB team, these are the most common and useful design patterns and UI components we've found in our two decades of web development work. Just browse the library, select the Building Block you need, and copy and paste the code into your project.
Powerful Kits to Help You Build A Diverse Range of Sites
Download ZURB-curated bundles of Building Blocks called Kits that are organized by project type so you have exactly what you need to build specific kinds of websites and apps. There are seven kit types available including Blog, Portfolio, Ecommerce, Marketing, Dashboard, Mobile App, and Travel - each containing the specific mix of Building Blocks you'll need to complete your project. Unlike a template, a kit doesn't dictate a page layout or design, but rather gives you a set of ready-to-use components that integrate naturally into your design.
Components Created by the Global Foundation Community
Battle-tested by designers and developers around the world and reviewed by ZURB, the Foundation Building Blocks library will continue to expand with components created by the Foundation community. Have an idea for component or pattern? Submit it using our easy to follow guidelines and it will be reviewed by the ZURB team and made available to the community.
Code That Will Cut Your Development Time in Half
Building Blocks are specifically built for Foundation projects, which means you won't need to worry about compatibility issues or dependencies. You won't find any pointless experiments or explorations, either. Instead, you'll find real, usable, and practical components every designer needs based on our two decades of designing for the web.
Both Kits and Building Blocks can be easily downloaded from the website. You can also copy and paste individual Building Blocks into Foundation projects. After installing the new 2.2.0 version of the Foundation CLI, Building Blocks and Kits can even be downloaded and installed automatically into ZURB stack projects, available instantly as ready-to-use partials. Simply run
npm install -g firstname.lastname@example.org and then
foundation kits install <kitname> in any project for Kits or
foundation blocks install <blockname> for individual Building Blocks.
We've been using Building Blocks internally in our client work to give ourselves a head start in our projects, and we've seen our development time cut in half. We're excited to see the Foundation Building Blocks library continue to grow with new Building Blocks and Kits from the ZURB team and our amazing community of Foundation users!
There's a revolution happening right now. The way we think about and design websites is going to change again. Old conventions and methods are being replaced by exciting new technologies that open up entirely new ways to design and build the web. And they're available today.
Out With the Old
Most early websites in the 90’s were little more than digital brochures, which makes sense since the web was born from the world of print. Our options as web designers for laying out content fell short of what was available to print designers for many years. Slowly but surely, our tools got better and we discovered new methods and techniques that allowed us to do some incredible things. The web came into its own, but the world of print still exerts its influence on the way many designers think. To this day we still call web files “documents,” arrange our content in “pages,” and try to fit the experience of users into sitemaps.
But pages are limiting. Pages are a convention of print- they don’t fit for the dynamic, interactive medium that is the web. Users don’t look at websites in some linear order, they journey through them, they explore through multiple pathways. We have a completely transformable, liquid canvas to paint this picture with, but we aren’t using it! The next decade will see more customization, personalization and predictive technologies that make the content and presentation fully dynamic. The factory line, widget production line mentality no longer applies- each user can have a unique experience.
In With the New
Over the last two decades, ZURB has pushed the web forward through our design work, and wth Foundation, the world’s most advanced front-end framework. Foundation was designed to help people take full advantage of the power of the web. It was the first framework to give designers a responsive grid to work with, the first to be mobile-first, the first to be semantic, and the first to be constructed with Sass, and the first to have accessibility built in to give designers and developers the tools they needed to make a user experience. Just last year, Flexbox was added to expand layout options even more. And we’re continuing to bring technology advancements to you. We're excited about a new technology that we think has the power to dramatically change the web, a technology that finally transform websites into the completely moldable, interactive, and customizable experiences we have always envisioned they would be. That technology is CSS Grid.
We’ve been experimenting with the possibilities of CSS Grid for months, and we’re incredibly excited about what we’ve been able to achieve. Here are three Playground Pieces that demonstrate the possibilities of CSS Grid, each with huge ramifications for Foundation:
1. Foundation CSS Grid Examples
First, an exploration into the the possibilities of CSS Grid with Foundation. In this grid we explore three different possibilities enabled by CSS grid. First a responsive data component that uses tabular views where space permits, second a responsive navigation “mega menu”, and finally a complex layering of content that previously would have been complicated and fragile to implement. Each of these can be a new component within Foundation. These also highlight how with CSS-grid, we will be able to evolve even components that previously were dramatically different to morph into one another responsively.Foundation CSS Grid Examples
2. Foundation CSS Grid + Container Queries
Next, we take one of these CSS-grid enabled components in Foundation and explore the possibilities that arise when combining it with another hot new technology: Container Queries. Container Queries take the concept of media queries and allow you to apply it to containers within a page - letting you truly create components responsive to the space available to them. In this exploration, we combine a responsive data view with an expandable navigation, using container queries to automatically adjust the data view based on the space available to it. While container queries do not yet have browser support, there is a first class polyfill and we are making them a first class citizen within Foundation.Foundation CSS Grid + Container Queries
3. Foundation Grids within Grids
Finally, we take these concepts to the next level. Proponents of CSS Grid often talk about the page-level layout possibilities, but by combining CSS Grid with container queries we firmly believe that we should be thinking beyond the page, and into nestable, reusable, grid-based components. In this final exploration we explore the possibilities of nesting grid based components with Foundation, with the inner component able to move seamlessly between parts of the other grid, formatting itself intelligently based on the space available to it. Foundation’s grid has always been flexible, but with CSS Grid hitting browsers the potential to mix, match, and combine grids is quickly becoming a reality.Foundation Grids within Grids
What CSS Grid means for Foundation and the Future of the Web
Foundation has always led the way for how the web is designed and built, and we’ve been preparing ways we can help you harness the power CSS Grid. We see a future filled with radically responsive components that morph and change depending on the circumstance or device. The development of CSS Grid will enable the very concept of grids to change from a massive structural choice to something more like components. Imagine having a set of grid components that allow you to get entire layouts and sublayouts right out of the box, and then nesting, combining, and recombining them.
Browser support for CSS Grid is exploding, with several adding support just this month:
- Chrome. Enabled by default since version 57.
- Firefox. Enabled by default since version 53.
- Internet Explorer. Enabled by default since IE10
- Opera. Enabled by default since version 44.
- Safari. Enabled by default since version 10.1.
The term “web page” is starting to feel very, very... inadequate. CSS Grid opens up layout in ways that were not possible before, and our minds are racing with the opportunity in front of us. We hope these experiments will get you as excited as we are, and demonstrate a little of what’s possible with this new tool.
ZURB works with companies every day to help them reimagine the possible with regards to their web applications, websites, and products. Do you have a project that deserves to push the limits? Feel free to get in touch, we’d love to work with you.
Designers working on web projects in 2017, in some ways, face more challenges than ever before. They have to create engaging websites, apps, and services that work seamlessly across all devices and work for a global audience at a pace that seems to speed up every year. That audience too is more tech savvy, have higher expectations and are more design literate than ever before and expect near perfection. Faced with these challenges, it's more important than ever for designers to be aware of emerging trends, solutions and patterns that can help them solve common issues, capture the full attention of their audiences, and deliver amazing experiences.
Here at ZURB, we've helped hundreds of companies surface the best solutions and take advantage of new patterns in their websites and products. We've created this list of 17 design and development trends we think every designer should be familiar with to shape their 2017 and well beyond.
(In no particular order...)
Taking its name from the architecture style of the 60's and 70's, Brutalism in design consists of bold, in-your-face collages of text and images, where anything goes. Echoing the web from yesteryear, Brutalist sites often employ simple markup, inline styles, and harsh colors and gradients. Some even argue that Instagram's new(er) gradient logo could be classified as Brutalist, with it's 90's esque neon colors and gradient design.theoutline.com
Pascal Deville, an authority on the Brutalism trend, and founder of brutalistwebsites.com defines the movement as this:
'In its ruggedness and lack of concern to look comfortable or easy, Brutalism can be seen as a reaction by a younger generation to the lightness, optimism, and frivolity of today's web design.'
But not all Brutalist websites are an all out attack on the eyes. A few sites like Bloomberg News and TheOutline.com borrow from the aesthetic while adding a level of polish not typically seen in most sites.
We think designers can use Brutalism to set their site apart from the rest with bold color choices, large typography, and layouts that break away from the common hero-image-then-3-up pattern.
- The Brutalist aesthetic makes good use of typography, so choosing the right typeface is critical. Check out these tips for conveying the right typographic voice.
- Brutalist websites run the gamut from mild to wild. Get inspired with these examples.
- Spotify has been flirting with this style for a while. Check out how they make use of bold colors, strong typography, and a collage inspired layout.
2. Large Screen Design
When most people think of responsive web design, they think of shrinking a website down from a desktop to something that looks great on a tablet or mobile phone. But this is ignoring a growing segment of users, those that have large scale monitors. Yes, while mobile has certain exploded in popularity over the last ten years, so has extra large monitors with ever increasing pixel densities. The problem is that most focus has seemed to be on the smaller side of the spectrum with, few sites truly catering to their large screen users. By looking at your data, you may find that the majority of your users, or at least you're converting users are on displays of 1920x1080 or higher. There are a lot of cool and creative ways to use that kind of screen real estate and clever designers are not afraid to go big.apple.com
- SVG’s are perfect for large screen design because they are scalable, resolution independent, have small file sizes and are supported by most browsers. Here are 10 resources to learn more about them.
- Targeting SVGs with CSS allows you to do cool things like using media queries to hide and reveal parts of an image by screen size. Check out our lesson to learn the basics.
- The Interchange component in Foundation uses media queries to load the images that are appropriate for a user's browser, making responsive images a snap. It decreases the load times for mobile users while still serving the bigger content to your visitors with higher screen resolutions. Learn how to use it.
3. Responsive Components
It's been nearly 8 years since Ethan Marcotte introduced the concept of responsive web design to the world, and we've seen it develop at an incredible pace. There are new techniques and technologies on the horizon though, that are going to dramatically simplify the write of responsive elements and make today's responsive sites look simplistic and naive. Some examples are element queries and the upcoming CSS-grid spec. These two technologies will enable web designers and developers to create experiences that are truly tuned to every device size. Element queries will allow creating components that are responsive based on the space allotted to them rather than the full screen size, while CSS-grid allows us to dramatically change layouts based on media queries.
Between the two, we believe we will see dramatic increase in the diversity of responsive patterns easily available to designers and front-end developers.
- Element queries and container queries open a new horizon for responsive components, here are 10 resources to learn more.
- The Foundation team broke down how responsive components work and what’s coming in the near future in this recent article.
4. Device Specific Microinteractions
As Nick Babich pointed out in a recent post on Medium, microinteractions provide users acknowledgement they crave. Popular apps like Slack have skillfully weaved them throughout the entire experience, delighting users and making the app feel more intuitive.
By taking advantage of whatever is available to them, device specific microinteractions will only serve to make microinteractions more compelling and personal.
- Learn the basics of microinteractions, why they’re important, and how to use them.
- Playing around CSS animations and transitions can help you build and test some neat microinteractions. Here’s a few techniques.
5. Split-screen Design
A simple way to highlight a contrast, balance text with images, or share two different products, split-screen design has grown in popularity with many designers. Easy to implement, split-screen design is a great way to present content in a way that feels fresh and balanced. For products or sites that require a comparison, split-screen design is a no brainer.theoceanfortlauderdale.com
We've seen some really creative uses of split-screen design, and we think people are only beginning to scratch the surface. We're looking forward to new ways this pattern can be used to tell a unique story and guide users.
- Get inspired with some great examples of split screen design on Pattern Tap.
- Still need inspiration? These 20 examples showcase some really creative applications of this trend.
- Nick Babich offer some clear best practices for split screen design you should definitely adhere to.
- Just because they’re simple doesn’t mean they’re easy. Here are three things to keep in mind when building a split screen layout.
6. Reactive Animations
We think we'll soon see more technologies that push what's possible in the browser, led by animation heavy interactions.
- Our Reactive Listener playground piece is a great example of how reactive animation can be used to highlight content to users even before they take action.
- By harnessing the power of JS and a little CSS, combined with the capabilities of modern browsers, we can deliver experiences that are responsive, fluid, react to user input and give native mobile apps a run for their money. Here are 10 resources to start with.
7. Refreshing Card Based Interfaces
While cards have been around for years, they are a solution that is not going away anytime soon. A pattern tailor made for responsive web design, they make it easy to display large amounts of information in a way that is easy to browse and simple to implement. In recent months, we've seen them used for more than text and links, becoming hubs of all kinds of rich media. Designers are playing around with rich microinteractions within cards themselves, and are finding ways to make this old pattern new again.google.com
We see no reason to abandon tried and true patterns that solve common problems, and are excited about the new experimentation we're seeing with cards.
- Cards are all over the web, but we still see designer making these 5 mistakes.
- Not a big reader? Learn how to avoid those 5 mistakes by watching this video.
- Cards are the basis for a ton of successful interfaces. These 10 resources will help you figure out how to best use them in your project.
- Foundation’s new Flex cards open you up to all kinds of possibilities. In this lesson, Rafi breaks down how to use this new component.
- Nick Babich highlights some best practices of using a card based UI in this incredible article.
Download the PDF for 10 More Trends, Exclusive Resources and Tutorials
The world of the web moves at light speed. It requires designers and developers working in it to constantly soak up new information, techniques and strategies to stay effective and impactful. To help them stay up to date and on top of new trends and solutions, we publish Responsive Reading, an email magazine covering new developments in responsive web design each month. It's free to sign up, and if you join now you'll get a free copy of our 17 Responsive Trends PDF that contains all 17 trends along with links to resources, tutorials and articles that will help you implement these trends in your own projects today.
Remember when the web was a collection of static websites, largely HTML, no CSS, and layout done with tables and frames? How about even farther back ' when your choice of mediums for design were print, film, industrial, and maybe even radio?
What about the aforementioned mediums is consistent? They were all linear. That meant we could think about things going from A-Z and stop there. Even when we got digital interfaces (enter HTML), we continued to think of interfaces as static screens for decades. It made things simple, and we put our focus into cutting the amounts of clicks on that trail to get people to the end faster. The data even seemed to prove it, with more clicks equaling 'bad' and less clicks equaling 'good.' This especially seemed to ring true in the eCommerce world where it's been accepted that the more hoops you make your user go through to buy something, the less sales you'll see. It was estimated that $4 trillion (Yes, that's trillion with a 't') was left in abandoned shopping carts in 2014, and so an entire industry of 'click reducers' have sprang up, 'optimizing' checkout flows to get people from A to Z in 1, 2, and only if necessary, 3.
That Takes How Many Clicks?
Today MV* frameworks (Model View *Whatever; Angular, React, etc.) are all the rage, and even the most basic websites have some way to serve up content or state dynamically on the fly. In the early days of the web, and still largely prevalent today, this stuff got served up from the server side. AJAX, jQuery, and the late-comers like Angular and React took that concept and ran with it ' allowing us to render all that state on the client side, unleashing the power of front-end developers and designers alike.
Many practitioners of design across various mediums often try to divorce themselves from technology. Technology is temporal and transitory; it evolves and never stays still. Good design should be permanent and everlasting (Or so our hubris gives us cause to think). This is actually a good thing, as we force ourselves to think about the constraints of the opportunities in front of us, not the technology that currently binds it.
Unfortunately, the reality is that designers don't really divorce themselves from technology, they just root themselves to past constraints that no longer exist. We still think about our website designs like they're print designs. We think of proximity in design as keeping like-things grouped together nicely on the printed page. Those savvy enough to realize their designs aren't print, but a series of hypertext documents, think of clicks instead of nearness ' but they're all wrong.
How many times have you heard someone say, 'Yeah, but that'll add an extra click'. Hearing that comment 5 years ago, I would have responded, 'Gosh, you're right, we gotta rethink this interaction thing'. Today I would respond entirely differently, I'd say, 'I don't give a crap how many clicks it takes'.
Websites used to be reeeeally slow. In pop culture we make fun of this fact, the stereotypical example is a nerd in his basement eagerly awaiting a pornographic picture to load on his screen. An hour passes, and he's thrilled to see it finally fully rendered on the screen.
Fast forward to 2016 and websites are lightning fast, that kid in his basement has more pictures than he knows what to do with. His mom is worried. And you, designer, should be too-- but not for the same reasons. You should be worried because you're still designing for static proximity, and the least amount of clicks to the desired input.
Where did we get this notion of clicks? Well, as exampled above, it used to take a long time to load a screen. Designing an interface that required a user to wait minutes before their content was available after clicking was, and still is, a big no-no. How long should we wait for a screen to load in 2016? According to Web Designer Depot, the desired time is 500 milliseconds to two seconds. Mere milliseconds more than the blink-of-an-eye.
We measure successful interactions in clicks because it was inferred that clicks take time, and add minutes to the end-user's experience. If I'm running an e-commerce store, or a marketing page, I need my user's experience to be as frictionless as possible. The logical result of this thinking is that we need to reduce the number of clicks it takes to get to checkout, or to that lead conversion form.
From a site-to-site point of view, as of 2016, the average page load is 5 seconds. But here's the deal folks, pages are a thing of the past. Conventional wisdom has it that If I've got a a checkout flow that's three pages deep, the absolute minimum amount of time it takes to get to that purchase is 15 seconds. But why do I need 3 pages of checkout flow? Why don't I have state changes instead of pages? The answer is, again, designers are still designing like it's 1999.
When we ask folks in user interviews how they think an application should work, they tell us. But it's important to remember they are telling us what-they-think, not how they actually prefer it; they tell us about their ideal interaction. Turns out, however, that the ideal state of things is not actually what they want. When processing the question they tell you what they think at that moment in absence of the actual real experience. Henry Ford is famous for saying, 'If I asked people what they wanted, they'd of told me faster horses'.
Following this logic, when people tell you they want less clicks, they are telling you they like the idea of less clicks. But really what they want is mental proximity.
Design for MENTAL proximity
I'm fond of asking people the question, 'How many clicks does it take to brush your teeth?' The point of the question is to lay bare the fact that humans don't think in clicks-- We evolved in a clickless world. This is something Amazon demonstrably understands as evidenced by some of their current innovations, like the Dash Button.
The Amazon Dash Button seems completely ridiculous on the surface to some. It's a button that does one thing, it reorders the product printed on the label. The quintessential example of the Dash Button is the Tide dash button. You place the button on your washer and dryer, and when you run out of laundry detergent, you press the button.
Upon first hearing of this, many of us thought this was a crazy stupid idea. 'I can already do that with my phone!' some said. 'Why do I need a dedicated button for something I can do on my phone with relative ease?!'.
If one analyzes the situation, they might reckon (and rightly so) that it would literally take more time to get up (from the couch, bed, etc.) and walk to the washer/dryer to press the button than it would to pull a phone out of their pocket and order more detergent through the web interface.
But, when I realize I need laundry detergent, I'm not in bed, on the couch, or anywhere else. I'm doing my laundry. The button is closer mentally and physically at the time of need than the same button represented in my phone.
What Do Your Users Need, and When Do They Need It?
Design Proximity is no longer about just physical proximity, it's about mental proximity. It's not measured in pixels from one button to another, but from one interaction to the next. It's not measured in clicks, but in the perceived nearness or proximity of that event to the next one in a chain of events.
When I ask how many clicks it takes to brush your teeth, it's easy to understand where physical proximity comes into play. I have my toothbrush, next to my toothpaste, next to the sink. I can successfully brush my teeth without having to run around looking for all-the-things.
But humans aren't solely teeth-brushing machines, we have other needs too. When I'm done brushing my teeth, there is a next event that almost always needs to happen: I need to pee. Thankfully, through who-knows-how-many-years, humankind has evolved a set of precedents that account for this mental proximity. My toothbrush and other aforementioned accoutrements all live in my bathroom, and my toilet is right there. We've got physical and mental proximity living together side by side.
So, whether you're a designer, developer, or designer/developer, we encourage you to think outside of static layouts and think about all that state you have to play with on the screen. Stop thinking about your sites and apps like they're real estate; trying to shove as much content into as small a space as possible. Remember there is no physical limit to your canvas, it's limited only by your powers of imagination. Unshackle yourself from the constraints of yesterday's technologies and open yourself up to the possibilities of today. Physical distance between elements is but one constraint, relying solely on these dimensions is like ignoring color and pretending the world is black and white; 2D instead of 3D. And don't forget what your user wants to do next.
The explosion of native mobile apps this decade put a spotlight on human centered design. Apple's iPhone and iOS were breakthroughs in part because of the way they used design to mimic humans and appeal to emotion. How good a design looks now plays second fiddle to the way it feels. New terms like 'microinteractions' and 'reactive animations' have been thrust into the designer's vernacular. It's a new era of design, the 'Experience Era.'
We're exploring microinteractions and reactive animations in our own products, looking for unique ways they could add real value for users and enhance the experience. It was with one of these explorations that our latest Playground Piece was born, Reactive Listener.
Most of the interactions on the web are causal. We click a button, a window loads. We push 'submit,' an email is sent. But what if we didn't want to be so binary. What if we want to humanize our website (on desktops) by subtly making our users aware of something before they've actually interacted with it. That's where Reactive Listener comes in.
Reactive Listener allows us to affect change over an element from a distance that otherwise would not be possible. This has all kinds of potential uses. Highlighting a clickable region of the page as one gets close to it, showing and hiding extra information as one navigates related content, and even simply subtle changes in position to make page elements feel as if they are 'alive' and reacting to you.
Our minds are exploding at the possibilities of these types of interactions, and we'd love to hear any ideas you have in the comments!
We've all been there - the project that just doesn't turn out like you hoped. You've gone over your work with the team repeatedly, and it just seems like nothing's really sticking. Maybe the design wasn't up to your standard, and you weren't sure why. Or there wasn't a lot of energy to launch the product. Or worst of all, precious time and energy was spent, and users just didn't care for it, dooming your product to stasis and death.
How did you react?
If you're like me, a flood of questions come to mind which can quickly turn into self doubt. You start to think, 'Why didn't I catch this earlier?' Or maybe you're more intuitive, and could FEEL that something was wrong all along, but didn't know what it was or what to do about it.
[Cue sleepless nights, binging on your favorite vice, and endless daydreams about finally opening that boutique coffee shop' and making millions.]
You might even have a great process. At ZURB, our's is highly iterative, involving quickly creating, showing and reacting. Maybe your process has some similarities. This is a great way to mitigate risk in the resource-intensive task of bringing a quality product to life. So how come projects can still go wrong?
The problem lies in how most of us started our design journey. In school, we're taught to care for every pixel, so as designers, we work on mastering great deliverables so our work is successful. But as you know if you've been in the profession for long enough, 80% of design is actually about communicating, discussing, and making decisions on ideas. When are we taught how to master communicating with the people who could kill our projects?
Asking the right questions in the right places
Luckily at ZURB, we get lots of practice. Every day, we have the privilege of designing world-class software with hundreds of companies, from venture-backed startups to multi-billion-dollar conglomerates, and we've discovered a few insights that help us communicate to build successful products.
Insight #1: Every project has different groups involved in them, and it's critical to understand who they are as early as possible.
Three common groups we've found in our project work are:
- Stakeholders - This is anyone who has some sway over the direction and momentum of the project. They might have an official title of influence, have some informal authority that makes others defer to them, or even be customers who have active investment in how the project turn out.
- Collaborators - This is anyone who has some skill that can add to a project's success. These could be formal collaborators placed on the team or others whose expertise you respect.
- Users - This is anyone who will end up using your product (who aren't always the same people as your customers, who primarily make purchasing decisions). This could be current or prospective.
Who are the groups of people involved in your project? By being aware of how the people involved in your project fit, you'll be able to understand who you have available to help you make good product decisions, and not miss out on talking to someone who's feedback might be critical.
Insight #2: Because of factors like convenience, power dynamics, and fear of failure, we tend to ask for feedback that these common project groups are specifically unequipped to give, dooming our design decisions with bias and inaccurate data.
- Stakeholder - We tend to think of how we can please those with power, and so we prioritize making decisions solely based on 'what they like', keeping us from making bolder design decisions based on data from real users
- Collaborator - since collaborators tend to be most accessible, we tend to go to them first to 'test our ideas'. Because we avoid conflict, we end up with a frankenstein product that incorporates their idiosyncratic and often contradictory advice on how our experiences 'should' be to 'make sense to them'
- User - IF we talk to users (and many teams don't), we tend to overly guide conversations so users will agree with our decisions and confirm our biases
How much does your communication mirror these behaviors? Getting the wrong feedback can cause you to inaccurately think users will think/behave like collaborators, stakeholders know what is good for the business all the time, and what users report is actually what they do.
Insight #3: Great designers have mastered HOW and WHEN to get the right feedback that makes products successful
- Stakeholder - since stakeholders have influence over the product's direction, momentum, and sometimes purchase, great designers leverage communication to achieve ALIGNMENT on the direction that best meets business and technical needs.
- Collaborator - since collaborators have relevant skills and knowledge to offer, great designers leverage communication to solve difficult problems that if not solved, can break the experience of the product
- User - since users are the ones with the need for the product and will be incorporating it into their lives, great designers leverage communication to validate the problems, ideas and usability of the product
If you could know something from each of your project groups right now based on how they're equipped, what would that be? By getting the right feedback (and avoiding the wrong kind), you can make thoughtful design decisions that solve major experiential issues, is in touch with real needs and desirability, and stay in a reality that your whole team is committed to building.
Get woke now
There's the old adage that you can't design in a vacuum. Stakeholders, collaborators, and users are common groups all integral to a project's success, and it's never too late in a project's timeline to reframe how we interact with each group to put our products on the best path for success. Stop appeasing stakeholders, blindly incorporating collaborator feedback, and putting words in users' mouths. Instead, start influencing stakeholders, problem-solving past stuckness with collaborators, and validating your designs with users to take your designs to the next level of success.
Two products hit the market. Feature wise, they're nearly identical and they are competing pretty closely on price as well. The difference, though, is that people love using one of them and want to pull their hair out every time they use the other. Why is the experience of using one so great and the other so awful? More often than not, it boils down to microinteractions.
Microinteractions are the magic little things that keep us coming back to the products we love. They're the satisfying little details that happen when we perform a single task. They humanize products and make them more enjoyable to use. How so? Well Nick Babich was able to sum it up in one word, acknowledgement. Humans have a very real need to feel acknowledged. We want our actions to be accepted and validated and need that reassurance. Other humans react to everything we do, so it feels more human when the things we interact with do it too. Just think about it, in a world without them we would be constantly frustrated and second guessing if our actions caused anything to happen.
As designers, microinteractions challenge us to think small. They force us to focus on the tiny moments that people engage with a digital or physical object, the moments in which people are provided with assurance and ease. But because they are so small, they are extremely easy to forget about, which would be a huge mistake.
Take your car key fob for example. Its function is to lock and unlock your car doors. Simple enough. But how do you really know that the doors lock when you push the button? Your car assures you that it understood your action and performed the task by beeping and flashing lights. If you're looking the other direction the honk can reassure you. If you're too far to hear it, the light assures you that your car is safely locked. Satisfying right?
Now imagine if you clicked the lock button and you did not hear a sound or see lights flash, would you trust that the doors locked? How would you know? Would you feel satisfied? Probably not. More than likely, you'd feel enough anxiety to walk back to the car and pull on the handle.
It's the same for your digital products, when people click something, type something, or interact with your product in any way, they need feedback from this microinteraction to assure them their work is saved, their image is uploading, or that the action they've took has been acknowledged. When the system registered what they intended and makes that known, it prevents anxiety. In other words, your product needs to learn ways to be a good listener.
The 4 Components of a Microinteraction
In his brilliant book, 'Microinteractions: Designing with Details,' Dan Saffer breaks down microinteractions into four components: The trigger, the rules, feedback, and loops/modes. Each of these components are critical to building a successful microinteraction.
The Trigger: This is the event that starts the microinteraction. Triggers can be broken up into two groups. Manual triggers happen when someone interacts with the product intentionally. These are things like the flip of a switch or push of a button. In many modern devices, it could even a clap or a wave of the hand. System triggers are automatic and occur when certain conditions are met. Your toaster beeping when your toast is done or the chime you hear when you receive a text message are system triggers.
The Rules: These are the parameters the microinteraction follows. What happens when you push the button? What can or cannot be done? The rules define exactly what happens after a trigger is performed. For example, with your car key fob, when you push the lock button, your car door locks.
Feedback: This is the verification of the microinteraction, the signal to the user that their action has been acknowledged. It can be a sound, a visual cue, vibration, movement or something else. For example, an iPhone vibrates when it is switched to silent mode.
Loops and Modes: A loop determines the length of the microinteraction. It determines whether the interaction repeats or if it changes over time. When you finish a load of laundry, your washing machine will play a sound and if you don't open the washer door, it will repeat to remind you. You want to be reminded that your wet clothes are finished so they don't sit there and get moldy. In this case it's important, but not every microinteraction needs to be repeated. Modes change the typical way things function and operate. Examples of this are changing a location in a weather app or setting a 'Do not disturb' mode on your phone.
To sum it up: The trigger initiates the feedback, the rules define what type of feedback occurs, and the loops and modes help define special cases where that feedback occurs or not.
Give me a sign!
Of all of these 4 components, by far, the most important one is feedback. But why?
It assures users that something is happening. The animation of swiping to delete an email is very useful. When you swipe, the email moves in the direction of your gesture. We've encountered examples without that animation and instead there is a popup window asking to confirm the deletion. The animation is much more related and contextual to your motion, where the popup doesn't give you continual feedback as you're interacting with the email and it feels very disconnected. Apple's Mail app does a great job of this:
It educates users on what's happening. When you're waiting for an image to upload, the loading indicator assures you that the system accepted your image and is processing it. Without that loading indicator, you're left to wonder if anything is happening and might try to keep clicking the upload button. Or if there is an error, feedback will help guide them to know something is actually wrong and help them figure out how to fix it.
It can delight users with something unexpected. A surprising detail doesn't always have to serve a purpose other than to entertain and delight. These details make using your product fun and exciting. It's always fun trying to find Yelp's hamster:
It can create memorable instances for your brand. Some microinteractions are so unique and memorable that they become synonymous with brands and even go on to influence how other products are builts. 'Pull to refresh' was an interaction invented by Loren Brichter for the Tweetie app which Twitter later acquired. The action is now forever linked to Twitter and can be seen in many other apps. Another example is Facebook's 'Like' interaction:
How can we take those opportunities for feedback to assure users, educate them, delight them, and create a memorable product brand?
Share Me Details
To successfully work microinteractions into your product, they can't be an afterthought. They aren't window dressing you include after you've built your product, they're critical components to layer in throughout the process. Think of microinteractions and the acknowledgement they provide as a sort of guiding principle throughout your design and development process. By actively looking for ways microinteractions can enhance your product early, you can shape your product around delivering an amazing experience for the user.
That being said, mockups and prototypes can never fully replicate what it's really like to use your product. It's extremely difficult to think of meaningful microinteractions when our product only exists on paper or in a wireframe. Use your live product, iterate on it, and be brutal and critical with how the experience feels. By using your actual product in real usecases, you'll uncover opportunities to enhance it with microinteractions you may have missed in prototype form.
Ultimately, remember that we're designing for people, and people want (and need) to feel acknowledged. Products that are full of well thought out, meaningful microinteractions are products people love to use. All of us crave that confirmation that what we're doing has been accepted, is valid, and is generating a result. In these small ways, you can help satisfy that very human need in your user.
The problems we've run into designing amazing products have inspired us to build powerful tools, frameworks and resources that have helped us design better and faster. We've made many of these resources freely accessible to the open source community, and it's been nothing short of awe inspiring to see how millions of designers and developers use them to create amazing sites, apps and emails.
From Frustration to Inspiration
We didn't want to use standard frameworks or libraries like jQuery, Angular, Backbone, etc because we knew that our customers would be using them too. A native solution would greatly decrease the chance of conflict or breaking their pages logic.
We scoured the net for an open source, native, @mention library and came up with nothing. So we rolled up our sleeves, put our heads down, and got to work. The result of which is Tribute, and we're incredibly proud of what we've created.
Check out our Playground Page to see how it works and give it a try!
According to recent research, 33% of people open emails based on the subject line alone and 68% decide to open based on the 'From' name. Most people spend hours of their time crafting the perfect content for their emails, neglecting these two important factors that can prevent all of that hard work from ever being seen. The truth is that people decide in seconds whether or not they will open that email you spent days working on. Subject lines, sender names and even preheader text (the preview of our email that gets displayed in our email client) all matter significantly. In general, short, clear and direct subject lines perform best for most industries. Vague, overly long, or boring subject lines kill open rates.
In some cases, a poorly chosen subject line or sender name can go beyond merely just being dull or ineffective and actually end up being rude, shocking or offensive. How so? Well, on mobile devices, subject lines and sender names are truncated. This can occasionally lead to some truly disastrous results. And mobile matters, a lot. More than half of emails are first opened on a mobile device. TL/DR: It is absolutely critical that your subject line reads well on all devices.
We're no stranger to emails here at ZURB. We've been spending a lot of time studying every facet of email and email delivery as we put the finishing touches on Foundation for Emails 2, a responsive framework for crafting HTML emails. This very framework was born out of our own needs ' we send thousands of emails every day. Foundation for Emails helps us speed up our process by drastically cutting down on development time and ensuring that our emails are fully responsive so they look great on any device.
But while we have a groundbreaking tool for developing amazing and beautiful emails, all of that hard work could be foiled by a subject line blunder. That got us thinking ... there had to be a way to quickly test out what our subject lines, sender names and preheader text looked like on the most popular mobile devices.
Sure, there are top notch paid services for testing and previewing emails on different devices, email clients and operating systems, and we are huge fans of them. But sometimes you need something quick and easy that you can test on while you're still crafting the content, without the need to go through the whole process of coding up the email.
Meet TestSubject, our latest Playground resource. TestSubject is a simple, free and easy to use tool to get a quick snapshot of what your email subject line, sender name and preheader text will look like on the most popular mobile devices. Simply copy and paste your content in and you'll get an instant preview. Avoid embarrassing gaffes and blunders, and make sure you've got a compelling message that gets people opening your message and reading your content. Using this tool will help you visualize how your subject line, sender name, and preheader text can better work together to get your email opened.
Visit the ZURB Playground and give a try!
New ZURB Master Class: Responsive Email
We've compiled all of our knowledge and insights on responsive HTML emails in a new online video course! Master responsive email by learning how to rapidly design and develop responsive emails that are on-message and display well on just about every screen, browser, and email client out there ' even Outlook.
Prototype to Production
Motion UI includes more than two dozen built-in transition and animation classes that make prototyping easy. When you move to a production environment, the library gives you total control over how your effects work.
The core of the library is a set of powerful transition and animation Sass mixins, which give you complete control over the details of an effect, from what direction an element slides, to how far it spins, to how intensely it shakes. Motion UI also includes a large number of pre-made CSS classes to help you get going quickly.
<div id="panel" data-animate="slideInRight" class="slow bounceIn"></div>
Motion is the New Flat
While previewing Foundation for Apps last year, we wrote about how 'motion is the new flat'. Animation allows us to design more expressive interfaces, by giving users queues around hierarchy, spatial orientation, and more. Foundation for Apps shipped with Motion UI, a Sass library that makes it easy to create CSS transitions and animations for your designs.
As we continue to develop the Foundation family, we're looking for ways to streamline the experience of using the three frameworks. This includes more consistent styling, naming, and architecture; revamping our CLI to build projects in any of the frameworks; and building standalone libraries that can be used by multiple frameworks.
Head on over to the ZURB Playground to see the library in action.
- Page 1 of 19
- Older Posts »