Continuous Integration

January 20, 2015Desenvolvimentodeploy, desenvolvimento, integração contínuaFernando Madeira

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.

01 May 2006

Martin Fowler

Translations: Portuguese

For more information on this, and related topics, take a look at my guide page for delivery.

ThoughtWorks, my employer, offers consulting and support around Continuous Integration. The open source CruiseControl, the first continuous integration server, was originally created at ThoughtWorks. Recently ThoughtWorks Studios, our products group, has releasedGo – a new server for continuous integration and delivery. It supports parallel, deployment pipelines with multiple projects, a snazzy looking dashboard, and support for automated deployments. It’s a commercial tool, but is free to use for small setups.

I vividly remember one of my first sightings of a large software project. I was taking a summer internship at a large English electronics company. My manager, part of the QA group, gave me a tour of a site and we entered a huge depressing warehouse stacked full with cubes. I was told that this project had been in development for a couple of years and was currently integrating, and had been integrating for several months. My guide told me that nobody really knew how long it would take to finish integrating. From this I learned a common story of software projects: integration is a long and unpredictable process.

But this needn’t be the way. Most projects done by my colleagues at ThoughtWorks, and by many others around the world, treat integration as a non-event. Any individual developer’s work is only a few hours away from a shared project state and can be integrated back into that state in minutes. Any integration errors are found rapidly and can be fixed rapidly.

This contrast isn’t the result of an expensive and complex tool. The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository.

When I’ve described this practice to people, I commonly find two reactions: “it can’t work (here)” and “doing it won’t make much difference”. What people find out as they try it is that it’s much easier than it sounds, and that it makes a huge difference to development. Thus the third common reaction is “yes we do that – how could you live without it?”

The term ‘Continuous Integration’ originated with the Extreme Programming development process, as one of its original twelve practices. When I started at ThoughtWorks, as a consultant, I encouraged the project I was working with to use the technique. Matthew Foemmel turned my vague exhortations into solid action and we saw the project go from rare and complex integrations to the non-event I described. Matthew and I wrote up our experience in the original version of this paper, which has been one of the most popular papers on my site.

Although Continuous Integration is a practice that requires no particular tooling to deploy, we’ve found that it is useful to use a Continuous Integration server. The best known such server is CruiseControl, an open source tool originally built by several people at ThoughtWorks and now maintained by a wide community. Since then several other CI servers have appeared, both open source and commercial – including Cruise from ThoughtWorks Studios.

Building a Feature with Continuous Integration

The easiest way for me to explain what CI is and how it works is to show a quick example of how it works with the development of a small feature. Let’s assume I have to do something to a piece of software, it doesn’t really matter what the task is, for the moment I’ll assume it’s small and can be done in a few hours. (We’ll explore longer tasks, and other issues later on.)

I begin by taking a copy of the current integrated source onto my local development machine. I do this by using a source code management system by checking out a working copy from the mainline.

The above paragraph will make sense to people who use source code control systems, but be gibberish to those who don’t. So let me quickly explain that for the latter. A source code control system keeps all of a project’s source code in a repository. The current state of the system is usually referred to as the ‘mainline’. At any time a developer can make a controlled copy of the mainline onto their own machine, this is called ‘checking out’. The copy on the developer’s machine is called a ‘working copy’. (Most of the time you actually update your working copy to the mainline – in practice it’s the same thing.)

Now I take my working copy and do whatever I need to do to complete my task. This will consist of both altering the production code, and also adding or changing automated tests. Continuous Integration assumes a high degree of tests which are automated into the software: a facility I call self-testing code. Often these use a version of the popular XUnit testing frameworks.

Once I’m done (and usually at various points when I’m working) I carry out an automated build on my development machine. This takes the source code in my working copy, compiles and links it into an executable, and runs the automated tests. Only if it all builds and tests without errors is the overall build considered to be good.

With a good build, I can then think about committing my changes into the repository. The twist, of course, is that other people may, and usually have, made changes to the mainline before I get chance to commit. So first I update my working copy with their changes and rebuild. If their changes clash with my changes, it will manifest as a failure either in the compilation or in the tests. In this case it’s my responsibility to fix this and repeat until I can build a working copy that is properly synchronized with the mainline.

Once I have made my own build of a properly synchronized working copy I can then finally commit my changes into the mainline, which then updates the repository.

However my commit doesn’t finish my work. At this point we build again, but this time on an integration machine based on the mainline code. Only when this build succeeds can we say that my changes are done. There is always a chance that I missed something on my machine and the repository wasn’t properly updated. Only when my committed changes build successfully on the integration is my job done. This integration build can be executed manually by me, or done automatically by Cruise.

If a clash occurs between two developers, it is usually caught when the second developer to commit builds their updated working copy. If not the integration build should fail. Either way the error is detected rapidly. At this point the most important task is to fix it, and get the build working properly again. In a Continuous Integration environment you should never have a failed integration build stay failed for long. A good team should have many correct builds a day. Bad builds do occur from time to time, but should be quickly fixed.

The result of doing this is that there is a stable piece of software that works properly and contains few bugs. Everybody develops off that shared stable base and never gets so far away from that base that it takes very long to integrate back with it. Less time is spent trying to find bugs because they show up quickly.

Practices of Continuous Integration

The story above is the overview of CI and how it works in daily life. Getting all this to work smoothly is obviously rather more than that. I’ll focus now on the key practices that make up effective CI.

Maintain a Single Source Repository.

Software projects involve lots of files that need to be orchestrated together to build a product. Keeping track of all of these is a major effort, particularly when there’s multiple people involved. So it’s not surprising that over the years software development teams have built tools to manage all this. These tools – called Source Code Management tools, configuration management, version control systems, repositories, or various other names – are an integral part of most development projects. The sad and surprising thing is that they aren’t part of all projects. It is rare, but I do run into projects that don’t use such a system and use some messy combination of local and shared drives.

So as a simple basis make sure you get a decent source code management system. Cost isn’t an issue as good quality open-source tools are available. The current open source repository of choice is Subversion. (The older open-source tool CVS is still widely used, and is much better than nothing, but Subversion is the modern choice.) Interestingly as I talk to developers I know most commercial source code management tools are liked less than Subversion. The only tool I’ve consistently heard people say is worth paying for isPerforce.

Once you get a source code management system, make sure it is the well known place for everyone to go get source code. Nobody should ever ask “where is the foo-whiffle file?” Everything should be in the repository.

Although many teams use repositories a common mistake I see is that they don’t put everything in the repository. If people use one they’ll put code in there, but everything you need to do a build should be in there including: test scripts, properties files, database schema, install scripts, and third party libraries. I’ve known projects that check their compilers into the repository (important in the early days of flaky C++ compilers). The basic rule of thumb is that you should be able to walk up to the project with a virgin machine, do a checkout, and be able to fully build the system. Only a minimal amount of things should be on the virgin machine – usually things that are large, complicated to install, and stable. An operating system, Java development environment, or base database system are typical examples.

You must put everything required for a build in the source control system, however you may also put other stuff that people generally work with in there too. IDE configurations are good to put in there because that way it’s easy for people to share the same IDE setups.

One of the features of version control systems is that they allow you to create multiple branches, to handle different streams of development. This is a useful, nay essential, feature – but it’s frequently overused and gets people into trouble. Keep your use of branches to a minimum. In particular have a mainline: a single branch of the project currently under development. Pretty much everyone should work off this mainline most of the time. (Reasonable branches are bug fixes of prior production releases and temporary experiments.)

In general you should store in source control everything you need to build anything, but nothing that you actually build. Some people do keep the build products in source control, but I consider that to be a smell – an indication of a deeper problem, usually an inability to reliably recreate builds.

Automate the Build

Getting the sources turned into a running system can often be a complicated process involving compilation, moving files around, loading schemas into the databases, and so on. However like most tasks in this part of software development it can be automated – and as a result should be automated. Asking people to type in strange commands or clicking through dialog boxes is a waste of time and a breeding ground for mistakes.

Automated environments for builds are a common feature of systems. The Unix world has had make for decades, the Java community developed Ant, the .NET community has had Nant and now has MSBuild. Make sure you can build and launch your system using these scripts using a single command.

A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment. I’ll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.

Build scripts come in various flavors and are often particular to a platform or community, but they don’t have to be. Although most of our Java projects use Ant, some have used Ruby (the Ruby Rake system is a very nice build script tool). We got a lot of value from automating an early Microsoft COM project with Ant.

A big build often takes time, you don’t want to do all of these steps if you’ve only made a small change. So a good build tool analyzes what needs to be changed as part of the process. The common way to do this is to check the dates of the source and object files and only compile if the source date is later. Dependencies then get tricky: if one object file changes those that depend on it may also need to be rebuilt. Compilers may handle this kind of thing, or they may not.

Depending on what you need, you may need different kinds of things to be built. You can build a system with or without test code, or with different sets of tests. Some components can be built stand-alone. A build script should allow you to build alternative targets for different cases.

Many of us use IDEs, and most IDEs have some kind of build management process within them. However these files are always proprietary to the IDE and often fragile. Furthermore they need the IDE to work. It’s okay for IDE users set up their own project files and use them for individual development. However it’s essential to have a master build that is usable on a server and runnable from other scripts. So on a Java project we’re okay with having developers build in their IDE, but the master build uses Ant to ensure it can be run on the development server.

Make Your Build Self-Testing

Traditionally a build means compiling, linking, and all the additional stuff required to get a program to execute. A program may run, but that doesn’t mean it does the right thing. Modern statically typed languages can catch many bugs, but far more slip through that net.

A good way to catch bugs more quickly and efficiently is to include automated tests in the build process. Testing isn’t perfect, of course, but it can catch a lot of bugs – enough to be useful. In particular the rise of Extreme Programming (XP) and Test Driven Development (TDD) have done a great deal to popularize self-testing code and as a result many people have seen the value of the technique.

Regular readers of my work will know that I’m a big fan of both TDD and XP, however I want to stress that neither of these approaches are necessary to gain the benefits of self-testing code. Both of these approaches make a point of writing tests before you write the code that makes them pass – in this mode the tests are as much about exploring the design of the system as they are about bug catching. This is a Good Thing, but it’s not necessary for the purposes of Continuous Integration, where we have the weaker requirement of self-testing code. (Although TDD is my preferred way of producing self-testing code.)

For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs. The tests need to be able to be kicked off from a simple command and to be self-checking. The result of running the test suite should indicate if any tests failed. For a build to be self-testing the failure of a test should cause the build to fail.

Over the last few years the rise of TDD has popularized the XUnit family of open-source tools which are ideal for this kind of testing. XUnit tools have proved very valuable to us at ThoughtWorks and I always suggest to people that they use them. These tools, pioneered by Kent Beck, make it very easy for you to set up a fully self-testing environment.

XUnit tools are certainly the starting point for making your code self-testing. You should also look out for other tools that focus on more end-to-end testing, there’s quite a range of these out there at the moment including FIT, Selenium, Sahi, Watir, FITnesse, and plenty of others that I’m not trying to comprehensively list here.

Of course you can’t count on tests to find everything. As it’s often been said: tests don’t prove the absence of bugs. However perfection isn’t the only point at which you get payback for a self-testing build. Imperfect tests, run frequently, are much better than perfect tests that are never written at all.

Everyone Commits To the Mainline Every Day

Integration is primarily about communication. Integration allows developers to tell other developers about the changes they have made. Frequent communication allows people to know quickly as changes develop.

The one prerequisite for a developer committing to the mainline is that they can correctly build their code. This, of course, includes passing the build tests. As with any commit cycle the developer first updates their working copy to match the mainline, resolves any conflicts with the mainline, then builds on their local machine. If the build passes, then they are free to commit to the mainline.

By doing this frequently, developers quickly find out if there’s a conflict between two developers. The key to fixing problems quickly is finding them quickly. With developers committing every few hours a conflict can be detected within a few hours of it occurring, at that point not much has happened and it’s easy to resolve. Conflicts that stay undetected for weeks can be very hard to resolve.

The fact that you build when you update your working copy means that you detect compilation conflicts as well as textual conflicts. Since the build is self-testing, you also detect conflicts in the running of the code. The latter conflicts are particularly awkward bugs to find if they sit for a long time undetected in the code. Since there’s only a few hours of changes between commits, there’s only so many places where the problem could be hiding. Furthermore since not much has changed you can use diff-debugging to help you find the bug.

My general rule of thumb is that every developer should commit to the repository every day. In practice it’s often useful if developers commit more frequently than that. The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts.

Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress. Often people initially feel they can’t do something meaningful in just a few hours, but we’ve found that mentoring and practice helps them learn.

Every Commit Should Build the Mainline on an Integration Machine

Using daily commits, a team gets frequent tested builds. This ought to mean that the mainline stays in a healthy state. In practice, however, things still do go wrong. One reason is discipline, people not doing an update and build before they commit. Another is environmental differences between developers’ machines.

As a result you should ensure that regular builds happen on an integration machine and only if this integration build succeeds should the commit be considered to be done. Since the developer who commits is responsible for this, that developer needs to monitor the mainline build so they can fix it if it breaks. A corollary of this is that you shouldn’t go home until the mainline build has passed with any commits you’ve added late in the day.

There are two main ways I’ve seen to ensure this: using a manual build or a continuous integration server.

The manual build approach is the simplest one to describe. Essentially it’s a similar thing to the local build that a developer does before the commit into the repository. The developer goes to the integration machine, checks out the head of the mainline (which now houses his last commit) and kicks off the integration build. He keeps an eye on its progress, and if the build succeeds he’s done with his commit. (Also see Jim Shore’sdescription.)

A continuous integration server acts as a monitor to the repository. Every time a commit against the repository finishes the server automatically checks out the sources onto the integration machine, initiates a build, and notifies the committer of the result of the build. The committer isn’t done until she gets the notification – usually an email.

