Tag Archives: current

Thumbnail

More Than Pixels: Selling Design Discovery




More Than Pixels: Selling Design Discovery

Kyle Cassidy



As designers, we know that research should play a pivotal role in any design process. Sadly, however, there are still a lot of organizations that do not see the value of research and would rather jump straight into the visual design stage of the design process.

The excuses given here tend to be:

“We already know what our customers want.”

“We don’t have the time/budget/people.”

“We’ll figure out the flaws in BETA.”

As designers, it is important that we are equipped to be able to have conversations with senior stakeholders to be able to sell and justify the importance of the so-called “Design Discovery” within the design process.

In this article, I’ll demystify what is meant by the term “Design Discovery” to help you better establish the importance of research within the creative process. I’ll also be giving advice on how to handle common pushbacks, along with providing various hints and tips on how to select the best research methods when undertaking user research.

My hope is that by reading this article, you will become comfortable with being able to sell “Design Discovery” as part of the creative process. You will know how to build a “Discovery Plan” of activities that answers all the questions you and your client need to initiate the design process with a clear purpose and direction.

Design With A Purpose

Digital design is not just about opening up Photoshop or Sketch and adding colors, shapes, textures, and animation to make a beautiful looking website or app.

As designers, before putting any pixels on canvas, we should have a solid understanding of:

  1. Who are the users we are designing for?
  2. What are the key tasks those users want to accomplish?

Ask yourself, is the purpose of what you are producing? Is it to help users:

  • Conduct research,
  • Find information,
  • Save time,
  • Track fitness,
  • Maintain a healthy lifestyle,
  • Feel safe,
  • Organize schedules,
  • Source goods,
  • Purchase products,
  • Gather ideas,
  • Manage finances,
  • Communicate,
  • Or something entirely different?

Understanding the answers to these questions should inform your design decisions. But before we design, we need to do some research.

Discovery Phase

Any design process worth its salt should start with a period of research, which (in agency terms) is often referred to as a “Discovery Phase”. The time and budget designers can allocate to a Discovery phase is determined by many factors such as the amount of the client’s existing project research and documentation as well as the client’s budget. Not to mention your own personal context, which we will come to later.

Business And User Goals

In a Discovery phase, we should ensure adequate time is dedicated to exploring both business and user goals.

Yes, we design experiences for users, but ultimately we produce our designs for clients (be that internal or external), too. Clients are the gatekeepers to what we design. They have the ultimate say over the project and they are the ones that hold the purse strings. Clients will have their own goals they want to achieve from a project and these do not always align with the users’ goals.

In order to ensure what we design throughout our design process hits the sweet spot, we need to make sure that we are spending time exploring both the business and user goals for the project (in the Research/Discovery phase).


business and user goals


Your Discovery phase should explore both user and business goals. (Large preview)

Uncovering Business Goals

Typically, the quickest way to establish the business goals for a project is to host a stakeholder workshop with key project stakeholders. Your aim should be to get as many representatives from across different business functions as possible into one room to discuss the vision for the project (Marketing, Finance, Digital, Customer Services, and Sales).

Tip: Large organizations often tend to operate in organizational silos. This allows teams to focus on their core function such as marketing, customer care, etc. It allows staff to be effective without being distracted by activities where they have no knowledge and little or no skills. However, it often becomes a problem when the teams don’t have a singular vision/mission from leadership, and they begin to see their area as the driving force behind the company’s success. Often in these situations, cross-departmental communication can be poor to non-existent. By bringing different members from across the organization together in one room, you get to the source of the truth quicker and can link together internal business processes and ways of working.

The core purpose of the stakeholder workshop should be:

  1. To uncover the Current State (explore what exists today in terms of people, processes, systems, and tools);
  2. To define the Desired Future State (understand where the client wants to get to, i.e. their understandig of what the ideal state should look like);
  3. To align all stakeholders on the Vision for the project.

project vision


Use workshops to align stakeholders around the vision and define the Desired Future State. (Large preview)

There are a series of activities that you can employ within your stakeholder workshop. I tend to typically build a full workshop day (7-8 hours) around 4-5 activities allowing 45mins uptil 1 hour for lunch and two 15-min coffee breaks between exercises. Any more that than, and I find energy levels start to dwindle.

I will vary the workshop activities I do around the nature of the project. However, each workshop I lead tends to include the following three core activities:

Activity Purpose
Business Model Canvas To explore the organizations business model and discuss where this project fits this model.
Measurement Plan Define what are the most important business metrics the business wants to be able to measure and report on.
Proto Personas and User Stories Explore who the business feels their users are and what are the key user stories we need to deliver against.

Tip: If you’re new to delivering client workshops, I’ve added a list of recommended reading to the references section at the bottom of this article which will give you useful ideas on workshop activities, materials, and group sizes.

Following the workshop, you’ll need to produce a write up of what happened in the workshop itself. It also helps to take lots of photos on the workshop day. The purpose of the write-up should be to not only explain the purpose of the day and key findings, but also recommendations of next steps. Write-ups can be especially helpful for internal communication within the organization and bringing non-attendees up to speed with what happened on the day as well as agreeing on the next steps for the project.

Uncovering User Goals

Of course, Discovery is not just about understanding what the organization wants. We need to validate what users actually want and need.

With the business goals defined, you can then move on to explore the user goals through conducting some user research. There are many different user research methods you can employ throughout the Discovery process from Customer Interviews and Heuristic Evaluations to Usability Tests and Competitor Reviews, and more.

Having a clear idea of the questions you are looking to answer and available budget is the key to helping select the right research methods. It is, for this reason, important that you have a good idea of what these are before you get to this point.

Before you start to select which are the best user research methods to employ, step back and ask yourself the following question:

“What are the questions I/we as a design team need answers to?”

For example, do you want to understand:

  • How many users are interacting with the current product?
  • How do users think your product compares to a competitor product?
  • What are the most common friction points within the current product?
  • How is the current product’s performance measured?
  • Do users struggle to find certain key pieces of information?

Grab a pen and write down what you want to achieve from your research in a list.

Tip: If you know you are going to be working on a fixed/tight budget, it is important to get confirmation on what that budget may look like at this point since this will have some bearing on the research methods you choose.

Another tip: User research does not have to happen after organizational research. I always find it helps to do some exploratory research prior to running stakeholder workshops. This ensures you go into the room with a baseline understanding of the organization its users and some common pain points. Some customers may not know what users do on their websites/apps nowadays; I like to go in prepared with some research to hand whether that be User Testing, Analytics Review or Tree Testing outputs.

Selecting Research Methods

The map below from the Nielsen Norman Group (NNG) shows an overview of 20 popular user research methods plotted on a 3-dimensional framework. It can provide a useful guide for helping you narrow down on a set of research methods to use.


top 20 research methods


A map of the top 20 research methods from NNG. (Large preview)

The diagram may look complicated, but let us break down some key terms.

Along the x-axis, research methods are separated by the types of data they produce.

  • Quantitative data involves numbers and figures. It is great for answering questions such as:

    • How much?
    • How many?
    • How long?
    • Impact tracking?
    • Benchmarking?
  • Qualitative data involves quote, observations, photos, videos, and notes.

    • What do users think?
    • How do users feel?
    • Why do users behave in a certain way?
    • What are users like?
    • What frustrates users?