At ThoughtWorks, we’re big fans of continuous integration servers – indeed we led the original development of CruiseControl and CruiseControl.NET, the widely used open-source CI servers. Since then we’ve also built the commercial Cruise CI server. We use a CI server on nearly every project we do and have been very happy with the results.

Not everyone prefers to use a CI server. Jim Shore gave a well argued description of why he prefers the manual approach. I agree with him that CI is much more than just installing some software. All the practices here need to be in play to do Continuous Integration effectively. But equally many teams who do CI well find a CI server to be a helpful tool.

Many organizations do regular builds on a timed schedule, such as every night. This is not the same thing as a continuous build and isn’t enough for continuous integration. The whole point of continuous integration is to find problems as soon as you can. Nightly builds mean that bugs lie undetected for a whole day before anyone discovers them. Once they are in the system that long, it takes a long time to find and remove them.

Fix Broken Builds Immediately

A key part of doing a continuous build is that if the mainline build fails, it needs to be fixed right away. The whole point of working with CI is that you’re always developing on a known stable base. It’s not a bad thing for the mainline build to break, although if it’s happening all the time it suggests people aren’t being careful enough about updating and building locally before a commit. When the mainline build does break, however, it’s important that it gets fixed fast.

A phrase I remember Kent Beck using was “nobody has a higher priority task than fixing the build”. This doesn’t mean that everyone on the team has to stop what they are doing in order to fix the build, usually it only needs a couple of people to get things working again. It does mean a conscious prioritization of a build fix as an urgent, high priority task.

Often the fastest way to fix the build is to revert the latest commit from the mainline, taking the system back to the last-known good build. Certainly the team should not try to do any debugging on a broken mainline. Unless the cause for the breakage is immediately obvious, just revert the mainline and debug the problem on a development workstation.

To help avoid breaking the mainline at all you might consider using a pending head.

When teams are introducing CI, often this is one of the hardest things to sort out. Early on a team can struggle to get into the regular habit of working mainline builds, particularly if they are working on an existing code base. Patience and steady application does seem to regularly do the trick, so don’t get discouraged.

Keep the Build Fast

The whole point of Continuous Integration is to provide rapid feedback. Nothing sucks the blood of a CI activity more than a build that takes a long time. Here I must admit a certain crotchety old guy amusement at what’s considered to be a long build. Most of my colleagues consider a build that takes an hour to be totally unreasonable. I remember teams dreaming that they could get it so fast – and occasionally we still run into cases where it’s very hard to get builds to that speed.

For most projects, however, the XP guideline of a ten minute build is perfectly within reason. Most of our modern projects achieve this. It’s worth putting in concentrated effort to make it happen, because every minute you reduce off the build time is a minute saved for each developer every time they commit. Since CI demands frequent commits, this adds up to a lot of time.

If you’re staring at a one hour build time, then getting to a faster build may seem like a daunting prospect. It can even be daunting to work on a new project and think about how to keep things fast. For enterprise applications, at least, we’ve found the usual bottleneck is testing – particularly tests that involve external services such as a database.

Probably the most crucial step is to start working on setting up a deployment pipeline. The idea behind a deployment pipeline (also known as build pipeline or staged build) is that there are in fact multiple builds done in sequence. The commit to the mainline triggers the first build – what I call the commit build. The commit build is the build that’s needed when someone commits to the mainline. The commit build is the one that has to be done quickly, as a result it will take a number of shortcuts that will reduce the ability to detect bugs. The trick is to balance the needs of bug finding and speed so that a good commit build is stable enough for other people to work on.

Once the commit build is good then other people can work on the code with confidence. However there are further, slower, tests that you can start to do. Additional machines can run further testing routines on the build that take longer to do.

A simple example of this is a two stage deployment pipeline. The first stage would do the compilation and run tests that are more localized unit tests with the database completely stubbed out. Such tests can run very fast, keeping within the ten minute guideline. However any bugs that involve larger scale interactions, particularly those involving the real database, won’t be found. The second stage build runs a different suite of tests that do hit the real database and involve more end-to-end behavior. This suite might take a couple of hours to run.

In this scenario people use the first stage as the commit build and use this as their main CI cycle. The second-stage build runs when it can, picking up the executable from the latest good commit build for further testing. If this secondary build fails, then this may not have the same ‘stop everything’ quality, but the team does aim to fix such bugs as rapidly as possible, while keeping the commit build running. As in this example, later builds are often pure tests since these days it’s usually tests that cause the slowness.

If the secondary build detects a bug, that’s a sign that the commit build could do with another test. As much as possible you want to ensure that any later-stage failure leads to new tests in the commit build that would have caught the bug, so the bug stays fixed in the commit build. This way the commit tests are strengthened whenever something gets past them. There are cases where there’s no way to build a fast-running test that exposes the bug, so you may decide to only test for that condition in the secondary build. Most of time, fortunately, you can add suitable tests to the commit build.

This example is of a two-stage pipeline, but the basic principle can be extended to any number of later stages. The builds after the commit build can also be done in parallel, so if you have two hours of secondary tests you can improve responsiveness by having two machines that run half the tests each. By using parallel secondary builds like this you can introduce all sorts of further automated testing, including performance testing, into the regular build process.

Test in a Clone of the Production Environment

The point of testing is to flush out, under controlled conditions, any problem that the system will have in production. A significant part of this is the environment within which the production system will run. If you test in a different environment, every difference results in a risk that what happens under test won’t happen in production.

As a result you want to set up your test environment to be as exact a mimic of your production environment as possible. Use the same database software, with the same versions, use the same version of operating system. Put all the appropriate libraries that are in the production environment into the test environment, even if the system doesn’t actually use them. Use the same IP addresses and ports, run it on the same hardware.

Well, in reality there are limits. If you’re writing desktop software it’s not practicable to test in a clone of every possible desktop with all the third party software that different people are running. Similarly some production environments may be prohibitively expensive to duplicate (although I’ve often come across false economies by not duplicating moderately expensive environments). Despite these limits your goal should still be to duplicate the production environment as much as you can, and to understand the risks you are accepting for every difference between test and production.

If you have a pretty simple setup without many awkward communications, you may be able to run your commit build in a mimicked environment. Often, however, you need to use test doubles because systems respond slowly or intermittently. As a result it’s common to have a very artificial environment for the commit tests for speed, and use a production clone for secondary testing.

I’ve noticed a growing interest in using virtualization to make it easy to put together test environments. Virtualized machines can be saved with all the necessary elements baked into the virtualization. It’s then relatively straightforward to install the latest build and run tests. Furthermore this can allow you to run multiple tests on one machine, or simulate multiple machines in a network on a single machine. As the performance penalty of virtualization decreases, this option makes more and more sense.

Make it Easy for Anyone to Get the Latest Executable

One of the most difficult parts of software development is making sure that you build the right software. We’ve found that it’s very hard to specify what you want in advance and be correct; people find it much easier to see something that’s not quite right and say how it needs to be changed. Agile development processes explicitly expect and take advantage of this part of human behavior.

To help make this work, anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.

Doing this is pretty straightforward: make sure there’s a well known place where people can find the latest executable. It may be useful to put several executables in such a store. For the very latest you should put the latest executable to pass the commit tests – such an executable should be pretty stable providing the commit suite is reasonably strong.

If you are following a process with well defined iterations, it’s usually wise to also put the end of iteration builds there too. Demonstrations, in particular, need software whose features are familiar, so then it’s usually worth sacrificing the very latest for something that the demonstrator knows how to operate.

Everyone can see what’s happening

Continuous Integration is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it.

One of the most important things to communicate is the state of the mainline build. If you’re using Cruise there’s a built in web site that will show you if there’s a build in progress and what was the state of the last mainline build. Many teams like to make this even more apparent by hooking up a continuous display to the build system – lights that glow green when the build works, or red if it fails are popular. A particularly common touch is red and green lava lamps – not just do these indicate the state of the build, but also how long it’s been in that state. Bubbles on a red lamp indicate the build’s been broken for too long. Each team makes its own choices on these build sensors – it’s good to be playful with your choice (recently I saw someone experimenting with a dancing rabbit.)

If you’re using a manual CI process, this visibility is still essential. The monitor of the physical build machine can show the status of the mainline build. Often you have a build token to put on the desk of whoever’s currently doing the build (again something silly like a rubber chicken is a good choice). Often people like to make a simple noise on good builds, like ringing a bell.

CI servers’ web pages can carry more information than this, of course. Cruise provides an indication not just of who is building, but what changes they made. Cruise also provides a history of changes, allowing team members to get a good sense of recent activity on the project. I know team leads who like to use this to get a sense of what people have been doing and keep a sense of the changes to the system.

Another advantage of using a web site is that those that are not co-located can get a sense of the project’s status. In general I prefer to have everyone actively working on a project sitting together, but often there are peripheral people who like to keep an eye on things. It’s also useful for groups to aggregate together build information from multiple projects – providing a simple and automated status of different projects.

Good information displays are not only those on a computer screens. One of my favorite displays was for a project that was getting into CI. It had a long history of being unable to make stable builds. We put a calendar on the wall that showed a full year with a small square for each day. Every day the QA group would put a green sticker on the day if they had received one stable build that passed the commit tests, otherwise a red square. Over time the calendar revealed the state of the build process showing a steady improvement until green squares were so common that the calendar disappeared – its purpose fulfilled.

Automate Deployment

To do Continuous Integration you need multiple environments, one to run commit tests, one or more to run secondary tests. Since you are moving executables between these environments multiple times a day, you’ll want to do this automatically. So it’s important to have scripts that will allow you to deploy the application into any environment easily.

A natural consequence of this is that you should also have scripts that allow you to deploy into production with similar ease. You may not be deploying into production every day (although I’ve run into projects that do), but automatic deployment helps both speed up the process and reduce errors. It’s also a cheap option since it just uses the same capabilities that you use to deploy into test environments.

If you deploy into production one extra automated capability you should consider is automated rollback. Bad things do happen from time to time, and if smelly brown substances hit rotating metal, it’s good to be able to quickly go back to the last known good state. Being able to automatically revert also reduces a lot of the tension of deployment, encouraging people to deploy more frequently and thus get new features out to users quickly. (The Ruby on Rails community developed a tool calledCapistrano that is a good example of a tool that does this sort of thing.)

In clustered environments I’ve seen rolling deployments where the new software is deployed to one node at a time, gradually replacing the application over the course of a few hours.

A particularly interesting variation of this that I’ve come across with public web application is the idea of deploying a trial build to a subset of users. The team then sees how the trial build is used before deciding whether to deploy it to the full user population. This allows you to test out new features and user-interfaces before committing to a final choice. Automated deployment, tied into good CI discipline, is essential to making this work.

Benefits of Continuous Integration

On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk. My mind still floats back to that early software project I mentioned in my first paragraph. There they were at the end (they hoped) of a long project, yet with no real idea of how long it would be before they were done.

The trouble with deferred integration is that it’s very hard to predict how long it will take to do, and worse it’s very hard to see how far you are through the process. The result is that you are putting yourself into a complete blind spot right at one of tensest parts of a project – even if you’re one of the rare cases where you aren’t already late.

Continuous Integration completely finesses this problem. There’s no long integration, you completely eliminate the blind spot. At all times you know where you are, what works, what doesn’t, the outstanding bugs you have in your system.

Bugs – these are the nasty things that destroy confidence and mess up schedules and reputations. Bugs in deployed software make users angry with you. Bugs in work in progress get in your way, making it harder to get the rest of the software working correctly.

Continuous Integrations doesn’t get rid of bugs, but it does make them dramatically easier to find and remove. In this respect it’s rather like self-testing code. If you introduce a bug and detect it quickly it’s far easier to get rid of. Since you’ve only changed a small bit of the system, you don’t have far to look. Since that bit of the system is the bit you just worked with, it’s fresh in your memory – again making it easier to find the bug. You can also usediff debugging – comparing the current version of the system to an earlier one that didn’t have the bug.

Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. This is partly because you get bug interactions, where failures show as the result of multiple faults – making each fault harder to find. It’s also psychological – people have less energy to find and get rid of bugs when there are many of them – a phenomenon that the Pragmatic Programmers call the Broken Windows syndrome.

As a result projects with Continuous Integration tend to have dramatically less bugs, both in production and in process. However I should stress that the degree of this benefit is directly tied to how good your test suite is. You should find that it’s not too difficult to build a test suite that makes a noticeable difference. Usually, however, it takes a while before a team really gets to the low level of bugs that they have the potential to reach. Getting there means constantly working on and improving your tests.

If you have continuous integration, it removes one of the biggest barriers to frequent deployment. Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features, and generally become more collaborative in the development cycle. This helps break down the barriers between customers and development – barriers which I believe are the biggest barriers to successful software development.

Introducing Continuous Integration

So you fancy trying out Continuous Integration – where do you start? The full set of practices I outlined above give you the full benefits – but you don’t need to start with all of them.

There’s no fixed recipe here – much depends on the nature of your setup and team. But here are a few things that we’ve learned to get things going.

One of the first steps is to get the build automated. Get everything you need into source control get it so that you can build the whole system with a single command. For many projects this is not a minor undertaking – yet it’s essential for any of the other things to work. Initially you may only do build occasionally on demand, or just do an automated nightly build. While these aren’t continuous integration an automated nightly build is a fine step on the way.

Introduce some automated testing into your build. Try to identify the major areas where things go wrong and get automated tests to expose those failures. Particularly on an existing project it’s hard to get a really good suite of tests going rapidly – it takes time to build tests up. You have to start somewhere though – all those cliches about Rome’s build schedule apply.

Try to speed up the commit build. Continuous Integration on a build of a few hours is better than nothing, but getting down to that magic ten minute number is much better. This usually requires some pretty serious surgery on your code base to do as you break dependencies on slow parts of the system.

If you are starting a new project, begin with Continuous Integration from the beginning. Keep an eye on build times and take action as soon as you start going slower than the ten minute rule. By acting quickly you’ll make the necessary restructurings before the code base gets so big that it becomes a major pain.

Above all get some help. Find someone who has done Continuous Integration before to help you. Like any new technique it’s hard to introduce it when you don’t know what the final result looks like. It may cost money to get a mentor, but you’ll also pay in lost time and productivity if you don’t do it. (Disclaimer / Advert – yes we at ThoughtWorks do some consultancy in this area. After all we’ve made most of the mistakes that there are to make.)

Final Thoughts

In the years since Matt and I wrote the original paper on this site, Continuous Integration has become a mainstream technique for software development. Hardly any ThoughtWorks projects goes without it – and we see others using CI all over the world. I’ve hardly ever heard negative things about the approach – unlike some of the more controversial Extreme Programming practices.

If you’re not using Continuous Integration I strongly urge you give it a try. If you are, maybe there are some ideas in this article that can help you do it more effectively. We’ve learned a lot about Continuous Integration in the last few years, I hope there’s still more to learn and improve.

For articles on similar topics…

…take a look at the following tags:

Acknowledgments

First and foremost to Kent Beck and my many colleagues on the Chrysler Comprehensive Compensation (C3) project. This was my first chance to see Continuous Integration in action with a meaningful amount of unit tests. It showed me what was possible and gave me an inspiration that led me for many years.

Thanks to Matt Foemmel, Dave Rice, and everyone else who built and maintained Continuous Integration on Atlas. That project was a sign of CI on a larger scale and showed the benefits it made to an existing project.

Paul Julius, Jason Yip, Owen Rodgers, Mike Roberts and many other open source contributors have participated in building some variant of CruiseControl. Although a CI server isn’t essential, most teams find it helpful. CruiseControl and other CI servers have played a big part in popularizing and enabling software developers to use Continuous Integration.

One of the reasons I work at ThoughtWorks is to get good access to practical projects done by talented people. Nearly every project I’ve visited has given tasty morsels of continuous integration information.

Significant Revisions

01 May 2006: Complete rewrite of article to bring it up to date and to clarify the description of the approach.

10 September 2000: Original version published.

COMO O VIVER DE BLOG CAPTUROU 3.174 EMAILS PARA SUA LISTA EM APENAS 1 MÊS

January 16, 2015Marketing Digitalemail marketing, mailchimp, marketing digitalFernando Madeira

Capturar emails é uma tarefa obrigatória se você deseja levar o seu site ou empreendimento digital para outro nível.

No guia sobre como criar uma lista de email, vimos números que comprovam que email marketing ainda é o canal mais rentável, apesar do forte crescimento das mídias sociais.

É por esse motivo que o Viver de Blog foi cuidadosamente projetado para otimizar a conversão de emails.

Nesse artigo, mostrarei a você como esse site capturou 3.174 emails em apenas 1 mês de vida.

São estratégias eficazes que você pode aplicar no seu próprio site hoje mesmo.

Continue lendo esse artigo para saber mais sobre:

EVOLUÇÃO DOS EMAILS: CRIANDO UM ATIVO PARA O VIVER DE BLOG

Criar um ativo é investir em algo que tende a gerar benefícios para você no futuro.

Criar um ativo é solidificar as bases do seu site/negócio.

Montar e cuidar de uma lista de email é, para mim, criar um ativo valioso.

Através de uma lista de emails, você consegue:

Promover seus artigos do blog
Interagir com seus leitores
Melhores Conversões
Obter mais receitas na venda de seus produtos ou de afiliados

Portanto, ao capturar emails você consegue gerar mais tráfego, mais conversões e até mesmo mais receitas para seu site.

Veja agora como foi a evolução do número de emails da lista Viver de Blog em apenas 1 mês de vida:

Todas as barras refletem um dia. Notem que o primeiro dia foi bastante agitado, com quase 1.000 cadastrados. Depois, a lista foi crescendo naturalmente, até atingir os 3.174 emails.

Se você notar coma atenção, o gráfico possui mais do que 30 dias. O período analisado é de02/05/2013 até 06/06/2013.

Resolvi incluir os 5 dias antes do lançamento do blog no dia 07/05/2013 para vocês verem como aestratégia de pré-lançamento ajudou bastante a criar a lista do Viver de Blog, antes mesmo do blog ser publicado. (falarei melhor sobre esse tema no próximo tópico)

O gráfico acima reflete a evolução cumulativa (número total de emails) que o Viver de Blog alcançou no período.

Veja agora, como foi a evolução diária, ou seja, quantos emails foram cadastrados na lista diariamente.

BOOM! Logo no primeiro dia da fase de pré-lançamento do site, 893 emails foram cadastrados.

A segunda barra alta, com 267 emails cadastrados em um dia, aconteceu justamente no dia do lançamento do blog, 07/05/2013.

A terceira barra alta, com 309 emails, ocorreu no dia 14/05/2013, dia extremamente agitado e obteve um número de visitas muito próximo do lançamento.

Nesse dia, a publicação do artigo sobre 18 problemas de usabilidade que deixam seus leitores furiosose as estratégias de divulgação para geração de tráfego foram as principais responsáveis pelo grande número de visitas e emails cadastrados.

Retirando esses 3 dias “atípicos”, a média por dia no Viver de Blog nesse período até o dia 06/06/2013 é de 52 emails capturados.

Estimando que essa média conseguirá se manter constante até o final do ano, o que acredito ser uma estimativa razoável, já que o HC Investimentos consegue números muito próximos, poderei ter uma lista acima de 10.000 emails, ou mais precisamente em torno de 13.195 emails.

Não seria nada mal para um blog com apenas 7 meses de vida. (porém, a minha meta ambiciosa é muito maior!)

A ESTRATÉGIA DE PRÉ-LANÇAMENTO: CRIANDO UMA LISTA ANTES MESMO DO BLOG NASCER

Já comentei um pouco de como foi a estratégia geral de pré-lançamento no primeiro artigo dessa série sobre o primeiro mês do Viver de Blog.

Para relembrar você e colocando o foco nos emails e não nas visitas, segue o resumo da estratégia por trás dos 1.117 emails coletados antes do lançamento do Viver de Blog.

No meu site sobre investimentos, o HC Investimentos, eu recebia mensagens com perguntas relacionadas a criar um site, administrá-lo e rentabilizá-lo.

Havia, portanto, um público que, além de acompanhar meus artigos sobre investimentos, estava disposto também a entender como funcionava os “bastidores” do HC Investimentos. Como montar um site, posicioná-lo e monetizá-lo.

Desse modo, criei uma nova lista de email no Mailchimp (link afiliado) direcionada apenas para esse público interessado nos “bastidores”.

Enviei uma campanha para os leitores do HC Investimentos e uma boa parcela gostou da ideia e se inscreveu na lista de pré-lançamento do Viver de Blog. Veja o resultado abaixo:

No dia do lançamento do Viver de Blog, a lista de pré-lançamento já tinha um pouco mais de 1.000leitores interessados. Na verdade, MUITO interessados, porque a taxa de abertura do primeiro email enviado foi de 78% e a taxa de clique de 63,8%.

Dica para você aplicar: Antes de qualquer tipo de lançamento, crie uma lista exclusiva para ele. Crie expectativa para esse lançamento, solte teasers do novo projeto ao longo do tempo e capture emails para essa lista de pré-lançamento.

No artigo anterior, o leitor Guilherme Nunes deixou esse comentário:

Henrique, caso não se tenha um projeto anterior como vc tem o HC investimentos, qual seria uma boa estratégia pra fazer o pré-lançamento do site? Na lista de email pessoal seria um tiro no pé? Abraço.

E eu respondi dessa maneira:

Oi Guilherme!

Uma estratégia que considero eficaz:

1. Crie uma landing page no seu site com objetivo de capturar emails.
2. Nessa landing page, mostre que seu site irá lançar em X dias e os motivos pelos quais os leitores devem colocar seu email para acompanharem seu novo site.
3. Escreva guest posts em sites relacionados, colocando links estratégicos para essa landing page.

Pronto! Se tudo sair como esperado, você já criará uma lista de email do zero ANTES mesmo de lançar seu blog. Quando chegar o grande dia, envie uma campanha para esse pessoal do pré-lançamento e já comece com uma vantagem competitiva. Abraços!

E ainda complementei:

Oi Guilherme!

Existe um site que faz praticamente todo esse trabalho para você. É o LaunchRock. Abraços!

DESIGN: OTIMIZANDO CONVERSÕES (E OS NÚMEROS POR TRÁS DOS 3.174 EMAILS)

Você já deve ter percebido que o design do Viver de Blog foi projetado com o principal objetivo de otimizar a captura de emails.

Acredite, foram meses de pesquisa, reuniões com o meu designer (PageLab é o site dele) no Skype e muitas novas interações e resolução de pequenos problemas até chegar à essa versão final.

Nessa seção, mostrarei a você como o design otimizado para capturar emails do Viver de Blog performou na prática. Número por número.

Afinal, todos os campos de captura de emails são devidamente trackeados aqui no Viver de Blog e compartilharei com você exatamente quais são os locais mais “quentes” para capturar emails.

1. The Featured Box (53,11%)

A Featured Box É um termo utilizado pelo Derek Halpern do site Social Triggers para o grande campo de captura de email logo no topo da homepage do seu site.

Veja como a utilizo aqui no Viver de Blog:

Esse grande campo de captura de email é responsável por, nada mais nada menos, que 53,11% (ou 1.674 emails) de captura de TODOS os emails cadastrados na lista do Viver de Blog. (todos os números serão detalhados no final dessa seção)

Sim, você leu corretamente. 53,11%!

E pensar que essa é uma solução inovadora que praticamente nenhum blog aqui no Brasil está utilizando… #ficadica

Não é todo site que você conseguirá implementá-la com facilidade, mas nada que contratar um designer não resolva. No longo prazo, os custos serão invisíveis em comparação com os benefícios.

Os temas da StudioPress (link afiliado), turbinados pela framework Genesis, oferecem boas soluções para implementação dessa funcionalidade.

Inclusive, a Genesis da StudioPress é a framework que utilizo aqui mesmo no Viver de Blog.

Se você deseja um tema pronto que já venha embutido com essa funcionalidade, uma boa opção é o “Generate Theme“. Você ainda pode customizá-lo com as generate box.

2. Na Página “Sobre” (15,1%)

A página “sobre” é uma página com muitas visitas em diversos blogs.

Isso ocorre porque o leitor de primeira viagem quer saber mais sobre quem escreve o site e porque esse site irá ajudá-lo.

Aqui no Viver de Blog ela é estrategicamente planejada para atrair tráfego e otimizada para conversão, com 3 áreas para captura de email.

Essa página, somando as 3 áreas de captura dentro da página (não incluindo a sidebar e a caixa no topo), foram responsáveis por 15,1% (ou 476 emails) de todos os emails coletados.

Se você ainda não possui uma página sobre em seu site ou não utiliza todo seu potencial, acredito que os dados acima são suficientes para você pensar com mais carinho nessa importante página.

3. Sidebar (13,83%)

Se você estiver lendo esse artigo em qualquer dispositivo com mais de 600px de largura, você está vendo essa “linda” caixa ao lado esquerdo para captura de emails.

Ela foi responsável por 13,83% (ou 436 emails) das conversões na captura de email desse site.

Auto-promoção: Se você ainda não cadastrou seu email nesse site, aproveite essa oportunidade e seja o primeiro a receber todas as novidades do Viver de Blog.

O fato dela correr junto com a página era algo que eu estava muito ansioso para testar e os resultados mostram que ela tem sido muito efetiva na geração de novos emails para a lista.

Além disso, como ela é visível na homepage, nos artigos e nas páginas, ela tem grandes chances de capturar mais emails do que as demais alternativas.

4. No topo de cada artigo (10,76%)

Confesso que essa foi uma grande surpresa para mim.

Apesar de saber que ela teria boas chances de gerar mais emails para a lista do Viver de Blog, não imaginaria que poderia gerar 10,76% (ou 339 emails) em apenas 1 mês.

Afinal, ela é visível apenas no topo dentro de cada artigo.

A minha hipótese era de que antes do leitor colocar seu email nesse campo, ele gostaria de ler o artigo primeiro e, provavelmente, só converter pela caixa de captura na sidebar ou no final do artigo.

Entretanto, o design focado na conversão parece ter atraído efetivamente a atenção dos leitores.

Por esse motivo, faço questão de repetir um dos mantras desse site: Always Be Testing (Esteja Sempre Testando). Não importa o que você acha ou o quanto forte é a sua hipótese. Se você não testar, nunca saberá se funcionará na prática.

Está gostando desse artigo?

Aproveite e cadastre seu email no campo abaixo para ser o primeiro a receber novas atualizações do site.

FIQUE ATUALIZADO!

Insira aqui o seu email para receber gratuitamente as atualizações do blog!

Apresentando: Os resultados detalhados:

Como vimos acima, as áreas mais “quentes” para capturar email foram:

featured-box (home-header): 53,11%
Dentro da página Sobre: 15,10%
Sidebar: 13,83%
No topo dos artigos (post-header): 10,76%

Veja os 10 lugares que mais capturaram emails abaixo:

Algumas observações:

Os números após “sobre” refletem a posição da caixa de captura. “1” é a primeira caixa e “3” é a terceira e última caixa, por exemplo.
“after-post” é a caixa de captura de email no final de cada artigo.
“7-passos-mais-trafego-1″ é a primeira caixa de captura de email dentro do artigo sobre os 7 passos para gerar mais tráfego.
“mais-trafego” e “mais receitas” são caixas de captura de email dentro das respectivas páginas:Mais Tráfego e Mais Receitas.

Recentemente, tive uma conversa com o Márcio Duarte, designer responsável pelo design do Viver de Blog, que é uma adaptação do tema “Eleven40″ da StudioPress (link afiliado).