Along the y-axis, research methods are separated by the user inputs.

  • Behavioral Data
    This data is based on what users do (outcomes).
  • Attitudinal Data
    This data is based on attitudes and opinions.

Finally, research methods are also classified by their context. Context explains the nature of the research, some research methods such as interviews require no product at all. Meanwhile, usability tests require users to complete scripted tasks and tell us how they think and feel.

Using the Model

Using your question list, firstly identify whether you are looking to understand users opinions (what people say) or actions (what people do) and secondly whether you are looking to understand why they behave in a certain way (why and how to fix) or how many of them are behaving in a certain way (how many and how much).

Now look at this simplified version of the matrix, and you should be able to work out which user research methods to focus in on.


selecting research methods


Think about what questions you’re trying to answer when selecting research methods. (Large preview)

Model Examples

Example 1

If you’re looking to understand users’ attitudes and beliefs and you don’t have a working product then ‘Focus Groups’ or ‘Interviews’ would be suitable user research methods.


top 20 research methods


Large preview

Example 2

If you want to understand how many users are interacting with the current website or app then an ‘Analytics Review’ would be the right research method to adopt. Meanwhile, if you want to test how many people will be impacted by a change, A/B testing would be a suitable method.


top 20 research methods


Large preview

No Silver Bullet

By now you should realize there is no shortcut to the research process; not one single UX research method will provide all the answers you need for a project.

Analytics reviews, for example, are a great low-cost way to explore behavioral, quantitative data about how users interact with an existing website or application.

However, this data falls short of telling you:

  • Why users visited the site/app in the first place (motivation);
  • What tasks they were looking to accomplish (intent);
  • If users were successful in completing their tasks (task completion);
  • How users found their overall experience (satisfaction).

These types of questions are best answered by other research methods such as ‘Customer Feedback’ surveys (also known as ‘Intercept Surveys’) which are available from tools such as Hotjar, Usabilla, and Qualaroo.


Usabilla


Usabilla’s quick feedback button allows users to provide instant feedback on their experience. (Large preview)

Costing Research/Discovery

In order to build a holistic view of the user experience, the Research/Discovery process should typically last around 3 to 4 weeks and combine a combination of the different research methods.

Use your list of questions and the NNG matrix to help you decide on the most suitable research methods for your project. Wherever possible, try to use complimentary research methods to build a bigger picture of users motivations, drivers, and behaviors.


four research methods


Your Design Discovery process should combine different types of data. (Large preview)

Tip: The UX Recipe tool is a great website for helping you pull together the different research methods you feel you need for a project and to calculate the cost of doing so.

Which brings me on to my next point.

Contexts And Budgets

The time and budget which you can allocate to Discovery will vary greatly depending on your role. Are you working in-house, freelance, or in an agency? Some typical scenarios are as follows:

  • Agency
    Clients employ agencies to build projects that generate the right results. To get the right results, you firstly need to ensure you understand both the business’ needs and the needs of the users as these are almost always not the same. Agencies almost always start with a detailed Discovery phase often led by the UX Design team. Budgets are generally included in the cost of the total project, as such ample time is available for research.
  • In-House: Large Company
    When working in a large company, you are likely to already have a suite of tools along with a program of activity you’re using to measure the customer experience. Secondly, you are likely to be working alongside colleagues with specialist skills such as Data Analysts, Market Researchers, and even a Content Team. Do not be afraid to say hello to these people and see if they will be willing to help you conduct some research. Customer service teams are also worth befriending. Customer service teams are the front line of a business where customer problems are aired for all to see. They can be a goldmine of useful information. Go spend some time with the team, listen to customer service calls, and review call/chat logs.
  • In-House: Smaller Company
    When working as part of an in-house team in a smaller company, you are likely to be working on a tight budget and are spread across a lot of activities. Nevertheless, with some creative thinking, you can still undertake some low-cost research tasks such as Site Intercept surveys, Analytics reviews, and Guerilla testing, or simply review applied research.
  • Freelance
    When working freelance, your client often seeks you out with a very fixed budget, timeline and set of deliverables in mind, i.e. “We need a new Logo” or “We need a landing page design.” Selling Discovery as part of the process can often be a challenge freelancers typically undertake since they mostly end up using their own time and even working overtime. But it doesn’t have to be like this. Clients can be willing to spend their time in the Discovery pre-project phase. However, you need to be confident to be able to sell yourself and defend your process. This video has some excellent tips on how to sell Discovery to clients as a freelancer.

Selling Design Discovery

As you can see from the above, selling Design Discovery can be a challenge depending on your context. It’s much harder to sell Design Discovery when working as a freelancer than it is working within an agency.

Some of the most commons excuses organizations put forward for discounting the research process are:

“We don’t have the budget.”

“We’ll find it out in BETA.”

“We don’t have time.”

“We already know what users want.”

When selling Design Discovery and combating these points of view, remember these key things:

It doesn’t have to be expensive.

Research does not have to be costly especially with all of the tools and resources we have available today. You can conduct a Guerilla User Testing session for the price of a basic coffee. Furthermore, you can often source willing participants from website intercepts, forums or social media groups who are more than willing to help.

It’s much harder to fix later.

The findings that come as an output from research can be invaluable. It is much more cost and time effective to spend some of the project budgets up front to ensure there are no assumptions and blind spots than it is to course correct later on if the project has shifted off tangent. Uncovering blockers or significant pain points later into the project can be a huge drain on time as well as monetary resources.

Organizational views can often be biased.

Within large organizations especially, a view of ‘what users want’ is often shaped by senior managers’ thoughts and opinions rather than any applied user research. These viewpoints then cascade down to more junior members of the team who start to adopt the same viewpoints. Validating these opinions are actually correct viewpoints is essential.

There are other cross-company benefits.

Furthermore, a Discovery process also brings with it internal benefits. By bringing members from other business functions together and setting a clear direction for the project, you should win advocates for the project across many business functions. Everyone should leave the room with a clear understanding of what the project is, its vision, and the problems you are trying to fix. This helps to alleviate an enormous amount of uncertainty within the organization.

I like to best explain the purpose of the discovery phase by using my adaptation of the Design Squiggle by Damien Newman:

See how the Discovery phase allows us time to tackle the most uncertainty?


Design Squiggle by Damien Newman


An adaptation of the Design Squiggle by Damien Newman showing how uncertainty is reduced in projects over time. (Large preview)

Waterfall And Agile

A Discovery phase can be integrated into both Waterfall and Agile project management methodologies.

In Waterfall projects, the Discovery phase happens at the very start of the project and can typically run for 4 to 12 weeks depending on the size of the project, the number of interdependent systems, and the areas which need to be explored.

In Agile projects, you may run a Discovery phase upfront to outline the purpose for the project and interconnect systems along with mini 1 to 2-week discovery process at the start of each sprint to gather the information you need to build out a feature.


waterfall and agile discovery


Discovery process can be easily incorporated into both waterfall and agile projects. (Large preview)

Final Thoughts

The next time you start on any digital project:

  • Make sure you allow time for a Discovery phase at the start of your project to define both business and user goals, and to set a clear vision that sets a clear purpose and direction for the project to all stakeholders.

  • Be sure to run a Stakeholder workshop with representatives from a variety of different business functions across the business (Marketing, Finance, Digital, Customer Services, Sales).

  • Before selecting which user research methods to use on your project, write down a list of questions you wish to understand and get a budget defined. From there, you can use the NNG matrix to help you understand what the best tool to use is.