O bate-papo foi basicamente sobre esses resultados que estou compartilhando com você aqui, analisando na prática as hipóteses que bolamos juntos para a ideia e implementação do design do Viver de Blog.

Um dos temas que discutimos por alguns minutos foi a caixa de captura de email no final de cada post.

Olhando rapidamente, ela só converteu 1,90% (ou 60 emails) de todos os emails da lista.

Eu acreditava que esse número iria ser bem maior, assim como também não imaginava que

As really with viagra meaning very have lotion: scrubber calories http://spikejams.com/female-viagra a feeling do shopping feet viagra uk than the hair blueberry cialis no prescription wouldn’t. Usally life be cheap viagra online years completely was live because discount cialis look that, this for cialis online is have Better female viagra week absorbed So viagra dosage Refiner favorite.

o número de captura através da caixa no topo dos artigos (post-header) fosse tão alto (10,76%).

Conversa vai, conversa vem, concluímos que a “baixa” conversão do final do post não se deve apenas pelo local, mas sim pela quantidade de caixas que o leitor já teria visto anteriormente.

Suponha o seguinte exemplo:

Um novo leitor entrou através da homepage e já viu a grande caixa de captura logo de cara. Ignorou.
Vendo na sidebar as informações sobre os R$ 8.295,22 gerados em menos de 14h clicou na página sobre para ler mais. Dentro dela, encontrou 3 caixas para captura de email. Novamente, ignourou.
Depois, clicou em no artigo sobre os 7 passos para gerar mais tráfego e, dentro desse post, viu a caixa no topo do artigo. Ignorou.
Ao longo da leitura, a caixa da sidebar flutuante deu novamente mais opções para ele cadastrar seu email. Para variar, ignorou.
Ainda na leitura do artigo, ele recebeu mais duas opções para cadastrar seu email no meio do conteúdo. Novamente, nada.
Finalmente, após todo esse caminho, ele vê a caixa de captura no final do artigo e resolve colocar seu email. Ufa!

A conclusão:

Não é que a conversão da caixa no final do artigo seja baixa, mas são tantas opções oferecidas aqui no Viver de Blog antes do leitor chegar nesse ponto, que torna-se natural o baixo número de emails através desse canal.

Voltando à nossa análise geral, se os dados compartilhados acima não fossem suficientes, ainda é possível analisá-los sob uma nova perspectiva.

Dessa vez, buscando entender qual página trouxe mais emails. Veja os dados abaixo:

A primeira página na imagem (“/”) é a homepage, responsável por 56,85% de conversão de todos os emails capturados.

A página sobre vem em segundo, com 24,90%.

Somente essas duas páginas correspondem por mais de 80% de captura de emails do site inteiro!

Os menos de 20% restantes vem através de artigos.

Se você já está achando essa análise completa, saiba que ainda é possível aumentar o nível de segmentação, buscando entender qual campo de captura de email funcionou melhor em cada uma dessas páginas.

Na homepage:

93,36% através da grande caixa de captura
6,64% através da sidebar

Números avassaladores. A featured-box é uma “máquina” de captura de emails.

Na página sobre:

O topo do artigo (post-header) teve 20,51% de conversão.
A sidebar, 18,85%.
E dentro do artigo, 60,64%.

Gosto desses números porque refletem que muita gente está lendo até o final essa página, que é uma das mais importantes no Viver de Blog, já que transmite um pouco da minha história e o que o blog tem a oferecer de valor para seu público.

Na página dos 7 passos para gerar mais tráfego:

35,82% através da sidebar
33,58% ao longo do artigo
26,12% no topo do artigo
4,48% no final do artigo

Talvez nesse momento você esteja coçando a cabeça e pensando:

Meu deus! O Henrique faz o tracking de TUDO aqui no Viver de Blog. Por quê?

Se me permite responder, esse tracking reflete exatamente a direção para a qual o blog deve ir.

São números como taxa de conversão de uma caixa de email, comentários em um artigo, visitas únicas, metas cumpridas e diversas análise customizadas que me permitem ter em mãos um mapa (um guia).

Se você não olha nenhum número no seu site, nem que seja ao menos visitas, bounce rate e metas cumpridas, é como se você estivesse dirigindo em uma longa estrada, porém, sem um mapa, totalmente cego.

A passagem abaixo representa exatamente essa metáfora do mapa.

como ganhar dinheiro online

Alice: Poderia dizer-me, por favor, que caminho devo tomar agora?
Gato: Depende muito de onde está querendo chegar.
Alice: Não me importo muito para onde …
Gato: Então não importa que caminho irá tomar.

~ Gato Risonho, em “Alice no País das Maravilhas”

“Roubei” essa famosa passagem da página sobre do Bruno (Empreendedor Digital).

Faz sentindo, não é mesmo?

Portanto, se você deseja alcançar um objetivo, seja atrair mais tráfego, mais emails ou mais vendas, você precisa de um mapa em mãos.

Esse mapa só pode ser conseguido se você se dedicar a analisar números como esses analisados aqui no Viver de Blog (acredite, essa é apenas uma pequena parte do que analiso).

Com uma base sólida do que funciona e não funciona, você poderá adaptar o rumo para o qual o seu blog deve ir.

Escute seus leitores, analise números e leia muito.

Às vezes, alguém chegará para você e dirá que o seu sucesso foi mera sorte, mas como bem sabemos:

Sucesso é apenas uma questão de sorte. Pergunte a qualquer fracassado. ~ Earl Wilson

CONCLUSÃO – RECAPITULANDO

Esse artigo foi além do que eu esperava. Já são mais de 2.700 palavras aqui no editor de texto.

Eu ainda gostaria de colocar uma nova seção sobre a importância das landing pages, páginas de verificação e thank-you pages, mas deixarei elas para um artigo mais adequado, sobre conversões. (a ser publicado no dia 26/06)

As lições que você pode tirar desse artigo são:

Sempre que for lançar um site/produto/serviço não esqueça de criar uma lista de pré-lançamento e soltar teasers sobre o que está por vir.
Não tenha receio de colocar campos de captura de email em diversas áreas do seu blog.

As regiões que conseguiram capturar mais emails aqui no Viver de Blog nesse primeiro mês foram:

Featured-box (home-header): 53,11%
Dentro da página Sobre: 15,10%
Sidebar: 13,83%
No topo dos artigos (post-header): 10,76%

Busque entender o funcionamento do seu site por completo. Cada clique, cada comentário, cada visita tem seu propósito. Junte todas as informações possíveis sobre o que está ou não funcionando para você ter um mapa do caminho a percorrer.
Esteja sempre testando. Não se prenda a hipóteses pessoais. Busque experimentar. Você poderá se surpreender com pequenas mudanças ou ideias.
Finalmente, lembre-se de que o email marketing continua sendo o principal canal para direcionar visitas e vendas.

Independente do número de emails que o Viver de Blog capturou no seu primeiro mês de vida, o importante é me aproximar cada vez mais com você, querido(a) leitor(a).

Espero que as dicas compartilhadas até hoje tenham ajudado você de alguma forma e também espero que futuramente possam ajudar ainda mais.

Confesso que a vida corrida me impede de escrever e compartilhar com você o tanto que gostaria e busco otimizar o meu dia-a-dia para que artigos como esse sejam publicados mais frequentemente.

Portanto, se você tiver qualquer tipo de comentário a fazer, seja dúvida, crítica ou elogio, sinta-se à vontade para expressar sua opinião.

O PODER DO EMAIL MARKETING: COMO CRIAR UMA LISTA DE EMAIL PODEROSA

January 16, 2015Marketing Digitalemail marketing, mailchimp, marketing digitalFernando Madeira

O assunto Email Marketing está pegando fogo!

O “velho” ditado sobre marketing digital já dizia:

O dinheiro está na lista (The money is in the list)

Se você não captura emails para a sua lista de email, me desculpe, mas você está deixando dinheiro na mesa.

Se você ainda acha que deve focar boa parte do seu tempo nas redes sociais como facebook, twitter, google plus, youtube, pinterest e outra sensação do momento – você irá se surpreender com esse artigo.

Assim como no artigo anterior sobre como gerar mais tráfego para seu site, compartilharei diversos estudos que mostram como o email (email marketing) destrói as redes sociais (social media). Alguns números para jogar lenha na fogueira:

92% dos usuários na internet tem ao menos 1 conta de email.
72% dos usuários checam a sua caixa de entrada de emails 6x ou mais todo dia.
Existem mais de 3 Bilhões de contas de emails criadas. (São 3x mais contas de email do que todas as contas do facebook + twitter combinadas!)
Clientes que recebem uma newsletter por email gastam 83% mais do que não cadastrados.
Em relação ao uso comercial, 75% dos usuários utilizam o email contra apenas 3% das redes sociais.
Em 2012 o email marketing teve um impressionante ROI (Retorno Sobre Investimento) de4000% (!).

Gostou dos números? Isso é apenas uma pequena parte do que está por vir…

Também mostrarei 2 softwares para email marketing top de linha e qual precisamente utilizo nos meus sites.

E para finalizar, quais são os 10 principais locais de seu site/blog que você precisa capturar emails. São locais estratégicos que farão a sua lista duplicar o número de novos emails diariamente.

Continue lendo para aprender mais sobre como criar uma lista de email poderosa.

EMAIL MARKETING: OU VOCÊ PRECISA DELE, OU VOCÊ PRECISA DELE

Novamente, se você não tem uma estratégia de email marketing, nem que seja ao menos capturar emails no seu site, você está deixando dinheiro na mesa.

Aqui estão as principais razões pelas quais você precisa criar e cultivar a sua lista de emails:

Para promover seus artigos do blog
Para interagir com seus leitores
Para conseguir conversões melhores
Para obter mais receitas na venda de seus produtos ou de afiliados

Se você já tentou divulgar um produto através das redes sociais e do email, tenho certeza que você já notou como o email converte MUITO melhor.

Veja a comparação dessas 2 categorias quando o objetivo foi promover o meu eBook sobre investimentos de janeiro até março de 2013:

Redes Sociais: 1076 visitas | 2 vendas | 0,19% taxa de conversão
Email: 485 visitas | 14 vendas | 2,87% taxa de conversão

Conclusão: Comece a montar sua lista de emails para ONTEM!

Infográficos sobre Email Marketing

Nada melhor do que comprovar uma opinião com fatos.

Por esse motivo, separei 2 infográficos para compartilhar com você e que mostram a superioridade do email marketing em comparação com as redes socias.

link para o infográfico #1

Você pode acessar todos os infográficos que coleto nesse link do meu Pinterest. Basta seguir o tópico ou a mim.

link para o infográfico #2

Esse infográfico é muito bom e vai direto ao ponto nos seguintes tópicos:

Benefícios
Crescimento
Uso
Alcance
Funcionalidades

A conclusão dele é essencial:

As mídias sociais merecem toda a atenção que vêm recebendo, mas, quando analisamos resultados e efetividade, principalmente de comunicações comerciais, o email marketing é o grande vencedor.

Digg, Orkut e a Morte das Redes Sociais

As redes sociais estão mudando como nunca.

Há 5 anos atrás, o tráfego dos sites era movido pelo Digg. Alcançar a primeira página do Digg era como encontrar o tesouro perdido nos sete mares.

Era uma chuva de tráfego garantida. Entretanto, essa rede social hoje está praticamente morta. Observe a queda pelo interesse no Digg:

Não sabemos se o mesmo irá ocorrer com o Facebook, Twitter e as redes mais populares.

Porém, é preciso saber que as redes sociais são uma área de grandes mudanças a todo tempo. Alguém lembra do Orkut?

Você NÃO é o dono de sua página no Facebook, Twitter e qualquer rede social

Atualmente, estamos mais conectados do que nunca.

Curtimos algo? Postamos no facebook.
Lemos uma matéria interessante? Tweetamos (olha o termo) o link no Twitter.
Tiramos uma foto maneira? Publicamos no Instagram.
Saímos para algum lugar? Check-in no Foursquare.

Entretanto, você precisa saber que NÃO é o dono de suas páginas nesses redes sociais.

O dono de sua fanpage no facebook é o facebook e o dono de sua página no twitter é o twitter.

Eles perguntaram a você se gostaria de mudar o visual de sua página? Não.
Eles dizem a você quais regras devem seguir? Sim.
Eles podem excluir sua página sem questionar você? Sim.

Você não pode colocar todos os seus esforços em uma única rede social que você não é nem mesmo o dono dela.

Vamos supor que a sua página no facebook de 50.000 curtidas foi deletada ou hackeada.

Como você recupera esse pessoal todo?

Você não pode entrar no perfil de todas as pessoas que curtiram sua página e clicar no curtir da sua página novamente.

E o email?

Simples, você sempre terá a sua lista de emails em mãos.

Trata-se de um pessoal que confirmou a inscrição na sua lista, que cedeu a você autorização para entrar em contato quando desejar.

Você é o dono da sua lista de emails. É um ativo que só tende a crescer com o tempo.

Mesmo se um software de email marketing falir, você poderá exportar a sua lista de email para uma planilha e importar em outro software.

Portanto, na próxima vez que você observar alguém colocando todas as fichas em uma única rede social lembre-se de compartilhar com essa pessoa esse artigo. Um dia ela irá agradecer a você.

Falando em software para email marketing…

QUAL É O MELHOR SOFTWARE PARA EMAIL MARKETING?

Atualmente eu considero apenas 2 softwares que são 5 estrelas: MailChimp e Aweber.

Ambos possuem suas vantagens e desvantagens, que cito a seguir.

MailChimp

Confesso – eu amo o MailChimp. Ele é, sem dúvida, o software mais valioso que utilizo e também o que gera o maior retorno sobre investimento.

Quando eu coloco a camisa cinza com o Freddie (o macaco mascote do MailChimp), as campanhas fluem naturalmente! hahaha

Sim, eu realmente tenho e uso uma camisa do MailChimp. (coisa de fã mesmo!)

Ok, chega de blá-blá-blá e vamos ao que realmente interessa – o porquê essa ferramenta é a minha favorita quando se trata de email marketing.

Vantagens do MailChimp:

Belíssima interface (fácil de usar e com visual muito agradável)

Através do Dashboard você já verifica como foi sua última campanha, o crescimento das suas listas, quem se inscreveu recentemente, além de uma navegação fácil para criar novas campanhas e analisar relatórios.

É um site extremamente fácil de usar. A preocupação com design e a experiência do usuário é uma das prioridades da equipe.

Drap And Drop Editor – Editor de Texto é incrível. Em poucos minutos você consegue montar uma campanha apresentável e enviá-la

Você pode arrastar blocos de texto, imagens, grupo de imagens, botões para compartilhar nas redes sociais, botões para seguirem você nas redes sociais, botões personalizados para uma call to action, footer personalizadas…

Enfim, tudo isso para facilitar o visual e o conteúdo do seu email.

Só você usando esse novo editor para perceber como o processo de escrever e enviar emails é rápido e fácil.

O Editor é tão incrível que se você visitar a homepage do MailChimp (link afiliado – leia mais abaixo sobre os benefícios dele) você verá um vídeo demonstrando como criar uma campanha personalizada em menos de 1 minuto.

Preço Inicial (É de graça!)

Se a sua lista tiver menos do que 2.000 emails e você não ultrapasse o limite de 12.000 emails enviados por mês, a sua conta é totalmente grátis!

Como eu não conhecia nenhum software, a opção de aproveitar todo o potencial de graça dessa plataforma foi o que me fez decidir por ela.

E se você utilizar esse meu link afiliado, tanto eu como você ganhamos $30,00 de crédito para usar dentro do MailChimp. #win-win

Quando você passar do limite de 2.000 emails cadastrados ou 12.000 emails enviados por mês, os planos pagos são esses:

Mapa de Cliques

Na imagem abaixo, o mapa de cliques de uma campanha enviada. É possível saber exatamente quantas e quais pessoas clicaram em cada link e a porcentagem dele em relação ao total.

Uma das curiosidades que todo empreendedor digital tem na hora de enviar seus emails é saber onde posicionar seus links, quantos links colocar e quais links são os mais clicados.

Com o MailChimp, analisar os cliques nos links é mais fácil que roubar doce de criança.

Vale para tudo. Imagens, links, botões. Qualquer elemento que tiver um link pode ser trackeado com precisão.

E mais: você ainda pode ver exatamente qual leitor (o email dele, no caso) clicou nesses links e quantas vezes clicou.

Uma ótima oportunidade para entender quem realmente está interessado no seu conteúdo.

Ranking (Estrelas) dos emails cadastrados

O próprio MailChimp categoriza os emails cadastrados na lista de 1 estrela (menos engajados) até5 estrelas (mais engajados).

O usuário de 1 estrela é aquele “chato” que não abre seus emails, ou quando abre marca como spam. Geralmente, não vale a pena ter esse tipo de usuário na lista, já que existe um custo para mantê-la.

Já o usuário de 5 estrelas é aquele “amigão” que sempre abre seus emails, clica nos links e os responde com elogios.

Entre 1 e 5, a quantidade de estrelas dependerá praticamente desses fatores: abrir email, clicar nos links, responder emails.

Quanto mais engajdos os leitores forem, mais próximo das 5 estrelas eles estarão.

Por que essa categorização é importante?

Porque permite você segmentar emails apenas para diversos grupos.

Quer enviar um email divulgando um produto, mas não quer incomodar certos usuários da lista?

Envie apenas para o grupo com mais de 2 estrelas. Essa segmentação é moleza de fazer no MailChimp.

Desvantagens do MailChimp:

Poucas opções de design para campos de emails dentro do site.
Não é possível segmentar uma lista de outra. (Isso já foi motivo de várias trocas de emails com eles, porque o recurso de grupos ou segmento estático não é exatamente o que quero)
Falta um tracking melhor para saber de onde exatamente o usuário cadastrou seu email.

São desvantagens que, ao serem solucionadas, deixariam o MailChimp perfeito (na minha visão, claro).

Entretanto, ele já é um software bem robusto e, como já deixei claro, adoro e uso para todos meus sites.

Você pode criar uma conta gratuita no MailChimp e ainda ganhar $30,00 de bônus. Basta clicar aqui(link afiliado) e fazer sua inscrição hoje mesmo.

Aweber

Eu gosto tanto do MailChimp que nunca pensei em trocar para a Aweber.

Entretanto, conheço muitos amigos que utilizam esse software por algumas razões.

Vantagens:

É possível fazer o tracking de tudo o que você imaginar.

O próprio software permite que você saiba qual é a taxa de conversão de qualquer campo de email no seu site ou fora dele, como por exemplo em uma página do facebook.

Desse modo, você pode analisar com precisão quais campos de email estão trazendo mais emails para sua lista e quais devem ser melhorados.

Muitas opções de design para campos de email dentro do site.
Inúmeras possibilidades de segmentação e de autoresponders.
Testes multivariáveis de emails.

Desvantagens:

Editor de texto é horrível e arcaico.
A curva de aprendizado para utilizar boa parte do potencial da ferramenta é alta (demora até pegar a “manha” do software).
Emails em HTML não são visualmente agradáveis como no MailChimp.
Posso estar enganado, mas algumas partes do email devem ficar em inglês (como o “unsubscribe”).

Quero deixar claro que esse software também é excelente e compete fortemente com o MailChimp.

Avalie todas as vantagens de ambos e veja qual software é mais adequado para você.

Por utilizar o MailChimp desde o início, citarei com frequência essa ferramenta quando o assunto for email marketing.

COMO TURBINAR SUA LISTA DE EMAILS: OS 10 LOCAIS ESTRATÉGICOS PARA VOCÊ CAPTURAR MUITO MAIS EMAILS

É matemática simples. Se você deseja ter mais emails cadastrados na sua lista, você precisa utilizarmais campos de captura de email.

Existem diversos locais no seu site que você pode aproveitar para capturar mais emails que você nunca havia pensado.

A pergunta é: onde devo colocar esses campos de captura de email?

Existem 10 lugares que convertem extremamente bem e vou mostrar a você cada um deles.

1. The Featured Box

É um termo utilizado pelo Derek Halpern do site Social Triggers para o grande campo de captura de email logo no topo da HOME do seu site.

Veja como a utilizo aqui no Viver de Blog:

Não é todo site que você conseguirá implementá-la com facilidade, mas nada que contratar um designer não resolva. No longo prazo, os custos serão invisíveis em comparação com os benefícios.

2. Sidebar

Outro lugar muito popular é a sidebar, a lateral do seu site.

Como ela é visível na HOME, nos artigos e nas páginas, ela tem grandes chances de capturar mais emails.

Lembre-se de destacá-la dos demais conteúdos da sidebar, como campo de pesquisa, redes sociais e banners.

Um campo de captura de emails na sidebar é essencial. Obrigatório. Se você não possui, coloque uma lá pra ONTEM.

[INFOGRÁFICO] 33 DICAS SOBRE WEBDESIGN E USABILIDADE QUE IRÃO ALAVANCAR SUAS CONVERSÕES

January 16, 2015Usabilidadedesign, usabilidadeFernando Madeira

Usabilidade e Conversão andam lado a lado.

Entretanto, poucos sites dão a devida atenção a experiência do usuário como forma de conseguir alavancar suas conversões.

Veja todos os detalhes sobre Usabilidade e Conversão no infográfico logo abaixo.

Eu irei compartilhar 33 dicas sobre design e usabilidade que irão transformar simples pesquisadores em compradores.

Veja algumas estatísticas abaixo sobre Usabilidade:

40% das pessoas abandonarão uma página da web se ela demorar mais que três segundos para carregar;
46% dos usuários móveis relataram ter dificuldade de interagir com uma página web, e 44% reclamaram que a navegação era difícil;
Apenas 55% das empresas estão atualmente realizando algum teste online de experiência do usuário.

Pensando na importância do assunto, o Viver de Blog produziu um rico infográfico com absolutamente tudo sobre Usabilidade e Conversão.

Clique na imagem abaixo para baixar uma versão em alta qualidade desse infográfico:

» Clique Aqui para baixar uma versão em Alta Resolução desse infográfico «

Coloque esse Infográfico no seu site (Copie e Cole o código HTML)

Fatos e Estatísticas para Tweetar:

(tweet) 40% das pessoas abandonarão uma página da web se ela demorar mais que três segundos para carregar.
(tweet) $1.1 trilhão das vendas do varejo em 2011 foram influenciadas pela web.
(tweet) 46% dos usuários móveis relataram ter dificuldade de interagir com uma página web, e44% reclamaram que a navegação era difícil.
(tweet) A taxa de rejeição (bounce rate) em um site pode até dobrar se ele demorar mais de 4 segundos para carregar e aumentar em até 150% se ele demorar mais de 8 segundos.
(tweet) Mais de 80% dos empresários consideram o aumento global da conversão com sendo de alta prioridade para seus programas de otimização de site.
(tweet) 78% dos clientes entrevistados afirmaram que sua companhia era extremamente ou muito empenhada em oferecer a melhor experiência online para o usuário.
(tweet) 48% dos usuários dizem que se eles visitam um site de negócios que não está funcionando bem no celular, eles tomam isso como uma indicação de que a companhia simplesmente não está se importando com o consumidor.
(tweet) 62% das companhias que projetam um site especificamente para celulares verificam um aumento nas suas vendas.
(tweet) Apenas 55% das empresas estão atualmente realizando algum teste online de experiência do usuário.
(tweet) 86,6% das pequenas e médias empresas citam websites como a sua tática de marketing mais importante.
(tweet) 90% das pessoas usam várias janelas de trabalho ao mesmo tempo, indicando que a grande maioria realiza multi-tarefas.

Você gostou desse Infográfico sobre Usabilidade e Conversão?

Espero que você tenha gostado das informações no infográfico e aplique no seu site e na sua empresa.

Se você gostou desse artigo e infográfico, por favor compartilhe com seus amigos.

Aproveite também para conhecer todos os infográficos já divulgados aqui no Viver de Blog.

E para receber mais infográficos como esse, basta se cadastrar na nossa lista de email para ser o primeiro a receber novas atualizações!

O QUE STEVE JOBS, APPLE E A MINHA AVÓ ME ENSINARAM SOBRE DESIGN, FOCO E SIMPLICIDADE

January 16, 2015Design, Usabilidadedesign, usabilidadeFernando Madeira

Férias, início de 2012. O período era o símbolo de curtição para muitos, mas não para ele.

Ele havia decidido passar boa parte de suas férias em busca de produzir um inédito material sobre investimentos aqui no Brasil.

Foram 3 meses de muito estudo, trabalho e madrugadas à dentro para dar vida a um projeto ambicioso, que ajudaria milhares de pessoas.

Porém, apesar desses resultados, ele mal sabia que um simples acontecimento iria marcar sua vida para sempre.

Tudo estava indo muito bem na produção de conteúdo desse material. Afinal, ele dominava o assunto e praticava exatamente o que ensinava.

Porém, o que ele não dominava, era transformar complicadas ideias em belos conceitos visuais.

Imagens e gráficos atraentes e fáceis de se entender e aplicar.

No mercado de investimentos, contaminado por clichês econômicos, ele sabia que uma linguagem mais simples, sem ser simplista, aliada a um forte design, seria o ingrediente perfeito para alcançar seu objetivo de trazer riqueza real a vida de várias pessoas.

Após longos meses, o conteúdo escrito estava pronto e era hora de pensar no ingrediente “X”, o design.

Uma procura por profissionais no mercado, mostrou a ele que um designer padrão estava disposto a cobrar em torno de R$ 1.000 a R$ 1.500 pelo valor de um eBook.

Ele era um estudante de 23 anos… E como todo estudante que se preze, ele ia todo dia de Mercedes para a faculdade.

Não o carro, mas o ônibus, em pé, junto com dezenas de pessoas em busca de uma oportunidade e um futuro melhor.

Ele não era um estagiário e ainda dependia da mesada dos pais para bancar seus custos.

Pagar um valor acima de R$ 1.000 em um projeto incerto, parecia, no mínimo, assustador para esse estudante.

Afinal, vindo de uma família de engenheiros e cursando economia, ele também pensava sobre o retorno sobre investimento que teria através desse eBook.

O futuro se mostrava confuso e indeciso… até que algo inesperado apareceu à sua frente.

Uma luz no fim do túnel

Em mais uma de suas pesquisas, ele descobriu um vídeo na internet sobre design para eBooks.

Era uma apresentação mostrando números, estatísticas e as tendências sobre o uso de eBooks, ao invés de livros tradicionais.

O design dessa apresentação e do eBook que a acompanhava, era tão fantástico que foi como se ele conseguisse enxergar, enfim, uma luz no fim do túnel para resolver seus problemas.

Ele viu e reviu o vídeo diversas vezes, maravilhado sobre como essa apresentação informava e cativava sua atenção, deixando nele um sorriso de gratidão no rosto após o término do vídeo.

Sem pensar duas vezes, ele decidiu entrar em contato com o designer que havia produzido todo esse material. “Quem sabe ele pudesse ser a pessoa ideal para o design do eBook?” – ele pensou.

Porém, ele não esperava que o investimento para contratar esse profissional era 5 vezes mais caroque os demais profissionais.

Se R$ 1.000 já era um valor considerável para esse estudante sem renda, imagina o valor de R$ 5.000?

Ele se perguntava a todo momento porque esse serviço era tão caro em comparação aos demais designers?

E por que não fazer tudo por conta própria e ainda economizar esse valor todo?

Então, na dúvida, ele procurou o conselho das pessoas mais próximas.