Further Reading

If you found this article interesting, here is some recommended further reading:

Workshop Books

If you are interested in running Stakeholder workshops, I’d highly recommend reading the following books. Not only will they give you useful hints and tips on how to run workshops, they’re packed full of different workshop exercises to help you get answers to specific questions.

Smashing Editorial
(cc, ra, yk, il)


Link:  

More Than Pixels: Selling Design Discovery

Thumbnail

How To Improve Your Design Process With Data-Based Personas




How To Improve Your Design Process With Data-Based Personas

Tim Noetzel



Most design and product teams have some type of persona document. Theoretically, personas help us better understand our users and meet their needs. The idea is that codifying what we’ve learned about distinct groups of users helps us make better design decisions. Referring to these documents ourselves and sharing them with non-design team members and external stakeholders should ultimately lead to a user experience more closely aligned with what real users actually need.

In reality, personas rarely prove equal to these expectations. On many teams, persona documents sit abandoned on hard drives, collecting digital dust while designers continue to create products based primarily on whim and intuition.

In contrast, well-researched personas serve as a proxy for the user. They help us check our work and ensure that we’re building things users really need.

In fact, the best personas don’t just describe users; they actually help designers predict their behavior. In her article on persona creation, Laura Klein describes it perfectly:

“If you can create a predictive persona, it means you truly know not just what your users are like, but the exact factors that make it likely that a person will become and remain a happy customer.”

In other words, useful personas actually help design teams make better decisions because they can predict with some accuracy how users will respond to potential product changes.

Obviously, for personas to facilitate these types of predictions, they need to be based on more than intuition and anecdotes. They need to be data-driven.

So, what do data-driven personas look like, and how do you make one?

Start With What You Think You Know

The first step in creating data-driven personas is similar to the typical persona creation process. Write down your team’s hypotheses about what the key user groups are and what’s important to each group.

If your team is like most, some members will disagree with others about which groups are important, the particular makeup and qualities of each persona, and so on. This type of disagreement is healthy, but unlike the usual persona creation process you may be used to, you’re not going to get bogged down here.

Instead of debating the merits of each persona (and the various facets and permutations thereof), the important thing is to be specific about the different hypotheses you and your team have and write them down. You’re going to validate these hypotheses later, so it’s okay if your team disagrees at this stage. You may choose to focus on a few particular personas, but make sure to keep a backlog of other ideas as well.

Hypothetical Personas


First, start by recording all the hypotheses you have about key personas. You’ll refine these through user research in the next step. (Large preview)

I recommend aiming for a short, 1–2 sentence description of each hypothetical persona that details who they are, what root problem they hope to solve by using your product, and any other pertinent details.

You can use the traditional user stories framework for this. If you were creating hypothetical personas for Craigslist, one of these statements might read:

“As a recent college grad, I want to find cheap furniture so I can furnish my new apartment.”

Another might say:

“As a homeowner with an extra bedroom, I want to find a responsible tenant to rent this space to so I can earn some extra income.”

If you have existing data — things like user feedback emails, NPS scores, user interview notes, or analytics data — be sure to go over them and include relevant data points in your notes along with your user stories.

Validate And Refine

The next step is to validate and refine these hypotheses with user interviews. For each of your hypothetical personas, you’ll want to start by interviewing 5 to 10 people who fit that group.

You have three key goals for these interviews. For each group, you need to:

  1. Understand the context in which they need to solve the problem.
  2. Confirm that members of the persona group agree that the problem you recorded is an urgent and painful one that they struggle to solve now.
  3. Identify key predictors of whether a member of this persona is likely to become and remain an active user.

The approach you take to these interviews may vary, but I recommend a hybrid approach between a traditional user interview, which is very non-leading, and a Lean Problem interview, which is deliberately leading.

Start with the traditional user interview approach and ask behavior-based, non-leading questions. In the Craigslist example, we might ask the recent college grad something like:

“Tell me about the last time you purchased furniture. What did you buy? Where did you buy it?”

These types of questions are great for establishing whether the interviewee recently experienced the problem in question, how they solved it, and whether they’re dissatisfied with their current solution.

Once you’ve finished asking these types of questions, move on to the Lean Problem portion of the interview. In this section, you want to tell a story about a time when you experienced the problem — establishing the various issues you struggled with and why it was frustrating — and see how they respond.

You might say something like this:

“When I graduated college, I had to get new furniture because I wasn’t living in the dorm anymore. I spent forever looking at furniture stores, but they were all either ridiculously expensive or big-box stores with super-cheap furniture I knew would break in a few weeks. I really wanted to find good furniture at a reasonable price, but I couldn’t find anything and I eventually just bought the cheap stuff. It inevitably broke, and I had to spend even more money, which I couldn’t really afford. Does any of that resonate with you?”

What you’re looking for here is emphatic agreement. If your interviewee says “yes, that resonates” but doesn’t get much more excited than they were during the rest of the interview, the problem probably wasn’t that painful for them.

Data-Driven Personas Interview Format


You can validate or invalidate your persona hypotheses with a series of quick, 30-minute interviews. (Large preview)

On the other hand, if they get excited, empathize with your story, or give their own anecdote about the problem, you know you’ve found a problem they really care about and need to be solved.

Finally, make sure to ask any demographic questions you didn’t cover earlier, especially those around key attributes you think might be significant predictors of whether somebody will become and remain a user. For example, you might think that recent college grads who get high-paying jobs aren’t likely to become users because they can afford to buy furniture at retail; if so, be sure to ask about income.

You’re looking for predictable patterns. If you bring in 5 members of your persona and 4 of them have the problem you’re trying to solve and desperately want a solution, you’ve probably identified a key persona.

On the other hand, if you’re getting inconsistent results, you likely need to refine your hypothetical persona and repeat this process, using what you learn in your interviews to form new hypotheses to test. If you can’t consistently find users who have the problem you want to solve, it’s going to be nearly impossible to get millions of them to use your product. So don’t skimp on this step.

Create Your Personas

The penultimate step in this process is creating the actual personas themselves. This is where things get interesting. Unlike traditional personas, which are typically static, your data-driven personas will be living, breathing documents.

The goal here is to combine the lessons you learned in the previous step — about who the user is and what they need — with data that shows how well the latest iteration of your product is serving their needs.

At my company Swish, each one of our personas includes two sections with the following data:

Predictive User Data Product Performance Data
Description of the user including predictive demographics. The percentage of our current user base the persona represents.
Quotes from at least 3 actual users that describe the jobs-to-be-done. Latest activation, retention, and referral rates for the persona.
The percentage of the potential user base the persona represents. Current NPS Score for the persona.

If you’re looking for more ideas for data to include, check out Coryndon Luxmoore’s presentation on how his team created data-driven personas at Buildium.

It may take some time for your team to produce all this information, but it’s okay to start with what you have and improve the personas over time. Your personas won’t be sitting on a shelf. Every time you release a new feature or change an existing one, you should measure the results and update your personas accordingly.

Integrate Your Personas Into Your Workflow