Todos deram a ele um único conselho:

Essa é sua primeira experiência com um produto digital. Não vale a pena investir todo esse valor em um algo incerto. Faça por você mesmo, veja o resultado e, na próxima, avalie se vale realmente a pena.

Não era de fato um conselho ruim… Ele estava bem inclinado a seguí-lo, mas a sua intuição gritava para ele seguir em frente e arriscar esse investimento com o designer.

Confiando no seu instinto, na ideia do projeto e no seu “espírito empreendedor”, ele resolveu contratar esse designer de extrema qualidade, mas que cobrava um valor 5x mais caro.

Embora não pareça, essa foi uma de suas decisões mais importantes na vida, que moldou a sua maneira de enxergar o mundo e o modo de traduzir suas habilidades em conhecimento e liberdade para seus leitores.

O caro, às vezes, sai muito barato

Após centenas de emails trocados e dezenas de reuniões via Skype (sem exageros), o eBook estava pronto para seu lançamento no mercado.

A mesma felicidade que ele teve ao terminar de assistir o vídeo sobre eBooks, ele teve ao ver seu eBook finalizado. O design estava impecável. Tão bom que, como dizia Steve Jobs, dava vontade de “lamber a tela”.

O sorriso orgulhoso no seu rosto indicava que ele havia feito a escolha correta.

Porém, analisando friamente, o dinheiro só havia sido investido, sem nenhuma garantia de retorno.

A decisão de investir todas as suas economias nesse projeto se pagariam com o tempo?

Somente no dia seguinte, ele teria a sua resposta através da demanda do público.

Para sua surpresa, o investimento não foi pago em 1 ano…

Nem 1 mês… nem mesmo 1 dia…

Mas em apenas algumas horas, com um faturamento superior a R$ 10.000.

Esse valor confirmou de uma vez por todas que o retorno sobre investimento havia sido positivo.

Porém, algo muito mais importante foi confirmado nesse dia.

Design não é simplesmente deixar algo mais bonito ou num pacote mais atraente.

Não fosse a preocupação com os elementos gráficos, a padronização das imagens, a tipografia, a página de vendas visualmente rica e fácil de usar, ele talvez não estivesse aqui contando essa história.

Sim, a história “dele” é, na verdade, a minha história pessoal.

O eBook dessa história é o meu eBook sobre investimentos, chamado “Alocação de Ativos”, que por algum tempo ocupou o primeiro lugar no ranking de vendas do Hotmart, com uma temperatura de 150º, a temperatura máxima de vendas, nunca antes alcançada nessa época.

Como é bom sermos o primeiro em um ranking, principalmente, quando você está ao lado de empreendedores digitais tão experientes, não é mesmo?

Então, o investimento havia sido pago. As minhas incontáveis horas de trabalho haviam sido pagas, mas as lições dessa experiências foram eternas, imensuráveis.

Eu aprendi diversas lições ao longo desses três meses de “férias” e que moldaram toda minha característica profissional dali para frente, como:

É muito melhor se comunicar com clareza do que exemplificar uma ideia através de termos e jargões complicados para mostrar que você é um expert naquilo que faz;
Empreender é saber tomar riscos para alçar vôos maiores. Afinal, o maior risco que você pode tomar na vida, é não tomar nenhum;
Design não é apenas como se mostra ser, ou como parece ser. Design é como funciona. Frase do Steve Jobs, que ficou tão clara no processo de criação da página de vendas do eBook;
Além do senso comum “às vezes, o barato sai caro”, o que é verdade, eu também aprendi que “às vezes, o caro sai barato”;
Em um mundo cada vez mais carente por atenção, aquele que souber adicionar estratégias visuais nos seus conteúdos, sairá quilometros à frente;
Qualidade supera quantidade. É muito melhor ter 1.000 super-fãs do que 100.000 leitores casuais. Evite as métricas da vaidade;
Menos é mais. Fale e escreva somente quando tiver algo muito interessante (e útil) para compartilhar.

Basta olhar como esse próprio blog design foi (e é) produzido. Você verá diversas características acima que levaram o Viver de Blog do zero a mais de 200.000 visitas mensais (e crescendo).

Como o design foi um dos pilares dessas lições aprendidas, eu quero compartilhar com você porque ele é tão essencial e convidar você à uma nova jornada.

Uma jornada por um mundo mais preocupado com qualidade, clareza e melhor design do que com empurrar produtos à qualquer custo goela abaixo das pessoas.

Continue lendo esse artigo para saber mais sobre:

Estudos científicos que mostram a importância do design em um site;
Por que 94% dos usuários que abandonam um site por um único motivo;
Menos é mais. Como menos opções podem resultar em mais vendas;
O conceito psicológico de “priming” e a importância da primeira impressão;
Como um redesign de um site, por si só, gerou 65% mais visitas e 133% mais emails capturados;
Como você pode ter um design parecido com o Viver de Blog (até melhor) sem pagar dezenas de milhares de reais.

POR QUE INVESTIR EM DESIGN?

Design é como criar o futuro. Ele encanta os consumidores. É o responsável por transformar ideias complexas em simples soluções.

Mais do que uma simples embalagem, um bom design torna a vida das pessoas mais simples, mais fácil.

Outro dia mesmo eu mostrei a minha avó, que já passa dos 80 anos de idade, o iPad. Eu não falei nada sobre como ele funcionava ou o que ela podia fazer com ele. Porém, para minha surpresa, ela sabia exatamente o que estava fazendo, mesmo que intuitivamente.

Ela ouvia música, assistia vídeos, olhava fotos e até tirava nossas próprias fotos. Acabamos essa fascinante experiência jogando Fruit Ninja, um contra o outro. Infelizmente, ela perdeu. Aí já seria demais né?

Como bom observador, eu conseguia ver como era fácil ela se familiarizar com uma ferramenta que ela nunca teve acesso (ela nunca acessou a internet ou mesmo teve um computador).

Naquele momento, após tanto me divertir e observar a minha avó mexendo no iPad, eu confirmei que design é muito mais do que algo bonito, design também é como uma ferramenta ou software funciona.

Design não é apenas o que parece e o que se sente. Design é como funciona – Steve Jobs

A partir dessa frase, o mercado da música seria revolucionado com a apresentação do novo iPod.

“Diga olá para o iPod. 1.000 músicas no seu bolso” (2001)

A Apple não inventou o tocador de mp3, mas o tornou parte diária de nossas vidas quando inovou no design do iPod.

O iPod era o mais bonito entre todos os tocadores de mp3 na época, há mais de 10 anos atrás.

Porém, como a frase acima diz, design não é apenas o que parece e o que se sente. Design é como funciona.

Então, como a Apple conseguiu ir além de um simples acabamento para criar fãs religiosos que desejavam fazer parte desse grupo inovador?

Se você já teve um iPod, irá se lembrar do click wheel. (veja imagem acima)

O click wheel é essa área circular abaixo da tela em que você passava o dedo para um lado ou para o outro, podendo aumentar/diminuir o volume da música, assim como navegar entre as opções mostradas na tela. Tudo com muita rapidez.

Ele é até hoje uma das maiores inovações em experiência do usuário da história.

A relação entre produto e consumidor através do iPod era platônica, pela simplicidade e facilidade de usá-lo.

Unindo um produto com ótima aparência à uma ótima experiência de usuário, a Apple estabelecia a maestria em design para seus produtos.

Esse é um exemplo de um produto físico, o iPod, que estabeleceu uma nova legião de fãs, graças a facilidade de usar um lindo mp3 que pudesse tocar 1.000 músicas e coubesse dentro do seu bolso.

Voltando ao nosso mundo digital, como o design pode quebrar ou alavancar um site?

Design, o fator número 1 que pode destruir a credibilidade do seu site

Local: Universidade de Nortúmbria (Newcaslte – UK).

Uma pesquisadora chamada Elizabeth Sillence e sua equipe conduziram um estudo (link) sobre os fatores que faziam usuários confiar ou desconfiar de um site, permanecendo ou saindo dele.

O estudo é bem simples. Elizabeth e sua equipe colocaram várias pessoas para visitar diversos sites na internet. Eles tinham como tarefa apenas responder se eles confiavam ou não confiavam nesses sites e o porquê.

O resultado foi surpreendente. Ao contrário do senso comum, o que faz um site não ser confiável não é seu conteúdo de má qualidade, mas sim seu design.

Mais surpreendente, foi descobrir que, a cada 100 respostas dizendo que não confiavam em um site, o motivo era 94 das vezes o mesmo: Design.

Portanto, não importa se seu conteúdo é uma obra-prima. Para um novo visitante, a primeira impressão que seu design transmite é tudo… ou nada.

Para piorar, estudos mostram que essa primeira impressão se dá muito rapidamente. Você tem apenas 8 segundos para que o visitante confie no seu site ou tudo estará perdido.

A psicologia explica esse conceito, que voltarei mais tarde nesse artigo para falar de “Priming” e como aumentar drasticamente suas chances de causar uma boa impressão com seu site.

O paradoxo das escolhas: Quando mais opções resultam em menos vendas

Você visita um site e se depara com os seguintes itens na sidebar:

Data e horário atual
Calendários de posts
Visitantes ao redor do mundo
Milhões de redes sociais
Infinitas categorias
Nuvens de tags
Blogs recomendados

Esses são apenas alguns parasitas que formam um enorme lixo, facilmente encontrado em sidebars de diversos blogs, principalmente iniciantes sobre marketing digital, que tentam vender tudo a todos, ocupando cada pixel de seu computador.

Porém, o que eles não sabem, ou não entendem, é que quanto mais opções você dá para o visitante do seu site, mais confuso ele ficará.

Digo isso por experiência própria e, claro, baseando-me em estudos renomados, como o da Dra. Sheena S. Iyengar para a universidade de Columbia, de nome “When Choice is Demotivating: Can One Desire Too Much of a Good Thing? ” (link).

O link o leva para aqueles PDFs longos e chatos de ler (infelizmente, é verdade). Para poupar o seu tempo, vou resumir o melhor desse trabalho aqui para você através de uma linguagem mais “humana”.

A Dra. Sheena S. Iyengar, montou um estande de degustação livre em um supermercado conhecido por sua extensa seleção de produtos, em dois sábados consecutivos.

No primeiro sábado, 24 sabores de geleia estavam disponíveis, e no outro sábado, apenas 6.

Agora, dê um palpite: Qual sábado conseguiu vender mais geleias?

Seguindo o senso comum de que quanto mais opções para o cliente melhor, você pensaria que o sábado com mais geleias vendeu mais.

Porém, não foi exatamente isso que aconteceu…

Quando 24 potes de geleia estavam disponíveis, 60% dos clientes pararam para um teste de degustação. Entretanto, apenas 3% daqueles que pararam, compraram algum pote de geleia.

Quando 6 potes de geleia estavam disponíveis, 40% dos clientes pararam para um teste de degustação e 30% compraram algum pote de geleia.

Supondo que 100.000 pessoas visitaram o supermercado em ambos os sábados teríamos os seguintes resultados:

1. Sábado com 24 potes de geleia:

60.000 pessoas pararam para degustar.
2.000 pessoas compraram pelo menos uma geleia.

2. Sábado com 6 potes de geleia

40.000 pessoas pararam para degustar.
12.000 pessoas compraram pelo menos uma geleia.

Os resultados são enormes. Mais de 10.000 pessoas compraram geleia em um sábado em relação ao outro. Um aumento de 500% nas vendas.

Moral da história: Menos é mais. Portanto, não transforme a homepage do seu site em uma coleção interminável de widgets, imagens e textos.

Caso contrário, eles terão o mesmo destino da coleção de quinquilharias que você guarda naquele quarto que ninguém visita na sua casa: A solidão.

Portanto, quanto mais elementos você colocar na sua homepage, mais opções você dará aos usuários, tornando-os mais confusos.

Como diz a frase:

Uma mente confusa não toma decisão alguma.

Você não quer que isso ocorra para o seu site, quer? Porém, como você pode resolver isso?

Acredito que a leitura desse artigo está cada vez mais mostrando a você como: Através de um bom design.

POR QUE BOM DESIGN SIMPLESMENTE FUNCIONA?

Sabemos que o processo de compra de um produto ou serviço está ligado a 3 fatores essenciais que antecedem essa compra. São eles:

Conhecer
Confiar
Gostar

A fórmula para vender mais é bem simples:

Conhecer + Confiar + Gostar = Vendas

Apesar de simples, essa fórmula é totalmente ignorada em um mundo obcecado por atenção, desejos próprios e ganância.

Falando em atenção… Você já reparou que a primeira impressão é extremamente poderosa tanto na vida como nos negócios?

Como vimos acima nesse artigo, 94% das pessoas tem uma impressão ruim de um website somente pelo seu design.

Primeiras impressões são tudo, porque são resultados de um conceito psicológico chamado de “Priming” em nossa memória implícita ou subconsciente, que estimula um resultado futuro.

Talvez o design desse site, o Viver de Blog, tenha causado uma boa impressão em você e, através desse conceito de “Priming”, você tenha sido estimulado a se cadastrar na lista de email para receber mais informações sobre marketing digital.

Esse caminho parece familiar para você?

Como a primeira impressão influencia toda interação futura, um bom design faz com você alcance 3 grandes objetivos:

Não causar uma má impressão em 94% das pessoas que poderiam deixar seu site;
Aumentar o efeito subconsciente do “Priming”, tornando seu trabalho muito mais fácil de manter o leitor no seu site;
Transformar Atenção em Intenção e ação.

Você já imaginou a quantidade de visitantes que você poderia ganhar (ou deixar de perder) somente por conta de um bom design?

Se você acredita que o principal fator para usuários deixarem um website, é um bom design, você está correto.

É o que estudos da universidade de Stanford, Columbia e Nortúmbria (Inglaterra) mostram. E minhas próprias experiências e de amigos também.

Estudo de Caso: Como o redesign de um site gerou 65% mais tráfego e 133% mais capturas de emails (em apenas um mês)

Você gostaria de:

Aumentar a captura de emails em 133%?
Aumentar as visitas em 65%?
Aumentar as páginas visitadas em 74%?
Aumentar o tempo do visitante no site (40 segundos a mais)?
Diminuir a taxa de rejeição (caiu 7%)?
Aumentar a qualidade dos comentários?

Quem não gostaria? Foram exatamente esses números que o site Quero Ficar Rico alcançou no seu primeiro mês após seu redesign, detalhados nessa entrevista que gravei com o Rafael, fundador do site.

Ao contrário do que você possa estar pensando, ele não produziu mais conteúdos nesse mês, muito menos colocou em prática novas estratégias de marketing.

Ah, mesmo antes do redesign, o blog já gerava mais de 100.000 visitas por mês e tinha uma lista acima de 30.000 emails.

Você imagina o que 133% mais emails na sua lista podem fazer diante de uma lista de 30.000 emails?

E 65% mais visitas, quando seu site já recebe mais de 100.000 visitas por mês?

Resultados expressivos para uma mudança relativamente simples.

O Rafael, apenas colocou “no ar” seu novo design, mesmo quando o anterior já era muito bom.

Se você notar no design do Quero Ficar Rico, verá boas semelhanças com o Viver de Blog:

O menu de navegação com poucos itens, ilustrados por ícones e o campo de pesquisa;
A sidebar na esquerda do blog ao invés da direita;
A captura de email logo acima dos artigos (com uma animação que atrai atenção);
Os formulários de email dentro dos artigos (no meio do conteúdo e no final);
Entre diversas outras funcionalidades…

E adivinha quem produziu o redesign do Quero Ficar Rico?

Se você respondeu o mesmo designer que produziu o Viver de Blog, você acertou.

Se você reconheceu que esse designer é o mesmo designer da minha história pessoal no início desse artigo sobre o eBook, você agora sabe como um bom design é fundamental para o sucesso de um site ou produto.

Esse designer é o Márcio Duarte, com mais de 15 anos de experiência nessa área e o profissional mais inteligente e atento aos detalhes com quem já trabalhei. (e olha que sou muito exigente com detalhes)

Sabe quando você pede para um designer ou uma pessoa fazer algo para você e ela faz um trabalho meia-boca?

O Márcio pratica exatamente o oposto. Mesmo já conhecendo e trabalhando com o Márcio há mais de 2 anos, ele nunca pára de me surpreender com sua incrível qualidade de trabalho.

Às vezes, chega a ser até estranho porque ele consegue adivinhar o processo de design que está na minha cabeça, mas que não consigo passar com clareza através de rabiscos, textos e ideias.

Agora, a pergunta que você deve estar se fazendo é como ter um designer como o Márcio ou umdesign como o Viver de Blog?

Um design que seja:

Responsivo
Otimizado para SEO
Esteticamente atraente
Baseado em conceitos universais de boas práticas de usabilidade
Fácil de usar e configurar
Integração nativa com capturas de email, compartilhamento social, avisos de atenção

E a lista só cresce, se incluirmos os benefícios como:

Maior retenção de novos visitantes no site
Maior retenção de leitores que já tenham visitado o site
Aumento do tempo de permanência dos leitores no site
Aumento da captura de emails para sua lista
Aumento do tráfego do site

E finalmente, aumento do faturamento do seu site.

Ao contrário do que você imagina, a resposta está muito mais próxima do que você pensa ou já tenha imaginado…

COMO VOCÊ PODE TER UM DESIGN COMO O VIVER DE BLOG (OU AINDA MELHOR)?

Como vimos nesse artigo, um bom design pode transformar um site, trazendo a ele mais credibilidade, mais leitores e até mais receitas.

A primeira impressão no seu site é muito importante para você desperdiça-la através de um design que não é exatamente o que seu leitor espera.

Sites como o Viver de Blog, o Quero Ficar Rico e demais sites que seguem essa linha de design, podem custar até mesmo R$ 10.000 (ou mais) nas “mãos” de designers muito experientes, como o Márcio.

Porém, eu quero compartilhar com você o início de um projeto que há tempos está guardado a 7 chaves e, hoje, começa a se tornar realidade.

Após receber centenas (sem exageros) de pedidos do tipo:

“Oi Henrique, adoro o design do Viver de Blog. Como faço para ter um design igual ao seu?”

ou…

“Oi Henrique, como faço para conseguir falar com seu designer?”

Eu poderei oferecer a você (muito em breve) a melhor resposta que você poderia esperar, e sem precisar pagar R$ 10.000 ou mais para isso.

Por enquanto, o máximo que posso compartilhar é esse link aqui para você ter acesso mais rápido e direto a todas as novidades que eu e o Márcio estamos preparando para você.

Clique no link e veja como uma página do Márcio já é um motivo para ficar de queixo caído.

Ah, e para vocês que participaram da pesquisa sobre temas para wordpress (muito obrigado!) e adoraram o design dela: Você sabe onde ela foi produzida?

No Google Docs.

Sim, o Márcio, através de um CSS customizado, conseguiu transformar o design chato e padrão do Google Docs nesse fabuloso design que você viu no link acima.

Eu avisei a você. Ele nunca pára de me surpreender, mesmo após anos trabalhando juntos.

Eu gostaria de já poder compartilhar com você todos os detalhes dessa grande novidade, mas ainda estamos ajustando os últimos detalhes. Afinal, um bom design é sobre os mínimos detalhes, lembra?

O que posso adiantar é que, além de uma qualidade em design, você também poderá contar com um grande foco em conversão.

Hoje em dia, um site não pode ser somente bonito. Ele também precisa ser efetivo e atingir os objetivos do seu dono.

Por enquanto, quero convidar você para embarcar conosco nessa nova jornada, deixando para trás a era assustadora do design medíocre e partindo para uma nova era.

Uma nova era regada pela maestria do design, e os benefícios que ele é capaz de nos oferecer.

Estamos juntos nessa jornada, combinado?

Visite essa página aqui e saiba mais informações sobre esse projeto. (e aproveite para ver a beleza de página que o eu e o Márcio produzimos – O design incrível é mérito todo dele)

Até o próximo artigo!

INFOGRÁFICO: OS MELHORES HORÁRIOS PARA PUBLICAR NAS REDES SOCIAIS

January 16, 2015Marketing Digitalfacebook, linkedin, marketing digital, twitterFernando Madeira

Qual é o melhor horário para postar no Facebook?

Qual é o melhor horário para publicar uma foto no Instagram?

Ou até mesmo quais são os piores horários para publicar no Google+, LinkedIn e Twitter…

Se você já se perguntou sobre os melhores (e piores) horários para postar nas redes sociais, esse infográfico irá responder todas as suas dúvidas.

Veja todos os detalhes sobre Os Melhores Horários para Postar nas Redes Sociais no infográfico logo abaixo.

Eu irei compartilhar várias estatísticas e dicas sobre como otimizar suas publicações para atingir o máximo de usuários nas redes sociais possível.

Clique na imagem abaixo para baixar uma versão em alta qualidade desse infográfico:

» Clique Aqui para baixar uma versão em Alta Resolução desse infográfico «

INFOGRÁFICO: A FREQUÊNCIA “PERFEITA” PARA POSTAR NAS REDES SOCIAIS

January 16, 2015Marketing Digitalfacebook, marketing digital, redes sociaisFernando Madeira

Quantas vezes postar nas redes sociais? Descubra a frequência “perfeita” para postar no Facebook, Twitter, Google+, Instagram e muito mais…

Sabe aquela comida que você adora? Então, imagina ter que comê-la todos os dias, em todas as refeições. Por mais que você ame determinado prato, uma hora você vai enjoar.

Não ficou convencido? Acha impossível enjoar do strogonoff da sua mãe ou de comida japonesa? Então pense naquela música que era ótima, mas tocou tantas vezes em tantos lugares possíveis, que acabou se tornando maçante.

O mesmo acontece com um planejamento digital. Por mais que você adore determinado assunto ou marca, se isso começa a aparecer demais na sua timeline, pesquisas e caixa de entrada, você simplesmente enjoa.

Desta forma, assim como comer aquele prato maravilhoso em uma ocasião especial faz dele ainda melhor, as marcas e geradores de conteúdo devem dosar sua frequência nas redes sociais.

Saber quantas vezes postar é a linha tênue entre ser chato e maçante ou relevante e memorável.

Veja o infográfico que o Viver de Blog preparou para você saber a frequência ótima para você postar nas redes sociais.

Você saberá as respostas para perguntas do dia-a-dia, como:

Com que frequência devo postar no blog?
Quantas vezes posso postar no Facebook?
Quantas vezes posso postar no Twitter
Quantas vezes posso postar no Instagram por dia?

Clique na imagem abaixo para baixar uma versão em alta qualidade desse infográfico:

» Clique Aqui para baixar uma versão em Alta Resolução desse infográfico «

O que é SEO?

January 16, 2015Marketing Digitalgoogle, mecanismos de busca, SEOFernando Madeira

Você já parou para pensar em qual é o segredo de alguns blogs ou sites campeões de acesso? Pois saiba que a explicação pode ser mais simples do que você imagina e que os bons resultados e grandes números de acesso deles não acontecem por acaso. É cada mais dia comum na web o trabalho de SEO – Search Engine Optimization.

Traduzindo, trata-se do trabalho de otimizar uma página web, ou mesmo um site inteiro, de modo que ele fique mais “amigável” ou acessível aos sites de buscas. O objetivo das técnicas de SEO é melhorar o posicionamento de uma página nos mecanismos de busca, aumentando a probabilidade de crescimento do número de acessos.

Qualquer um pode aplicar técnicas de SEO em uma página?

Em tese qualquer um pode tornar suas páginas mais acessíveis para os sites de buscas. No entanto, o SEO se baseia em uma série de possibilidades e não é pelo simples fato de você aplicar algumas regras básicas na hora de postar seu conteúdo que seu site aumentará o número de visitantes da noite para o dia.

A maneira como você é visto nos buscadores é um trabalho de SEO
Não é a toa que o número de profissionais que se especializam nesta área cresce a cada dia. Mas você pode fazer a sua parte dando uma mãozinha para os buscadores, entendendo um pouco como eles funcionam e dando a eles a oportunidade de ser encontrado com mais facilidade.

O primeiro passo: a edição das meta tags

Você sabe o que são meta tags? Elas nada mais são do que um conjunto de informações que são colocadas no código HTML da sua página para passar informações aos robôs dos mecanismo de buscas a respeito do seu conteúdo. É como se elas sintetizassem, em poucas linhas, tudo o que usuário irá encontrar naquele endereço URL.

Cabeçalho básico de edição de meta tags
Cada mecanismo de busca tem uma maneira particular de checar e priorizar essas informações. Por isso é importante dar atenção a esse aspecto. Se você tem algum conhecimento de HTML pode editar as informações do cabeçalho da página. Aspectos como título, descrição e palavras-chaves são alguns dos itens que você deve levar em consideração. Se você utiliza algum sistema de blogs, como Blogger ou WordPress, pode encontrar alguns plugins que permitem editar esse tipo de informação sem precisar ter contato direto com o código-fonte.

Você pode conhecer um pouco mais sobre edição lendo o “Search Engine Optimization Starter Guide”, um guia para iniciantes disponibilizado pelo Google. O guia está em .PDF e é disponibilizado também em português.

Mais do que edição de código, SEO é conteúdo

De nada adianta você se preocupar apenas com o código das páginas se o seu conteúdo não é relevante, não é original ou é repleto de erros de português. O primeiro passo para atrair visitantes para o seu site é escrever com freqüência, de preferência um conteúdo inédito e original sobre um assunto. Sites e blogs que apenas copiam informação alheia além de agir de maneira antiética, também acabam por se tornar irrelevantes nos mecanismos de busca.

Conteúdo de qualidade é a melhor maneira de se destacar na web
Lembra das aulas de redação, em que você aprendeu que na estrutura de um texto a informação mais relevante aparece por primeiro e, em seguida você apresenta o desenvolvimento e, por último a conclusão? Aqui a regra vale da mesma maneira. O texto que é apresentado por primeiro tem peso maior que o que vem na sequência. Por isso criar um texto com uma estrutura coesa, e num linguajar correto, ainda é a melhor maneira de cativar a audiência dos seus visitantes.

O que é a usabilidade

January 16, 2015UsabilidadeusabilidadeFernando Madeira

O que é a usabilidade? Porquê e quando investir em usabilidade? Como melhorar o nível de usabilidade do seu produto, aplicação ou website? Porque se deve preocupar com isso? Este artigo pretende dar respostas a estas questões.

O que significa usabilidade?

A usabilidade é um atributo de qualidade dos produtos que permite aferir se uma interface com o utilizador é fácil de utilizar. A palavra “usabilidade” também se emprega para referir o conjunto de métodos destinados a melhorar a usabilidade dos produtos.

A usabilidade é definida em 5 dimensões:

Aprendizagem: Quão fácil é para os utilizadores realizarem tarefas básicas no primeiro contacto que têm com a interface?
Eficiência: Depois dos utilizadores se tornarem experientes na utilização da interface, quão rápido conseguem realizar as tarefas?
Memorização: Depois de um longo período de ausência, quão facilmente conseguem os utilizadores restabelecer o seu nível de proficiência?
Robustez: Quantos erros cometem os utilizadores, quão severos são esses erros, e quão facilmente conseguem recuperar dos erros?
Satisfação: Quão agradável é a utilização do sistema?