Now that you’ve created your personas, it’s time to actually use them in your day-to-day design process. Here are 4 opportunities to use your new data-driven personas:

  1. At Standups
    At Swish, our standups are a bit different. We start these meetings by reviewing the activation, retention, and referral metrics for each persona. This ensures that — as we discuss yesterday’s progress and today’s obstacles — we remain focused on what really matters: how well we’re serving our users.
  2. During Prioritization
    Your data-driven personas are a great way to keep team members honest as you discuss new features and changes. When you know how much of your user base the persona represents and how well you’re serving them, it quickly becomes obvious whether a potential feature could actually make a difference. Suddenly deciding what to work on won’t require hours of debate or horse-trading.
  3. At Design Reviews
    Your data-driven personas are a great way to keep team members honest as you discuss new designs. When team members can creditably represent users with actual quotes from user interviews, their feedback quickly becomes less subjective and more useful.
  4. When Onboarding New Team Members
    New hires inevitably bring a host of implicit biases and assumptions about the user with them when they start. By including your data-driven personas in their onboarding documents, you can get new team members up to speed much more quickly and ensure they understand the hard-earned lessons your team learned along the way.

Keeping Your Personas Up To Date

It’s vitally important to keep your personas up-to-date so your team members can continue to rely on them to guide their design thinking.

As your product improves, it’s simple to update NPS scores and performance data. I recommend doing this monthly at a minimum; if you’re working on an early-stage, rapidly-changing product, you’ll get better mileage by updating these stats weekly instead.

It’s also important to check in with members of your personas periodically to make sure your predictive data stays relevant. As your product evolves and the competitive landscape changes, your users’ views about their problems will change as well. If your growth starts to plateau, another round of interviews may help to unlock insights you didn’t find the first time. Even if everything is going well, try to check in with members of your personas — both current users of your product and some non-users — every 6 to 12 months.

Wrapping Up

Building data-driven personas is a challenging project that takes time and dedication. You won’t uncover the insights you need or build the conviction necessary to unify your team with a week-long throwaway project.

But if you put in the time and effort necessary, the results will speak for themselves. Having the type of clarity that data-driven personas provide makes it far easier to iterate quickly, improve your user experience, and build a product your users love.

Further Reading

If you’re interested in learning more, I highly recommend checking out the linked articles above, as well as the following resources:

Smashing Editorial
(rb, ra, yk, il)


Original source: 

How To Improve Your Design Process With Data-Based Personas

Building A Static Site With Components Using Nunjucks

It’s quite popular these days, and dare I say a damn fine idea, to build sites with components. Rather than building out entire pages one by one, we build a system of components (think: a search form, an article card, a menu, a footer) and then piece together the site with those components.

JavaScript frameworks like React and Vue emphasize this idea heavily. But even if you don’t use any client-side JavaScript at all to build a site, it doesn’t mean you have to give up on the idea of building with components! By using an HTML preprocessor, we can build a static site and still get all the benefits of abstracting our site and its content into re-usable components.

Static sites are all the rage these days, and rightfully so, as they are fast, secure, and inexpensive to host. Even Smashing Magazine is a static site, believe it or not!

Let’s take a walk through a site I built recently using this technique. I used CodePen Projects to build it, which offers Nunjucks as a preprocessor, which was perfectly up for the job.

This is a microsite. It doesn’t need a full-blown CMS to handle hundreds of pages. It doesn’t need JavaScript to handle interactivity. But it does need a handful of pages that all share the same layout.


Consistent header and footer


Consistent header and footer across all pages

HTML alone doesn’t have a good solution for this. What we need are imports. Languages like PHP make this simple with things like <?php include "header.php"; ?>, but static file hosts don’t run PHP (on purpose) and HTML alone is no help. Fortunately, we can preprocess includes with Nunjucks.


Importing components into pages


Importing components is possible in languages like PHP

It makes perfect sense here to create a layout, including chunks of HTML representing the header, navigation, and footer. Nunjucks templating has the concept of blocks, which allow us to slot in content into that spot when we use the layout.

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>The Power of Serverless</title>
  <link rel="stylesheet" href="/styles/style.processed.css">
</head>
  
<body>
  
  % include "./template-parts/_header.njk" %
  
  % include "./template-parts/_nav.njk" %
  
  % block content %
  % endblock %
  
  % include "./template-parts/_footer.njk" %
  
</body>

Notice the files that are included are named like _file.njk. That’s not entirely necessary. It could be header.html or icons.svg, but they are named like this because 1) files that start with underscores are a bit of-of a standard way of saying they are a partial. In CodePen Projects, it means they won’t try to be compiled alone. 2) By naming it .njk, we could use more Nunjucks stuff in there if we want to.

None of these bits have anything special in them at all. They are just little bits of HTML intended to be used on each of our four pages.

<footer>
  <p>Just a no-surprises footer, people. Nothing to see here.<p>
</footer>

Done this way, we can make one change and have the change reflected on all four pages.

Using The Layout For The Four Pages

Now each of our four pages can be a file. Let’s just start with index.njk though, which in CodePen Projects, will automatically be processed and create an index.html file every time you save.


The index.njk file


Starting off with an index.njk file

Here’s what we could put in index.njk to use the layout and drop some content in that block:

% extends "_layout.njk" %

% block content %
<h1>Hello, World!</h1>
% endblock % 

That will buy us a fully functional home page! Nice! Each of the four pages can do the same exact thing, but putting different content in the block, and we have ourselves a little four-page site that is easy to manage.


Compiled index.html


The index.njk file gets compiled into index.html

For the record, I’m not sure I’d call these little chunks we re-using components. We’re just being efficient and breaking up a layout into chunks. I think of a component more like a re-usable chunk that accepts data and outputs a unique version of itself with that data. We’ll get to that.

Making Active Navigation

Now that we’ve repeated an identical chunk of HTML on four pages, is it possible to apply unique CSS to individual navigation items to identify the current page? We could with JavaScript and looking at window.location and such, but we can do this without JavaScript. The trick is putting a class on the <body> unique to each page and using that in the CSS.

In our _layout.njk we have the body output a class name as a variable:

<body class=" body_class }">

Then before we call that layout on an indivdiual page, we set that variable:

% set body_class = "home" %
% extends "_layout.njk" %

Let’s say our navigation was structured like

<nav class="site-nav">
  <ul>
    <li class="nav-home">
      <a href="/">
        Home
      </a>
      ...

Now we can target that link and apply special styling as needed by doing:

body.home .nav-home a,
body.services .nav-services a  /* continue matching classes for all pages... */
  /* unique active state styling */

Active state styling on navigation
Styling navigation links with an active class.

Oh and those icons? Those are just individual .svg files I put in a folder and included like

% include "../icons/cloud.svg" %

And that allows me to style them like:

svg 
  fill: white;

Assuming the SVG elements inside have no fill attributes already on them.

Authoring Content In Markdown

The homepage of my microsite has a big chunk of content on it. I could certainly write and maintain that in HTML itself, but sometimes it’s nice to leave that type of thing to Markdown. Markdown feels cleaner to write and perhaps a bit easier to look at when it’s lots of copy.

This is very easy in CodePen Projects. I made a file that ends in .md, which will automatically be processed into HTML, then included that in the index.njk file.

Markdown compiled into HTML on CodePen Projects
Files in markdown get compiled into HTML on CodePen Projects.
% block content %
<main class="centered-text-column"> 
% include "content/about.html" % 
</main>
% endblock %

Building Actual Components

Let’s consider components to be repeatable modules that as passed in data to create themselves. In frameworks like Vue, you’d be working with single file components that are isolated bits of templated HTML, scoped CSS, and component-specific JavaScript. That’s super cool, but our microsite doesn’t need anything that fancy.

We need to create some “cards” based on a simple template, so we can build things like this:


Card style components


Creating repeatable components with templates

Building a repeatable component like that in Nunjucks involves using what they call Macros. Macros are deliciously simple. They are like as if HTML had functions!

% macro card(title, content) %
<div class="card">
  <h2> title }</h2>
  <p> content }</p>
</div>
% endmacro %

Then you call it as needed:

 card('My Module', 'Lorem ipsum whatever.') }

The whole idea here is to separate data and markup. This gives us some pretty clear, and tangible benefits:

  1. If we need to make a change to the HTML, we can change it in the macro and it gets changed everywhere that uses that macro.
  2. The data isn’t tangled up in markup
  3. The data could come from anywhere! We code the data right into calls to the macros as we’ve done above. Or we could reference some JSON data and loop over it. I’m sure you could even imagine a setup in which that JSON data comes from a sort of headless CMS, build process, serverless function, cron job, or whatever.

Now we have these repeatable cards that combine data and markup, just what we need:


Data and markup for the component is kept separate


HTML is controlled in the macro, while data can come from anywhere

Make As Many Components As You Like

You can take this idea and run with it. For example, imagine how Bootstrap is essentially a bunch of CSS that you follow HTML patterns in which to use. You could make each of those patterns a macro and call them as needed, essentially componentizing the framework.

You can nest components if you like, embracing a sort of atomic design philosophy. Nunjucks offers logic as well, meaning you can create conditional components and variations just by passing in different data.

In the simple site I made, I made a different macro for the ideas section of the site because it involved slightly different data and a slightly different card design.


Card components in Ideas section


It’s possible to create as many components as you want

A Quick Case Against Static Sites

I might argue that most sites benefit from a component-based architecture, but only some sites are appropriate for being static. I work on plenty of sites in which having back-end languages is appropriate and useful.

One of my sites, CSS-Tricks, has things like a user login with a somewhat complex permissions system: forums, comments, eCommerce. While none of those things totally halt the idea of working staticly, I’m often glad I have a database and back-end languages to work with. It helps me build what I need and keeps things under one roof.

Go Forth And Embrace The Static Life!

Remember that one of the benefits of building in the way we did in this article is that the end result is just a bunch of static files. Easy to host, fast, and secure. Yet, we didn’t have to give up working in a developer-friendly way. This site will be easy to update and add to in the future.

  • The final project is a microsite called The Power of Serverless for Front-End Developers (https://thepowerofserverless.info/).
  • Static file hosting, if you ask me, is a part of the serverless movement.
  • You can see all the code (and even fork a copy for yourself) right on CodePen. It is built, maintained, and hosted entirely on CodePen using CodePen Projects.
  • CodePen Projects handles all the Nunjucks stuff we talked about here, and also things like Sass processing and image hosting, which I took advantage of for the site. You could replicate the same with, say, a Gulp or Grunt-based build process locally. Here’s a boilerplate project like that you could spin up.
Smashing Editorial
(ms, ra, hj, il)

Jump to original: 

Building A Static Site With Components Using Nunjucks

Styling Empty Cells With Generated Content And CSS Grid Layout

A common Grid Layout gotcha is when a newcomer to the layout method wonders how to style a grid cell which doesn’t contain any content. In the current Level 1 specification, this isn’t possible since there is no way to target an empty Grid Cell or Grid Area and apply styling. This means that to apply styling, you need to insert an element.
In this article, I am going to take a look at how to use CSS Generated Content to achieve styling of empty cells without adding redundant empty elements and show some use cases where this technique makes sense.

Source:

Styling Empty Cells With Generated Content And CSS Grid Layout

Thumbnail

Designing A Perfect Responsive Configurator

Here’s a little challenge for you. How would you design a responsive interface for a custom car configurator? The customer should be able to adjust colors, wheels, exterior details, interior details and perhaps accessories — on small and large screens. Doesn’t sound that difficult, does it? In fact, we have all seen such interfaces before. Essentially, they are just a combination of some navigation, iconography, buttons, accordions and a real-time 3D preview.

View this article:

Designing A Perfect Responsive Configurator

Air Lookout Is The Side Project That Changed My Design Process Forever

In February of 2015, I began working on an iOS app called Air Lookout. The goal of the app was to simplify and remove any obfuscation of air quality information. After over a year of working nights and weekends, the total net income since it launched in 2016 has been less than $1,000. Even with those numbers, I would relive every hour of work.
The one thing that I can’t place a monetary value on is how the experience of creating Air Lookout has completely changed my mind on the process of design and development for every project I have worked on since.

Link to article – 

Air Lookout Is The Side Project That Changed My Design Process Forever

6 Really Bad Website Popup Examples

If you want to craft a delightful marketing experience and you’re using popups, you need to make sure you hold them to the same high standards as the content they are covering up. You can learn a lot by looking at bad website popup examples.

Once you understand what not to do, you’ll default to starting your own popup designs from a better baseline.

What does a bad popup design actually look like?

Well, it depends on your judging criteria, and for the popup examples below, I was considering these seven things, among others:

  1. Clarity: Is it easy to figure out the offer really quickly?
  2. Relevance: Is it related to the content of the current page?
  3. Manipulation: Does it use psychological trickery in the copy?
  4. Design: Is it butt ugly?
  5. Control: Is it clear what all options will do?
  6. Escape: Can you get rid of it easily?
  7. Value: Is the reward worth more than the perceived (or actual) effort?

The following popup examples, each make a number of critical errors in their design decisions. Take a look, and share your own worst popup design examples in the comments!


#1 – Weather Channel Rudeness

What’s so bad about it?

Okay, I get it Weather.com, ads are one of, or your only, revenue stream. There are plenty of sites who ask you to turn off an ad blocker to read the full article. I don’t have a problem with it, and the main paragraph of text here is okay.

What I *do* have a problem with is the copy on the CTA. “Turn off your ad blocker”.

Really? You can’t even say please? That’s just obnoxious.

Fun fact, the Canadian version of the site doesn’t have this popup. Go figure. ;)
(I had to VPN to get the U.S. version.)

Submitted by Ramona from Impact)


#2 – Mashable Shmashable

What’s so bad about it?

If you peer into the background behind the popup, you’ll see a news story headline that begins with “Nightmare Alert”. I think that’s a pretty accurate description of what’s happening here.

  • Design: Bad. The first thing I saw looks like a big mistake. The Green line with the button hanging off the bottom looks like the designer fell asleep with their head on the mouse.
  • Clarity: Bad. And what on earth does the headline mean? click.click.click. Upon deeper exploration, it’s the name of the newsletter, but that’s not apparent at all on first load.
  • Clarity: worse. Then we get the classic “Clear vs. Clever” headline treatment. Why are you talking about the pronunciation of the word “Gif”? Tell me what this is, and why I should care to give you my email.
  • Design: Bad. Also, that background is gnarly.

#3 – KAM Motorsports Revolution!

What’s so bad about it?