Existem outros atributos de qualidade igualmente importantes. Um desses atributo-chave é a utilidade, que se refere à eficácia do design. O sistema permite fazer o que o utilizador pretende? A usabilidade e a utilidade são as duas faces da mesma moeda e têm igual importância. Interessa pouco que algo seja fácil de utilizar se não permite fazer o que se pretende. É igualmente inútil que um sistema permita, hipoteticamente, fazer o que se pretende, mas que não consigamos atingir esse objectivo porque a interface é demasiado difícil de utilizar. A usabilidade e a utilidade podem ser estudadas através das mesmas metodologias.

Porquê investir em usabilidade?

Na web, a usabilidade é um factor crucial de sobrevivência. Se um website é difícil de utilizar, as pessoas desistem. Se a homepage não apresenta, de forma clara, o que a empresa tem para oferecer e o que é que os utilizadores podem fazer no site, as pessoas desistem. Se os utilizadores se perdem num website, desistem. Se a informação contida num website é de difícil leitura e não responde às questões-chave dos utilizadores, eles desistem. Detecta aqui um padrão? É irrealista assumir que os utilizadores vão ler manuais ou perder tempo a tentar perceber como utilizar um website. Existem numerosas alternativas online; desistir e abandonar o site é a primeira defesa que os utilizadores têm quando encontram dificuldades de sua utilização.

A primeira lei do comércio electrónico diz que, se o utilizador não consegue encontraro produto, então também não consegue comprar o produto.

No que diz respeito às intranets, a usabilidade é sobretudo direccionada para a produtividade dos colaboradores. O tempo que os utilizadores gastam quando estão perdidos na intranet, ou a tentar interpretar interfaces complexas, é dinheiro que está a desperdiçar ao pagar-lhes o salário para não serem produtivos.

A experiência aponta para um custo com a usabilidade a rondar os 10% do orçamento destinado ao design do sistema. Em média, este custo permite mais do que duplicar as métricas de qualidade de um website e praticamente duplicar as métricas de qualidade em intranets. No caso do software aplicacional e produtos físicos, o ganho de introduzir a usabilidade no processo de design é tipicamente inferior – ainda que substancial.

Em projectos internos, considere a duplicação do investimento em usabilidade correspondente à redução para metade dos custos em formação e o aumento para o dobro das transações que os colaboradores realizam por hora. Em projectos para o público em geral, pense na duplicação das vendas, do número de utilizadores subscritores, do número de leads, ou na duplicação de outras métricas tipicamente utilizadas na medição do sucesso de projectos.

A primeira lei do e-commerce é que caso os utilizadores não consigam encontrar o produto, também não o podem comprar.

Como melhorar a usabilidade?

Existem numerosas metodologias para estudar a usabilidade de um sistema, mas podemos afirmar que a mais simples e útil é a realização de testes com utilizadores, que podemos dividir em 3 etapas:

Recrute utilizadores representativosdo público-alvo, tal como clientes do seu site de comércio electrónico, ou colaboradores da sua intranet (neste último caso, devem trabalhar fora do departamento que desenha e desenvolve a intranet);
Solicite aos utilizadores que executemtarefas representativas no sistema;
Observe o utilizador, tomando nota dos seus sucessos e das suas dificuldades na utilização do sistema. Não interfira e ajude o utilizador a verbalizar a sua experiência.

É importante realizar os testes com um utilizador de cada vez, e que ele tente resolver autonomamente os problemas com que se pode deparar durante o teste. No instante em que você interferir, ajudando o utilizador ou chamando a atenção do utilizador para algum aspecto da interface, terá contaminado os resultados do teste.

Com 5 utilizadores é tipicamente possível identificar os problemas de usabilidade mais importantes. E é geralmente mais útil e proveitoso realizar vários testes rápidos, em pequena escala, revendo o design e corrigindo os problemas identificados, iterativamente, do que realizar um único teste complexo e dispendioso. O design iterativo é a melhor forma de atingir um bom nível de usabilidade e de qualidade de experiência de utilização. Quantos mais testes rápidos com utilizadores realizar, mais ideias irá obter sobre como melhorar a interface.

Testes com utilizadores e focus groups são coisas bem diferentes. Focus groups são um método pouco eficaz para avaliar a usabilidade. Focus groups têm um papel importante em Marketing Research, mas para avaliar a usabilidade de um sistema, você deve observar de perto os utilizadores a interagirem com o sistema. Ouvir, simplesmente, o que os utilizadores têm a dizer (a sua opinião) pode desorientar mais do que ajudar: é preciso observá-los a realizarem tarefas na prática.

Quando investir em usabilidade?

A usabilidade tem um papel importante em várias fases do processo de design. É por isso que se defende a realização de múltiplas sessões de testes rápidos e de baixo custo. Aqui vão algumas pistas:

Antes de iniciar um novo design, teste o design anterior para identificar os pontos positivos (que deve manter) e os aspectos que dificultam a vida aos utilizadores.
Teste soluções da concorrência. É uma forma simples e acessível de obter dados valiosos sobre alternativas de design em sistemas com funcionalidades semelhantes às do seu produto (no caso das intranets, como é óbvio, torma-se mais difícil testar as soluções da concorrência).
Vá ao terreno e realize um estudo de campo(field study) para aprender como é que os utilizadores agem e resolvem os seus problemas no seu ambiente natural.
Desenhe protótipos em papel da interface (uma ou mais alternativas), e teste-os com utilizadores. Não invista muito esforço na qualidade gráfica dos protótipos iniciais, já que terá que modificar muitas opções de design depois dos testes.
Refina gradualmente a interface, em várias iterações, com base nas ideias recolhidas nos testes, partindo de protótipos em papel de baixa fidelidade gráfica até chegar ao design visual final da aplicação. Teste cada iteração.
Inspecione as opções de design à luz das guidelines de usabilidade estabelecidas.
Uma vez implementado, teste o sistema novamente. A experiência mostra que surgem sempre problemas subtis de usabilidade durante a fase de implementação.

Não adie a realização dos testes com utilizadores até ter o sistema todo implementado. Se o fizer, irá perceber que a grande maioria dos problemas críticos de usabilidade detectados nos testes já não poderão ser corrigidos. Habitualmente, muitos destes problemas são estruturais, e a sua resolução costuma implicar alterações ao nível da arquitectura do sistema.

Onde realizar os testes?

Se realiza pelo menos um teste com utilizadores por semana, compensa investir num laboratório de usabilidade. Para a maioria das empresas, contudo, é mais do que suficiente realizar os testes em salas normais, desde que garanta um ambiente isento de ruído e distrações.

A única forma de conseguir um nível elevado de qualidade na experiência de utilização do seu produto, aplicação ou website é através de testes com utilizadores logo nas primeiras fases do processo de design, e em cada etapa desse processo. O importante é que consiga recrutar os utilizadores, que os coloque frente ao sistema, e que os observe a realizarem tarefas. Um bloco de notas é o único equipamento de que precisa.

Texto original de Jakob Nielsen em http://www.useit.com/alertbox/20030825.html.

Usabilidade na web

January 16, 2015UsabilidadeusabilidadeFernando Madeira

Neste artigo, você aprenderá a utilizar corretamente as regras básicas de usabilidade na web. Tornando o site eficiente e agradável aos diversos tipos de usuários.

Leia mais em: Usabilidade na web http://www.devmedia.com.br/usabilidade-na-web/24737#ixzz3OzXiiHKJ

Usabilidade é o método que visa facilitar a utilização de uma interface pelo usuário sem perder a interação de suas funcionalidades com o sistema. Refere-se ao grau no qual o usuário consegue realizar uma tarefa. É tornar “algo” utilizável e funcional, mais especificamente, refere-se à rapidez com que os usuários podem aprender a usar alguma coisa e sua eficiência ao utilizá-la, sua facilidade de aprendizado – facilidade de relembrar.

A usabilidade de um site ou software nada mais é do que implementação de recursos focando o usuário final.

Vocês podem estar se perguntando por que é importante existir usabilidade na web, e a resposta para esta pergunta é simples. Se você deseja que o usuário realize algo quando visitar seu site, você deve com certeza se preocupar com a usabilidade. Pois atualmente, as pessoas esperam muito dos web sites e cada vez menos aceitam um projeto ruim.

Ou seja, a má utilização da usabilidade resultará em clientes e usuários insatisfeitos e perdas de negócios.

Há a princípio sete regras básicas que devem ser seguidas, estas regras colaboram para a facilidade de aprendizado, pois o usuário consegue explorar rapidamente o sistema e realizar suas tarefas.

Clareza na arquitetura da informação:É essencial que o usuário consiga distinguir o que é prioritário e o que é secundário no site – para isso deve-se ter um bom arranjo da informação, pois os usuários podem ter dificuldades em encontrar o que procuram, e, portanto devem ser ajudados. Deve-se fornecer um senso de como a informação está estruturada e localizada. Um bom exemplo é o mapa do site.

Facilidade de navegação: O usuário deveria conseguir acessar a informação desejada no máximo em três cliques.

Simplicidade: Quem navega quer encontrar o mais rapidamente possível o objetivo da busca. Deve ser evitado qualquer exagero, dando ao usuário paz e tranquilidade para que possa analisar a informação.

A relevância do conteúdo: Sempre que questionados sobre sites, usuários se referem à qualidade e relevância do conteúdo. – um bom texto para essa mídia, o mais conciso e objetivo possível, não ser promocional ou publicitário. Os leitores online imprimem textos (eles necessitam de paginas bem curtas e informações secundaria deixada para paginas de suporte).

Manter a consistência: Quando as coisas acontecem sempre do mesmo jeito, os usuários não precisam se preocupar a respeito do que irá acontecer. Um web site deve ser gerenciado como um projeto único de interface com o usuário.

Tempo suportável: O tempo de cargas das paginas deve ser curto – 10 segundos é o máximo de tempo antes que as pessoas percam o interesse. (na web os usuários já tem uma baixa expectativa limite pode aumentar para 15 segundos).

Foco nos usuários: É o “sair do caminho”, afim de que o usuário possa fazer o que quer da maneira mais rápida possível.

Seguidas estas regras deve-se, antes de colocar seu site no ar, realizar sucessivos ciclos de análise, concepção e testes, com o objetivo de avaliar a qualidade das interações e levar em conta os resultados destas para a construção de novas versões das interfaces. O teste de usuário contribui para que se possa analisar o comportamento destes perante o site, observando assim suas virtudes e seus pontos fracos.

Se essas regras forem implementadas desde cedo, no desenvolvimento, essa estratégia pode reduzir o risco de falhas conceituais do projeto garantindo que, a cada ciclo, o sistema responda cada vez melhor às expectativas e necessidades dos usuários em suas tarefas.

Neste artigo expliquei de forma básica e rápida a necessidade da usabilidade na web. Espero que vocês tenham gostado e até a próxima.

REFERÊNCIAS BIBLIOGRÁFICAS

NIELSEN, Jakob. LORANGER, Hoa. Projetando Websites. Traduzido por Edson Furmankiewicz & Carlos Schafranski. Rio de Janeiro: Campus, 2006. Tradução de: Prioritizing web usability.

Contents

Building a Feature with Continuous Integration

Practices of Continuous Integration

Maintain a Single Source Repository.

Automate the Build

Make Your Build Self-Testing

Everyone Commits To the Mainline Every Day

Every Commit Should Build the Mainline on an Integration Machine

Fix Broken Builds Immediately

Keep the Build Fast

Test in a Clone of the Production Environment

Make it Easy for Anyone to Get the Latest Executable

Everyone can see what’s happening

Automate Deployment

Benefits of Continuous Integration

Introducing Continuous Integration

Final Thoughts

Further Reading

For articles on similar topics…

Acknowledgments

Significant Revisions

EVOLUÇÃO DOS EMAILS: CRIANDO UM ATIVO PARA O VIVER DE BLOG

A ESTRATÉGIA DE PRÉ-LANÇAMENTO: CRIANDO UMA LISTA ANTES MESMO DO BLOG NASCER

DESIGN: OTIMIZANDO CONVERSÕES (E OS NÚMEROS POR TRÁS DOS 3.174 EMAILS)

1. The Featured Box (53,11%)

2. Na Página “Sobre” (15,1%)

3. Sidebar (13,83%)

4. No topo de cada artigo (10,76%)

FIQUE ATUALIZADO!

Apresentando: Os resultados detalhados:

CONCLUSÃO – RECAPITULANDO

EMAIL MARKETING: OU VOCÊ PRECISA DELE, OU VOCÊ PRECISA DELE

Infográficos sobre Email Marketing

Digg, Orkut e a Morte das Redes Sociais

Você NÃO é o dono de sua página no Facebook, Twitter e qualquer rede social

QUAL É O MELHOR SOFTWARE PARA EMAIL MARKETING?

MailChimp

COMO TURBINAR SUA LISTA DE EMAILS: OS 10 LOCAIS ESTRATÉGICOS PARA VOCÊ CAPTURAR MUITO MAIS EMAILS

1. The Featured Box

2. Sidebar

Fatos e Estatísticas para Tweetar:

Você gostou desse Infográfico sobre Usabilidade e Conversão?

Uma luz no fim do túnel

O caro, às vezes, sai muito barato

POR QUE INVESTIR EM DESIGN?

Design, o fator número 1 que pode destruir a credibilidade do seu site

O paradoxo das escolhas: Quando mais opções resultam em menos vendas

POR QUE BOM DESIGN SIMPLESMENTE FUNCIONA?

Estudo de Caso: Como o redesign de um site gerou 65% mais tráfego e 133% mais capturas de emails (em apenas um mês)

COMO VOCÊ PODE TER UM DESIGN COMO O VIVER DE BLOG (OU AINDA MELHOR)?

FIQUE ATUALIZADO!

Sobre o autor

Qualquer um pode aplicar técnicas de SEO em uma página?

O primeiro passo: a edição das meta tags

Mais do que edição de código, SEO é conteúdo

O que significa usabilidade?

Porquê investir em usabilidade?

Como melhorar a usabilidade?

Quando investir em usabilidade?

Onde realizar os testes?