It’s motorsports. It’s not a revolution. Unless they’re talking about wheels going round in circles.

  • Clarity: Bad. The headline doesn’t say what it is, or what I’ll get by subscribing. I have to read the fine print to figure that out.
  • Copy: Bad. Just reading the phrase “abuse your email” is a big turn off. Just like the word spam, I wasn’t thinking that you were going to abuse me, but now it’s on my mind.
  • Relevance: Bad. Newsletter subscription popups are great, they have a strong sense of utility and can give people exactly what they want. But I don’t like them as entry popups. They’re much better when they use an exit trigger, or a scroll trigger. Using a “Scroll Up” trigger is smart because it means they’ve read some of your content, and they are scrolling back up vs. leaving directly, which is another micro-signal that they are interested.

#4 – Utterly Confused


(Source unknown – I found it on confirmshaming.tumblr.com)

What’s so bad about it?

I have no earthly clue what’s going on here.

  • Clarity: Bad. I had to re-read it five times before I figured out what was going on.
  • Control: Bad. After reading it, I didn’t know whether I would be agreeing with what they’re going to give me, or with the statement. It’s like an affirmation or something. But I have no way of knowing what will happen if I click either button. My best guess after spending this much time writing about it is that it’s a poll. But a really meaningless one if it is. Click here to find out how many people agreed with “doing better”…
  • It ends with “Do Better”. I agree. They need to do a lot better.

#5 – Purple Nurple

What’s so bad about it?

  • Manipulation: Bad. Our first “Confirm Shaming” example. Otherwise known as “Good Cop / Bad Cop”. Forcing people to click a button that says “Detest” on it is so incongruent with the concept of a mattress company that I think they’re just being cheap. There’s no need to speak to people that way.
  • I found a second popup example by Purple (below), and have to give them credit. The copy on this one is significantly more persuasive. Get this. If you look at the section I circled (in purple), it says that if you subscribe, they’ll keep you up to date with SHIPPING TIMES!!! Seriously? If you’re going to email me and say “Hey Oli, great news! We can ship you a mattress in 2 weeks!”, I’ll go to Leesa, or Endy, or one of a million other Casper copycats.


#6 – Hello BC

What’s so bad about it?

Context: This is an entry popup, and I have never been to this site before.

  • Relevance: Bad. The site is Hellobc.com, the title says “Supernatural British Columbia”, and the content on the page is about skydiving. So what list is this for? And nobody wants to be on a “list”, stop saying “list”. It’s like saying email blast. Blast your list. If you read the first sentence it gets even more confusing, as you’ll be receiving updates from Destination BC. That’s 4 different concepts at play here.
  • Design: Bad. It’s legitimately butt ugly. I mean, come on. This is for Beautiful Supernatural British Columbia ffs. It’s stunning here. Show some scenery to entice me in.
  • Value: Bad. Seeing that form when I arrive on the page is like a giant eff you. Why do they think it’s okay to ask for that much info, with that much text, before I’ve even seen any content?
  • Control: Bad. And there’s not any error handling. However, the submit button remains inactive until you magically click the right amount of options to trigger it’s hungry hungry hippo mouth to open.

Train. Wreck.


Well, that’s all for today, folks. You might be wondering why there were so few popup examples in this post. Honestly, when the team was rallying to find me a bunch of examples, we all struggled to find many truly awful ones. We also struggled to find many really awesome ones.

This is where YOU come in!

Send me your terrible and awesome popup examples!

If you have any wonderfully brutal, or brutally wonderful examples of website popup design, I’d really appreciate a URL in the comments. If you could share the trigger details too that would be rad (e.g. exit, entrance, scroll, delay etc.).

Tomorrow’s Post is about Awesome Popup Examples! YAY.

So get your butt back here same time tomorrow, where I’ll be sharing my brand new Popup Delight Equation that you can use to grade your own popup designs.

Cheers,
Oli

p.s. Don’t forget to subscribe to the weekly updates.

View original post here:  

6 Really Bad Website Popup Examples

Technology isn’t the Problem, We Are. An Essay on Popups + 5 Horrific Popup Examples

Before I bring the heat, I want to talk a bit about what it’s like, as a marketer, to be marketing something that’s difficult to market.

You see, there’s a common problem that many marketers face, and it’s also one of the most asked questions I hear when I’m on the road, as a speaker:

“How do I great marketing for a boring product or service?”

That’s a tough challenge for sure, although the good news is that if you can inject some originality you’ll be a clear winner, as all of your competitors are also boring. However, I think I can one-up that problem:

“How do I do great marketing for something that’s universally hated, like popups?”

We knew we had a big challenge ahead of us when we decided to release the popups product because of the long legacy of manipulative abuse it carries with it.

In fact, as the discussion about product direction began in the office, there were some visceral (negative) reactions from some folks on the engineering team. They feared that we were switching over to the dark side.

It makes sense to me that this sentiment would come from developers. In my experience, really good software developers have one thing in common. They want to make a difference in the world. Developers are makers by design, and part of building something is wanting it to have a positive impact on those who use it.

To quell those types of fears requires a few things;

  • Education about the positive use cases for the technology,
  • Evidence in the form of good popup examples, showcasing how to use them in a delightful and responsible manner,
  • Features such as advanced triggers & targeting to empower marketers to deliver greater relevance to visitors,
  • And most important of all – it requires us to take a stance. We can’t change the past unless we lead by example.

It’s been my goal since we started down this path, to make it clear that we are drawing a line in the sand between the negative past, and a positive future.

Which is why we initially launched with the name “Overlays” instead of popups.

Overlays vs. Popups – The End of an Era

It made a lot of sense at the time, from a branding perspective. Through podcast interviews and public speaking gigs, I was trying to change the narrative around popups. Whenever I was talking about a bad experience, I would call it a popup. When it was a positive (and additive) experience, I’d call it an overlay. It was a really good way to create a clear separation.

I even started to notice more and more people calling them overlays. Progress.

Unfortunately, it would still require a lot of continued education to make a dent in the global perception of the terminology, that with the search volume for “overlays” being tiny compared to popups, factored heavily into our decision to pivot back to calling a popup a popup.

Positioning is part of a product marketer’s job – our VP of Product Marketing, Ryan Engley recently completed our most recent positioning document for the new products. Just as the umbrella term “Convertables” we had been using to include popups and sticky bars had created confusion, “Overlays” was again making the job harder than it should have been. You can tell, just from reading this paragraph alone that it’s a complex problem, and we’re moving in the right direction by re-simplifying.

The biggest challenge developing our positioning was the number of important strategic questions that we needed to answer first. The market problems we solve, for who, how our product fits today with our vision for the future, who we see ourselves competing with, whether we position ourselves as a comprehensive platform that solves a unique problem, or whether we go to market with individual products and tools etc. It’s a beast of an undertaking.

My biggest lightbulb moment was working with April Dunford who pushed me to get away from competing tool-to-tool with other products. She said in order to win that way, you’d have to be market leading in every tool, and that won’t happen. So what’s the unique value that only you offer and why is it important?

— Ryan Engley, VP Product Marketing at Unbounce

You can read more about our initial product adoption woes, and how our naming conventions hurt us, in the first post in the series – Product Marketing Month: Why I’m Writing 30 Blog Posts in 30 Days.

Let’s get back to the subject of popups. I think it’s important to look back at the history of this device to better understand how they came about, and why they have always caused such a stir.

Browser Interaction Models & the History of the Popup

The talk I was doing much of last year was called Data-Driven Design. As part of the talk, I get into interaction design trends. I’ve included the “Trendline” slide below.

You can see that the first occurrence of a popup was back in 1998. Also, note that I included Overlays in late 2016 when we first started that discussion.

Like many bad trends, popups began as web developers started trying to hack browser behavior to create different interruptive interaction modes. I know I made a lot of them back in the day, but I was always doing it to try to create a cool experience. For example, I was building a company Intranet and wanted to open up content in a new window, resize it, and stick it to the side of the screen as a sidebar navigation for the main window. That was all good stuff.

Tabbed browsers have done a lot to help clean up the mess of multiple windows, and if you couple that with popup blockers, there’s a clear evolution in how this type of behavior is being dealt with.

Then came the pop-under, often connected to Malware virus schemes where malicious scripts could be running in the background and you wouldn’t even know.

And then the always fun “Are you sure you want to do that?” Inception-like looping exit dialogs.

Developers/hackers took the simple Javascript modal “Ok” “Cancel” and abused it to the point where there was no real way out of the page. If you tried to leave the page one modal would lead to another, and another, and you couldn’t actually close the browser window/tab unless you could do it within the split second between one dialog closing and the next opening. It was awful.

So we have a legacy of abuse that’s killed the perception of popups.

What if Popups Had Been Built Into Browsers?

Imagine for a moment that a popup was simply one of many available interaction models available in the browsing experience. They could have had a specification from the W3C, with a set of acceptable criteria for display modes. It would be an entirely different experience. Sure, there would still be abuse, but it’s an interesting thought.

This is why it’s important that we (Unbounce and other like-minded marketers and Martech software providers) take a stance, and build the right functionality into this type of tool so that it can be used responsibly.

Furthermore, we need to keep the dialog going, to educate the current and future generations of marketers that to be original, be delightful, be a business that represents themselves as professionals, means taking responsibility for our actions and doing everything we can to take the high road in our marketing.

Alright, before I get to the really bad website popup examples, I’ll leave you with this thought:

Technology is NOT the problem, We Are.

It’s the disrespectful and irresponsible marketers who use manipulative pop-psychology tactics for the sake of a few more leads, who are the problem. We need to stop blaming popups for bad experiences, and instead, call out the malicious marketers who are ruining it for those trying to do good work.

It’s a tough challenge to reverse years of negative perception, but that’s okay. It’s okay because we know the value the product brings to our customers, how much extra success they’re having, and because we’ve built a solution that can be configured in precise ways that make it simple to use in a responsible manner (if you’re a good person).


Follow our Product Marketing Month journey >> click here to launch a popup with a subscribe form (it uses our on-click trigger feature).


5 Really Bad Website Popup Examples

What does a bad popup actually look like? Well, it depends on your judging criteria, and for the examples below, I was considering these seven things, among others:

  1. Clarity: Is it easy to figure out the offer really quickly?
  2. Relevance: Is it related to the content of the current page?
  3. Manipulation: Does it use psychological trickery in the copy?
  4. Design: Is it butt ugly?
  5. Control: Is it clear what all options will do?
  6. Escape: Can you get rid of it easily?
  7. Value: Is the reward worth more than the perceived (or actual) effort?

#1 – Mashable Shmashable

What’s so bad about it?

If you peer into the background behind the popup, you’ll see a news story headline that begins with “Nightmare Alert”. I think that’s a pretty accurate description of what’s happening here.

  • Design: Bad. The first thing I saw looks like a big mistake. The Green line with the button hanging off the bottom looks like the designer fell asleep with their head on the mouse.
  • Clarity: Bad. And what on earth does the headline mean? click.click.click. Upon deeper exploration, it’s the name of the newsletter, but that’s not apparent at all on first load.
  • Clarity: worse. Then we get the classic “Clear vs. Clever” headline treatment. Why are you talking about the pronunciation of the word “Gif”? Tell me what this is, and why I should care to give you my email.
  • Design: Bad. Also, that background is gnarly.

#2 – KAM Motorsports Revolution!

What’s so bad about it?

It’s motorsports. It’s not a revolution. Unless they’re talking about wheels going round in circles.

  • Clarity: Bad. The headline doesn’t say what it is, or what I’ll get by subscribing. I have to read the fine print to figure that out.
  • Copy: Bad. Just reading the phrase “abuse your email” is a big turn off. Just like the word spam, I wasn’t thinking that you were going to abuse me, but now it’s on my mind.
  • Relevance: Bad. Newsletter subscription popups are great, they have a strong sense of utility and can give people exactly what they want. But I don’t like them as entry popups. They’re much better when they use an exit trigger, or a scroll trigger. Using a “Scroll Up” trigger is smart because it means they’ve read some of your content, and they are scrolling back up vs. leaving directly, which is another micro-signal that they are interested.

#3 – Utterly Confused


(Source unknown – I found it on confirmshaming.tumblr.com)

What’s so bad about it?

I have no earthly clue what’s going on here.

  • Clarity: Bad. I had to re-read it five times before I figured out what was going on.
  • Control: Bad. After reading it, I didn’t know whether I would be agreeing with what they’re going to give me, or with the statement. It’s like an affirmation or something. But I have no way of knowing what will happen if I click either button. My best guess after spending this much time writing about it is that it’s a poll. But a really meaningless one if it is. Click here to find out how many people agreed with “doing better”…
  • It ends with “Do Better”. I agree. They need to do a lot better.

#4 – Purple Nurple

What’s so bad about it?

  • Manipulation: Bad. Our first “Confirm Shaming” example. Otherwise known as “Good Cop / Bad Cop”. Forcing people to click a button that says “Detest” on it is so incongruent with the concept of a mattress company that I think they’re just being cheap. There’s no need to speak to people that way.
  • I found a second popup example by Purple (below), and have to give them credit. The copy on this one is significantly more persuasive. Get this. If you look at the section I circled (in purple), it says that if you subscribe, they’ll keep you up to date with SHIPPING TIMES!!! Seriously? If you’re going to email me and say “Hey Oli, great news! We can ship you a mattress in 2 weeks!”, I’ll go to Leesa, or Endy, or one of a million other Casper copycats.


#5 – Hello BC

What’s so bad about it?

Context: This is an entry popup, and I have never been to this site before.

  • Relevance: Bad. The site is Hellobc.com, the title says “Supernatural British Columbia”, and the content on the page is about skydiving. So what list is this for? And nobody wants to be on a “list”, stop saying “list”. It’s like saying email blast. Blast your list. If you read the first sentence it gets even more confusing, as you’ll be receiving updates from Destination BC. That’s 4 different concepts at play here.
  • Design: Bad. It’s legitimately butt ugly. I mean, come on. This is for Beautiful Supernatural British Columbia ffs. It’s stunning here. Show some scenery to entice me in.
  • Value: Bad. Seeing that form when I arrive on the page is like a giant eff you. Why do they think it’s okay to ask for that much info, with that much text.
  • Control: Bad. And there’s not any error handling. However, the submit button remains inactive until you magically click the right amount of options to trigger it’s hungry hungry hippo mouth to open.

Trainwreck.


Well, that’s all for today, folks. You might be wondering why there were so few popup examples in this post, keep reading and I’ll explain why.

Coming Up Tomorrow – Good Popups, YAY!!!

One of the most interesting things I’ve noticed of late is that there is a shift in quality happening in the popup world. When the team rallied to find the bad popup examples above, we found at least 10x as many good ones as bad. That’s something to feel pretty good about. Perhaps the positive energy we’re helping to spread is having an impact.

So get your butt back here tomorrow to see 20+ delightful website popup examples. More importantly, I’ll also be sharing “The Delight Equation”, my latest formula for measuring quantifying how good your popups really are.

See you then!

Cheers
Oli

p.s. Don’t forget to subscribe to the weekly updates.

Continue reading:

Technology isn’t the Problem, We Are. An Essay on Popups + 5 Horrific Popup Examples

Technology isn’t the Problem, We Are. An Essay on Popups.

Today I want to talk a bit about what it’s like, as a marketer, to be marketing something that’s difficult to market.
Stop blaming the popups for what bad marketers do.
You see, there’s a common problem that many marketers face, and it’s also one of the most asked questions I hear when I’m on the road, as a speaker:

“How do I great marketing for a boring product or service?”

That’s a tough challenge for sure, although the good news is that if you can inject some originality you’ll be a clear winner, as all of your competitors are also boring. However, I think I can one-up that problem:

“How do I do great marketing for something that’s universally hated, like popups?”

We knew we had a big challenge ahead of us when we decided to release the popups product because of the long legacy of manipulative abuse it carries with it.

In fact, as the discussion about product direction began in the office, there were some visceral (negative) reactions from some folks on the engineering team. They feared that we were switching over to the dark side.

It makes sense to me that this sentiment would come from developers. In my experience, really good software developers have one thing in common. They want to make a difference in the world. Developers are makers by design, and part of building something is wanting it to have a positive impact on those who use it.

To quell those types of fears requires a few things;

  • Education about the positive use cases for the technology,
  • Evidence in the form of good popup examples, showcasing how to use them in a delightful and responsible manner,
  • Features such as advanced triggers & targeting to empower marketers to deliver greater relevance to visitors,
  • And most important of all – it requires us to take a stance. We can’t change the past unless we lead by example.

It’s been my goal since we started down this path, to make it clear that we are drawing a line in the sand between the negative past, and a positive future.

Which is why we initially launched with the name “Overlays” instead of popups.

Overlays vs. Popups – The End of an Era

It made a lot of sense at the time, from a branding perspective. Through podcast interviews and public speaking gigs, I was trying to change the narrative around popups. Whenever I was talking about a bad experience, I would call it a popup. When it was a positive (and additive) experience, I’d call it an overlay. It was a really good way to create a clear separation.

I even started to notice more and more people calling them overlays. Progress.

Unfortunately, it would still require a lot of continued education to make a dent in the global perception of the terminology, that with the search volume for “overlays” being tiny compared to popups, factored heavily into our decision to pivot back to calling a popup a popup.

Positioning is part of a product marketer’s job – our VP of Product Marketing, Ryan Engley recently completed our most recent positioning document for the new products. Just as the umbrella term “Convertables” we had been using to include popups and sticky bars had created confusion, “Overlays” was again making the job harder than it should have been. You can tell, just from reading this paragraph alone that it’s a complex problem, and we’re moving in the right direction by re-simplifying.

The biggest challenge developing our positioning was the number of important strategic questions that we needed to answer first. The market problems we solve, for who, how our product fits today with our vision for the future, who we see ourselves competing with, whether we position ourselves as a comprehensive platform that solves a unique problem, or whether we go to market with individual products and tools etc. It’s a beast of an undertaking.

My biggest lightbulb moment was working with April Dunford who pushed me to get away from competing tool-to-tool with other products. She said in order to win that way, you’d have to be market leading in every tool, and that won’t happen. So what’s the unique value that only you offer and why is it important?

— Ryan Engley, VP Product Marketing at Unbounce

You can read more about our initial product adoption woes, and how our naming conventions hurt us, in the first post in the series – Product Marketing Month: Why I’m Writing 30 Blog Posts in 30 Days.

Let’s get back to the subject of popups. I think it’s important to look back at the history of this device to better understand how they came about, and why they have always caused such a stir.

Browser Interaction Models & the History of the Popup

The talk I was doing much of last year was called Data-Driven Design. As part of the talk, I get into interaction design trends. I’ve included the “Trendline” slide below.

You can see that the first occurrence of a popup was back in 1998. Also, note that I included Overlays in late 2016 when we first started that discussion.

Like many bad trends, popups began as web developers started trying to hack browser behavior to create different interruptive interaction modes. I know I made a lot of them back in the day, but I was always doing it to try to create a cool experience. For example, I was building a company Intranet and wanted to open up content in a new window, resize it, and stick it to the side of the screen as a sidebar navigation for the main window. That was all good stuff.

Tabbed browsers have done a lot to help clean up the mess of multiple windows, and if you couple that with popup blockers, there’s a clear evolution in how this type of behavior is being dealt with.

Then came the pop-under, often connected to Malware virus schemes where malicious scripts could be running in the background and you wouldn’t even know.

And then the always fun “Are you sure you want to do that?” Inception-like looping exit dialogs.

Developers/hackers took the simple Javascript modal “Ok” “Cancel” and abused it to the point where there was no real way out of the page. If you tried to leave the page one modal would lead to another, and another, and you couldn’t actually close the browser window/tab unless you could do it within the split second between one dialog closing and the next opening. It was awful.

So we have a legacy of abuse that’s killed the perception of popups.

What if Popups Had Been Built Into Browsers?

Imagine for a moment that a popup was simply one of many available interaction models available in the browsing experience. They could have had a specification from the W3C, with a set of acceptable criteria for display modes. It would be an entirely different experience. Sure, there would still be abuse, but it’s an interesting thought.

This is why it’s important that we (Unbounce and other like-minded marketers and Martech software providers) take a stance, and build the right functionality into this type of tool so that it can be used responsibly.

Furthermore, we need to keep the dialog going, to educate the current and future generations of marketers that to be original, be delightful, be a business that represents themselves as professionals, means taking responsibility for our actions and doing everything we can to take the high road in our marketing.

I’ll leave you with this thought:

Technology is NOT the problem, We Are.

It’s the disrespectful and irresponsible marketers who use manipulative pop-psychology tactics for the sake of a few more leads, who are the problem. We need to stop blaming popups for bad experiences, and instead, call out the malicious marketers who are ruining it for those trying to do good work.

It’s a tough challenge to reverse years of negative perception, but that’s okay. It’s okay because we know the value the product brings to our customers, how much extra success they’re having, and because we’ve built a solution that can be configured in precise ways that make it simple to use in a responsible manner (if you’re a good person).


Get your butt back here tomorrow to see 20+ delightful website popup examples. More importantly, I’ll also be sharing “The Delight Equation”, my latest formula for measuring quantifying how good your popups really are.

See you then!

Cheers
Oli

p.s. Don’t forget to subscribe to the weekly updates.

Continue reading: 

Technology isn’t the Problem, We Are. An Essay on Popups.

The Rise Of The State Machines

It’s 2018 already, and countless front-end developers are still leading a battle against complexity and immobility. Month after month, they’ve searched for the holy grail: a bug-free application architecture that will help them deliver quickly and with high quality. I am one of those developers, and I’ve found something interesting that might help.
We have taken a good step forward with tools such as React and Redux. However, they’re not enough on their own in large-scale applications.

View the original here – 

The Rise Of The State Machines