Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 14 2014


10 Online Applications To Help With File Management

Managing file is a necessity of today’s world because we have to deal with the great amount of different types of files on a daily basis – be is documents, images, photos, multimedia, etc. therefore, it is important to have a system where you can manage all of your files without any hassle.

Today, the communication and business processes demand the files to be rapidly shared, edited and created. People all over the world can now edit of view the accessible files regardless of their PC specifications and internet speed. This circumstance gives rise to the use of online services rather than desktop applications. Online entrepreneurs mostly use online services to manage their work files so that they can access them wherever they go.

eXtplorer -PHP and JavaScript based File Manager

eXtplorer is a web-based File Manager. You can use it to, browse directories & files on the server and, edit, copy, move, delete files, search, upload and download files, create and extract archives,


Pydio allows you to instantly turn any server into a powerful file sharing platform.


Share files with your clients or staff on your web site. Enable your users to securely access, upload and organize documents from anywhere with only a web browser. Store your confidential files on your own server and have full control over them.


Install CKFinder to increase daily website content management productivity. Easily upload and download multiple files. All users will find the interface intuitive and simple to use. You will only regret not having installed CKFinder on your website earlier.


Full featured PHP web based file manager with an easy to use ajax user interface. Upload and download large files for easy sharing.


Here’s what activeCollab can offer to help you manage your projects more effectively: Organized projects and task management, Centralized and open communication, Simple and easy way to track time and expenses, Billing your clients for the work you’ve done.


Give your team one place to share, find, and collaborate on information they need to get work done. Give your team Confluence. No email. No meetings. No problem.


Producteev is the leading social task management solution for teams. It’s helped thousands of teams get work done faster and more effectively.

Central Desktop

web based collaboration software for business teams to share information and collaborate on projects.


Teambox is a collaboration platform for task management, file sharing and communications.

November 13 2013


9 Useful Time Zone Converters For Computer & Mobile Users

Here we have compiled a list of 9 best time zone converters for your desktops and mobiles as well. With these time zone converters, you can easily stay connected with your internet contacts at their local times and can also watch live shows, matches and other events on your PC. All of this because you know at what time your show starts locally.

Sometimes, time difference can be a big headache especially if you have a meeting or discussion with someone with totally different time zone like GMT, PST, and PDT and so on. With these time zone converters that you can use on your mobiles and on your PC, you can easily manage your global appointment and also these time zone converters help you identify the time before you make a call to someone with different time zone.

World Time Buddy

Effortlessly convert between multiple time zones, plan and schedule conference calls, online webinars and international meetings.


World Time Zone Map and Converter.


This app can convert time from any timezone into your local time.


TimePal is a great aid to keep around when you just aren’t sure about the time.

Hours Keeper

Hours Keeper is a well designed application that you can use to easily track your hours worked and calculate your earnings.

TimeZone Converter

Simply Convert Date & Time from one Time Zone to Other Time Zone.Supports several time zones around the world.One Screen Application makes it very easy to use.Choose your Date and time and select the Source and destination Time Zones and simply click to convert, it will show you the converted time for the destination time zone.

Time Zone Converter

Looks for the local location of the user to compare with other time zones.

Timezone Converter

Converts a date/time from one time-zone to another. This application is great for scheduling international trips as well as convenient times for overseas conference calls, webinars and phonecalls to friends and relatives.

Time Zone Converter By TheTimeNow

Use our Time Zone Converter to find the time difference between two cities or two time zones around the world.

Sponsored post
Reposted byLegendaryy Legendaryy

November 06 2013


Why the Long-Table Approach Leads to Better Designs

The best startups today understand that great design is a team effort.

We need to deliver a seamless design and brand experience throughout all the things our customers see and touch.

And that’s no easy task when we silo our designers into teams like Marketing and Product Development.

At my company, Zendesk, we’ve adopted a long-table approach where the entire design team works at a single communal table.

Source: Ildar Sagdejev

This means we’ve eliminated silos within our designers. Every designer in our long-table:

  • Has influence
  • Works collaboratively with others
  • Can take on cross-functional responsibilities

What we’ve realized is that the long-table approach also leads to more productive — and happier — designers.

Here are five reasons why the long-table approach has worked for us, and why it might work for you too.

It’s Easier to See What Everyone is Doing

As startups grow, it’s harder for people to know what everyone else is doing at any given point in time.

Designers often have to rely on spreadsheets or project management apps to keep tabs on other design-related projects.

Important updates from one group of designers never seem to make it to other groups that could have a positive influence on product and brand developments.

With the long-table approach, a designer just has to look across the table to see what someone else is up to. For example, what an early prototype of a web page redesign is going to look like.

More Opportunities to Grow

In a typical company, designers often get pigeonholed into certain roles. Also, when you’re doing the same thing, day in and day out, it’s easy to get bored and fall into a creative rut.

By sharing the same space with other creative professionals, you’re automatically exposed to different facets of Design, and there are more opportunities to work on different types of projects.

It’s important to note here that while designers should be provided the opportunity to dabble in other areas, they should still have ownership over specific areas within the product and the company. This ensures that people are not merely "spot cleaning" for others.

Better Collaboration and Real-Time Feedback

When you’re all working around the same table, you can get real-time feedback from your peers.

The long-table approach also gives designers the ability to have a diverse source of input. A designer can get feedback from other designers who might have a different specialization or viewpoint.

In addition, the spontaneous back-and-forth collaboration between designers heightens everyone’s game.

Easier Path to Consistency

It’s easier to reach that holy grail of design and brand consistency when everyone is in the same physical space and can look over each other’s shoulders.

Last year, we undertook a major product overhaul. This task was significantly easier for everyone involved since the entire design team was working in the same space and each individual could see how other branches of the product were being developed.

Better Use of Individual Strengths

With design housed under one space, leaders can easily identify individual skills and allocate resources in more strategic ways.

They can, for example, adapt to people’s strengths and interests and form creative work pairings that would not have been obvious if designers weren’t working together in a single collaborative space.

Final Thoughts

When a startup commits to design-driven innovation, it doesn’t just mean paying top rate for the best designers. More importantly, we’ve also got to instill the right culture and environment that allows Design to thrive.

At the core of the long-table approach is a simple premise: Design is never tangential. Design is central to a company’s identity and all the things it does.

Related Content

About the Author

Toke Nygaard is the Chief Creative Officer at Zendesk driving the company’s design-centric approach to both brand and customer experience. Connect with them on Twitter @Zendesk.

The post Why the Long-Table Approach Leads to Better Designs appeared first on Six Revisions.

August 07 2013


Manage Your Web Design Projects Better with an “Action Register”

Do you find that many of your web design projects start with great energy and clarity, only to slow down and get hairy a few weeks in?

I will discuss the typical problems that arise in web design projects, common solutions many of us have tried, and what actually worked for my company after 8 years of business: the Action Register.

What is the Action Register?

The Action Register is a spreadsheet that my web design company uses.

This simple spreadsheet is a listing of tasks that need to be done to complete a web design project.

For each task, the Action Register spreadsheet tells you:

  • What the task is
  • Who is responsible for completing the task?
  • When will the task be done?
  • How many hours are required to finish the task?
  • How much will the task cost to complete?
  • What is the status of the task?

You can download a template of the our Action Register spreadsheet here.

In my web design agency, we use the Action Register for clients down the street and across the planet.

It has kept our web design projects running smoothly, even when unexpected things happen.

Before you decide to use the Action Register, you probably want to learn about it first.

So, allow me to go over how the Action Register is going to save you time, money, and drama.

We will look at how the Action Register helps us prevent common web design project problems. Then we’ll pull it all together by showing you a simple process you can use to manage project execution and client meetings.

What the Action Register Solves

Projects depend on people taking actions in order to move the project forward.

  • The client may need to give images, text, answers, and task approvals
  • The developer may need to learn about a new web technology or create a JavaScript library for custom website features
  • The designer might need to create website wireframes

When someone doesn’t do what they’re suppose to do on time, it can affect other project tasks, causing the whole project to stall.

We want to avoid that. As quickly as possible, we want to complete the project, have the client benefit from what we built, and get paid.

A regular web design project bottleneck is when the designer or developer is waiting on the client to provide certain things in order for his work to proceed.

Usually, clients are pretty excited to start the project at the kick-off meeting. It’s the weeks after the meeting that things tend to slow down or even stop.

Why? Did the client not understand what they needed to do? Not usually.

Clients get busy, and their day gets filled up quickly, just like ours.

A similar situation is when you’re working with a subcontractor who doesn’t take action on time. No one wants to be late, but it does happen.

What Have We Tried Before?

At my company, we’ve tried a number of things to try and solve the issue of projects stalling because of the lack of action.

These things didn’t work well by themselves:

  • Adding a clause on commitment/accountability to our standard project contracts. This usually only serves to "scare" new clients, but it doesn’t really truly motivate them to take action.
  • Reminder emails and phone calls. It takes time to remind yourself to remind other people. On top of that, it’s just not a call or email that people like to get or send.
  • Waiting for action. Waiting for the client to provide what you need without being in sync on when that was going to be, we’ve discovered, doesn’t work.

Greater Accountability

It’s one thing to verbally agree to do something at some date, but to have your name on a task with a clear deadline you’ve agreed to, is completely different — it motivates people tremendously to get the task done.

Everyone wants to save face and look good. We might as well work with human nature rather than against it.

Improve Client Meetings

Having a kick-off meeting that goes through the Action Register gets you and your client in sync from the get-go.

Related content: Read about how to get your web development projects off to a good start if you want to learn about kick-off meetings.

Come to your kick-off meeting with the tasks in the Action Register filled out as much as you can.

If you and the client have already agreed on a target completion date for the project, make a task for "Launch" or whatever the final task is, and assign it that date. Then, work your way backwards through the necessary tasks needed to get the project to this point.

Doing this with the client will not only show them that you care about the success of the project and about serving them well, but if they are part of this process, they will be more likely to buy into the website production plan and take ownership of the tasks they need to fulfill in order to complete the project.

Through this simple process, you may realize that there are a few other tasks that must be done in order to really complete the project. Now is the best time to identify those tasks and assign them to whomever should do them.

Get What You Need from Your Clients

Should you use the Action Register to list what you need from the client?


At my web design company, we put the items we need from the client into the Action Register as tasks that are assigned to the client.

It’s really clear what is needed, what has been provided, who needs to provide it, and when we should be expecting it from them.

Plus, we have minimized how many project management docs we have floating around.

At your kick-off meeting, you would review what needs to be done by going over the Action Register with your client.

Better Project Management

Every client we have done this with has been impressed by our organization, attention to detail, and determination to make it a smooth experience by taking the time to set up this process.

You need to review every task item with the client and confirm who is doing what and by when.

The client may ask you to make a few adjustments if they are afraid of not being able to meet a task’s deadline. This is actually good. This means that the client is carefully considering how they can realistically make good on their commitments to you and the success of the project.

Once you’re in agreement on these tasks, you’re ready to start the work because you’ve laid the foundation that facilitates and promotes commitment for the rest of the project.

Manage Expectations Better

After the kick-off, you need a way to continue to manage expectations on the project execution.

Even though you worked on an initial schedule at kick-off, it probably becomes irrelevant as soon as something unexpected happens.

I will list out the different types of expectations and identify how the Action Register handles them for us.


Because the Action Register shows a Start Date and End Date for every task, it’s crystal clear when a task should start and when it should be completed by.

If something affects the start and end time of a task, it can be changed, with agreement from the client.


Every project has a limitation of resources — whether it’s money, time, people, a combination of a these things, whatever.

When it comes down to it, you need to prioritize tasks whenever unexpected events happen.

In the Action Register, you can easily adjust start and end dates to prioritize tasks.

You can also use the Actual Hours and the $ Amount columns to tally up how much work you already have, to show you and the client if or how to factor in a new task.


It’s inevitable that the client or your team will discover a need to add some new tasks beyond what has already been agreed upon and approved.

Related content: Do you want to know how to minimize the addition of new tasks in your projects (in project management terms: scope creep)? Read about how to avoid unscoped work from unreasonable clients.

By listing these as new line items in the Action Register, they become separate tasks to be handled. If you need approval from the client to do the task, you can put the Estimate in Hours (or $ Amount) in and set the status to "Needs Approval", and make sure to review at your next meeting.

The client then has the opportunity to fully understand the effect of adding the new request.

We have had clients that have a tendency to add more and more tweaks to the project and expect the same deadline to happen.

Once we started putting in estimated hours and how much it would cost them for us to be able to complete the new tasks, our clients would make these requests more carefully since they saw how it could affect the project’s completion time, require them to do additional work, or add cost to the project.


Ever had a client say "I didn’t know I was going to be billed for this" or "I didn’t realize it would cost this much".

It happens.

Maybe you weren’t clear.

Maybe the client doesn’t remember.

Whatever the case, you can avoid this — and we have — by using the Action Register as the backbone of the project execution and by reviewing it regularly with the client.

The Estimate in Hours and/or $ Amount columns make it totally clear what the cost will be.

The Status column makes it clear if something was approved or not.


Like we talked about above, by assigning every task to a person, it is clear who should do what.

There’s no more, "Well, I thought Jessica was doing that" and "I didn’t know I was suppose to do that."

If someone isn’t doing their work or has left the team, their tasks can be reassigned to another person.

Tracking the Details

There is also a Comments column for adding details on the task items. Use this column for any additional details about what you and the client specifically agreed upon.

You can avoid or minimize the "I thought it would work differently" situations by adding clarifying comments to the Action Register.

Case in point: We have a few clients that are perfectionists. It’s easy for them to come up with a new idea to tweak something about their project without realizing these ideas may require plenty of hours of additional work.

That scenario happened frequently and it weighed us down.

Once we employed the Action Register into our weekly meetings, it became obvious to the client that these new tasks don’t always fit into the project agreement.

The client would then agree that some of their new requests weren’t really that important, or at least they would be OK with doing them later on.

What happened? By fleshing out all the desired tasks into the Action Register, we made it clear as day what was on the list to be done and as well as the needed resources to do them.

The client could plainly see when there’s a problem and offered a solution to prioritize some over others.

Related content: Learn how to decline new task requests by reading about the most powerful word known to mankind.

How to Implement the Action Register

Using the Action Register really begins to help you when you use it to run your regular client meetings and schedule your work week.

Let’s go over a simple process which you can use to cater to your own situation and style.

Weekly Review of the Action Register

On Monday, or whatever day of the week works best for you, block out time to sit down and review all your active tasks in your Action Register.

This is your time to fully understand the status of each of your projects.

If you or your team members are responsible for a particular task, get it on your/their calendars.

If you are unsure of the status of a task, now is the time to find out. You will save time by knowing for sure, rather than kinda thinking it’s done and then finding out later that it really isn’t.

Once you get into the habit of doing this weekly Action Register review, you will find that your head is much clearer and you won’t worry where you are in terms of the project’s progress.

Update the Action Register Whenever You Complete Tasks

As you and your project team members complete tasks throughout the week, update the Action Register.

If the task needs tweaks before really being complete, request the tweaks.

If a task is actually complete, update the appropriate task item with the Actual Hours and set the Status column to "Complete".

Schedule Regular Client Meetings

Schedule regular meetings with your active clients.

Having a quick phone meeting every week or every other week can make projects go more smoothly.

These regular meetings have an agenda that goes like this:

  1. Go through the list of tasks in the Action Register and review their statuses and whether or not each task is on track.
    1. If a task is not on track, identify why and what needs to be done by whom to get it on track.
    2. Adjust the Action Register accordingly. If this causes other tasks to be pushed back, clearly state why and agree on new dates with the client.
  2. If a task was marked "Complete", show the client that the task is complete and get their sign-off on the completed task if necessary.
  3. Move completed tasks to the bottom of the spreadsheet, or create a new sheet in the spreadsheet to move the completed tasks to. This way, you have a record of what was done and when. This can be very helpful if you ever need to look back and verify something. It’s a documented record of how the project went.
  4. If a task was recently added, and the estimated hours of completion or cost of the task is ready for approval, explain it to the client and ask for approval to begin work.
  5. If a task needs something in order to continue working, this is a good time to sync with the client on what you need and decide together how to continue.

You can save many back and forth emails by having the client bring observations, ideas, and questions to the meeting to discuss rather than emailing on a whim. Unless of course it’s something urgent.

Final Thoughts

Doesn’t it all just seem like common sense? Like with anything else, the more experienced we get, the more we see things in a simpler, more straightforward way.

The results of using the Action Register:

  • Your clients will feel in sync with what is going on with the project
  • You will minimize surprises
  • You and the client will be collaborating together to get the project completed

In the end, you’ll get to focus more time on the part of your work that you love the most: Building websites.

Related Content

About the Author

Steve Schmidt is the President and Web Strategist of Effect Web Agency. Since 2005, Effect Web Agency has been serving clients with web design, web development, website planning, SEO and empowering people to make smart web marketing decisions. Connect with Steve by heading over to Google+.

The post Manage Your Web Design Projects Better with an “Action Register” appeared first on Six Revisions.

July 22 2013


The Most Powerful Word Known to Mankind

"Nathan," my boss says to me, "we need to get this feature in before we launch the product."

"Don’t worry, it’s fairly simple and shouldn’t take long," I reply.

The request had been lobbed at me out of nowhere. The request seemed pretty straightforward, and apparently it was mission-critical.

If only I’d realized it was actually a grenade threatening to destroy our product release plans.

You’ve probably been in that same narrative before.

These seemingly small and simple requests can quickly become complex, dangerous, and an absolute nightmare.

As the product manager, I should have — and could have — avoided this nightmare by using the most powerful word known to mankind:


Why I Had to Learn to Say No

It had all started so well, we knew what we had to do and started to burndown the stories in the sprint.

(By the way, we use the Scrum software development method. If a term in this article isn’t familiar, check out this Scrum glossary of terms.)

Further requests came in, which wasn’t unusual, and they were quickly accepted without proper investigation.

Oops. Big mistake.

All of a sudden, the release had become bloated and it became much bigger than we had ever anticipated.

There were early signs of the release going off track, with the sprint burndown lagging, the story points increasing significantly, and an unusually large amount of questions being asked about the new stories.

Worst of all, I had started to look like an ass.

The scope had crept, clarity was absent, and I was losing control of this project.

We were hemorrhaging big time.

The bleeding had to stop.

My mindset switched over.

I had caused this mess. So I was going to fix it.

The only way to fix this was to use that amazingly simple but powerfully potent word.

Here’s how I did it, and how you too can get to No.

Stop the Bleeding

Just say No. Don’t use fluffy, doublespeak language. Just say it.


Deny new requests until you have the time and resources to properly look into them. Also, bear in mind that there will be future releases, so you can responsibly delay some ideas into the next release.

This sounds so easy, but it takes some getting used to. It takes a change in thinking.

For example, as a product manager, I’m often under intense pressure from the CEO or the client or my boss or a decision-maker. Saying No to these folks seems to be a career-limiting move.

No is your strongest tool for stopping the bleeding. It will let you reset and it will get you back in sync.

Flip the Problem

I explained why new requests were being rejected. We were close to the release date, and we just didn’t have enough time.

This, too, sounds quite easy; it was a good and honest reason for being unable to accommodate a request.

Yet it’s easy to forget that non-technical folk see what we do as black magic.

Don’t bother with the technical reasons for why the request is difficult to accommodate. Rather, highlight the consequences of adding extra work, such as a delayed release, increased costs, cranky and pissed-off software engineers, and so forth.

If you’re really pushed, make a point that every decision has its consequences.

"We can do what you asked. It just means [TheOtherFeatureYouAskedFor] has to go. Which is more important?"

The ball’s now in their court.

Appeal to Higher Objectives

If a feature request doesn’t progress you towards your business goals, or if it isn’t inline with your product strategy, why are you going to do it?

These types of scope-augmenting requests are often hastily made and not well-formed. They often shouldn’t be in the product until they’ve been better developed.

(Read more about creating good project scopes.)

Learn to say "No, it doesn’t help us get to our goals and it will have to wait for now."If the entire team is heading towards the same objectives, this will also help you gain broader support from other project members.

You Own the Backlog

One of the best tools for product managers is the sprint backlog. And you need to be all over it if you’re a manager.

If the product backlog is mysteriously growing, you’re in big trouble, and you need to step up, get all totalitarian and dictatorial, and let the offenders know the sprint backlog is your domain.

You must own it, and no one else can add to it regardless of how simple the task seems.

This might require a cultural change in your team, and be prepared for some push back, but you must get it done.

If you can’t control your backlog, you’re fighting a losing battle.

Final Thoughts

Hindsight is a wonderful thing. Watch out for seemingly simple requests that are actually grenades in disguise.

I’m now much more proactive about saying No. And if you too want to sidestep the problems I’ve faced, you must also learn how to use No, the most powerful word know to mankind.

Related Content

About the Author

Nathan Conyngham is a customer advocate focusing on project, product and expectation management. He’s an avid believer that the best results are achieved by focusing on the customer, having clarity of purpose and executing well. Get in touch with Nathan via his personal blog or on Twitter @nathanconyngham.

The post The Most Powerful Word Known to Mankind appeared first on Six Revisions.

July 17 2013


Your Clients Don’t Have to Like Your Work

Your Clients Don't Have to Like Your Work

Whenever I meet with a new client for the first time, I always tell them this: It’s not important that you like the design I’m going to make for you.

It’s always humorous to see the client’s reaction to this statement. Most look inquisitive, others look downright baffled.

I then expound on my initial statement: "It’s a bonus if you like it, but the main objectives are that your business needs are met and that your customers like it."

In almost all cases, they go along with this logic.

A few clients, however, will still have a personal need to like the finished product for themselves. But the smartest and most awesome types of clients get the concept, and I prefer to work with them. Why? Because they approach the design project with their business foot forward rather than let their personal tastes and biases control the process.

Personally, I approach each design project by looking at the needs of the users and the client first — so it only makes sense that I would expect the same from my clients.

The key difference between clients that need to love your work themselves versus those that go about the process in a much less personal manner all depends on who is paying the bills.

Where’s The Project Money Coming From?

Nine times out of ten, when a client is paying you out of pocket, they’re going to be much more hands-on throughout the process. Examples of clients that may be in this situation are startup entrepreneurs bootstrapping their company, who may have a powerful and very personal attachment to their business. It’s only human nature. They’re paying for it — or more specifically, they’re paying you for it — so they may want very fine control over the outcome. They may make the process too personal, because by the very nature of the situation, it is very personal.

I absolutely understand that situation. But the problem I see is this: The more a client takes the project personally, the less objective they become, and the more they tend to exert their own personal tastes towards dictating the direction the project takes.

On the flipside, clients who are merely overseeing the project on behalf of a large company aren’t paying for it themselves.

They will also have a compelling desire for the project to turn out successfully, but they tend to make it much less personal, and much more about what is good for their company.

Of course, those are all vast generalizations, but in my experience they tend to be true for the most part.

Making Your Clients Understand the Concept

Whether your client is a big multinational company or a fledging startup business, it’s your duty to make them see the forest rather than the trees when they are caught up in their own personal preferences.

If you’re designing a new website for a client — and you have done your due diligence at the beginning — you have probably asked many questions relating to their customer base and business needs, and are producing the website accordingly.

So what happens when you have done your job correctly and have created the perfect website that will connect with and engage their target market, but your client still doesn’t like it?

Ask Why

Ask them to point out specific parts of the design they don’t like. Then ask the client why they don’t like those parts of the design.

Then, ask the client if the parts they don’t like fail to fulfill the objectives of the project or if it helps achieve the objectives.

Often if you can get them to admit that although they might not like something, that it still matches with the objectives of the project, you will have a much easier time convincing them to go your way.

Ask for Examples

If you can get your client to point to examples of solutions that they like better, one of two things can happen. Maybe their solution is actually a better one. If not, collect your thoughts and explain why your solution is better for the job.

Point to Facts

If your client is adamant about adding an audio loop or splash screen on their homepage, send them references and resources that show why those are horrible ideas. Point to facts that show how these things affect user experience and usability.

If they want an overly complex logo, show them examples of successful logos in their industry, and point out what commonalities they all share (typically, good logos are simple and created using vector illustration software).

And if you can’t point to facts, then consider the alternative that the point of contention is debatable.

Know When to Give In

Having said all of that, there will come a time when it’s best to just give the client what they want.

Many designers will have a different point of view on that statement I’ve just made.

But in my experience, if I have a client that is firmly digging in their heels on an issue, I state my case, and leave the ball in their court.

As the saying goes, you have to pick your battles. Good design is definitely worth fighting for; and as for the rest, they don’t matter in the broader scheme of things.

Final Thoughts

While most of my clients have hired me for my years of experience and my body of work, some of them trust in these credentials more than others.

I always prefer to work with business people rather than people paying out-of-pocket, because they understand the end game in a much purer way.

While I love the situation where my clients love the finished product, it’s never my goal. If the project doesn’t hit home with their customers and business objectives, I can’t chalk it down as a success.

Related Content

Lead image source: "Workers at computers at the Huichon Machine Tool Factory in Huichon, Chagang Province"

About the Author

Wes McDowell is the Principal and Creative Director for The Deep End, a web design firm in Los Angeles. In addition to client work, he’s authored several books for freelance designers and co-hosts a popular graphic design podcast called "The Deeply Graphic DesignCast." Follow Wes on Google+.

The post Your Clients Don’t Have to Like Your Work appeared first on Six Revisions.

July 08 2013


Improve Your Web Design Projects with a Good Project Scope

Improve Your Web Design Projects with a Good Project Scope

The first few things you do after a potential client contacts you about a web design project are the most important. In fact, these initial steps can spell the difference between a good or bad project.

There’s plenty of information out there on how to identify bad clients and manage difficult situations. You may even have your own client horror stories of your own.

While it’s true that bad client situations sometimes can’t be avoided — it’s an inherent part of working with other people, after all — many of these situations are just simply the result of lack of communication and understanding.

Fortunately, if you create a good, thorough project scope statement, it will surely improve communication with your clients as well as eliminate many website production problems.

The Importance Project Scope

One of the important initial project tasks we need to do is defining the project scope.

A poorly crafted project scope statement results in miscommunication and wasted project time.

Project scope, in essence, defines what the deliverables for the project are going to be.

A good project scope should clearly and unambiguously state the client’s expectations, and it should describe how you have agreed to meet those expectations.

Evidence of Bad Project Scope

When something is added to a project’s scope, we call it scope creep.

Too much scope creep results in lots of unnecessary work.

Many web designers and developers are too casual about project scope. They fail to get the whole scope of the project before they start working on it, and this can mean lots of reworking and retooling all throughout the span of the project.

"Introducing ‘Feature Creep’, the nefarious designer arch-enemy." Source:

A lot of scope creep means the project scope wasn’t properly defined and clearly stated at the beginning of the project.

Common Mistakes Made When Defining Project Scope

Here are three common mistakes web designers make when they define scope:

Not getting the agreement in writing.

Scope should be included in a written agreement between you and the client. Scope should be reviewed and signed by both parties before you start the project.

Not asking enough questions.

Often, scope is incomplete and the web designer/developer didn’t ask the client for enough information to really understand the project requirements.

Making too many assumptions.

Assumptions are like guesses; sometimes they’re right, but often they’re wrong. A good project scope statement eliminates any assumptions.

The best way to develop a good project scope is to ask the right questions.

8 Key Questions That Will Help You Define Project Scope

Here are some questions you can ask your clients during initial discussions that will help you produce a solid project scope.

Question #1: What type of website will I be building for you?

A landing page, a blog, and an e-commerce site all need good web design but your strategy, production process, planning process, project requirements, project time, techniques, and so forth will change depending on the type of site you’re creating.

Question #2: When do you need to have this website completed?

Misunderstandings about the deadline can be a big source of client unhappiness. Make sure you have enough time to do the work they want you to do.

Question #3: What is your budget for the project?

This question tells you what the client can afford to spend on this project, as well as if they are a serious prospect for your web design business.

Budget affects the size and features that will be defined in the project scope.

Determine the Constraints of the Project

The three questions above will help you determine the three primary constraints — scope, schedule, and cost — of the project management triangle model that will cooperatively determine the quality of the results.

Here are the not-so-obvious questions that you might forget to ask:

Question #4: Who is the typical user of your website?

A website that works well for one audience will not necessarily work well for another audience. The target audience will significantly influence the website’s architecture.

Question #5: What goals do you want to achieve with this project?

Is the client trying to use the website for sales, to generate publicity, or to build an online community?

Website goals make a big difference in how you will proceed with the website’s design.

Question #6: What types of content will be used in this website?

Content strategy should not be an afterthought. Content strategy should be an integral part of your web design process.

If your client hasn’t planned for their website’s content yet, at the very least, you should get them thinking about it right at the start of the project.

This question also clarifies who’s going to be in charge of content, and you should document this area of responsibility in your project agreement.

Question #7: Can you show me examples of websites you like and don’t like?

Examples can speak volumes. Pay close attention to why the client likes some sites while disliking others.

Question #8: What’s the message you’re trying to convey with your website?

The website’s message needs to be clearly communicated through the site’s look-and-feel.

The answer to this question also affects the website features that you need to implement.

Ask More Questions as Needed!

Of course, the list of eight questions above is just a starting place to help you define project scope; they cover the fundamentals that you absolutely must know before beginning the project.

If you still feel like you don’t fully understand what the client wants after asking these questions, you need to ask more questions until you’re confident that you comprehend their desired outcomes in full.

Don’t Forget About Negative Scope

What’s negative scope? In a project’s scope, negative scope are items that won’t be a part of the project.

Discussing and documenting negative scope items can eliminate a lot of confusion and misunderstandings.

Negative scope could include these things:

  • Items you and client discussed, but have decided not to include as deliverables in the project.
  • Items that are often done for projects of this sort, but that the client didn’t want.
  • Other elements of websites that aren’t going to be part of your project agreement but that you anticipate the client might need, such as web hosting, social media marketing, SEO, and so forth.

By specifically bringing up negative scope items, you reduce the likelihood of the client assuming that these items are included in the project and of them claiming that the negative scope items were part of your agreement.

Negative scope brings more clarity to your project scope agreement, which is what we want.

Documenting the Project Scope

Even if you asked all the right questions, you could still get into trouble if you don’t have a good record of the discussions that you and the client agreed upon.

Maybe you discussed the project in a series of phone conversations with the client. Maybe you met with the client in person.

Do you rely solely on your memory of what you and the client agreed on? If you do, you’re taking a huge risk.

Our memories can be faulty. Our recollection of conversations can be different from that of the client’s.

The best way to eliminate disagreements about project scope is to get it in writing and to get the client to sign off on it.

Fortunately, there are some good tools and resources out there to help you document project scope well.

There are, for example, project scope document templates that can be found on the Web. Here’s one example of a project scope template that you can download on another website:

You could also check out my web app, Osmosis, which incorporates project scope into the work agreement.

Find more tips on freelance web design contracts here.

Once you have the client’s acknowledgement on the work agreement, keep the information with your project files.

How Do You Deal with Project Scope?

How do you define your web design project scope? What are some key questions you ask your clients that help you define the project scope? Share your experiences in the comments below.

Related Content

About the Author

Dominic St-Pierre is the owner and founder of Osmosis, an innovative web-based tool to help web designers, web developers, and other freelancers gather project requirements and create proposals. He has over thirteen years of experience as a web developer and entrepreneur. Connect with him on Twitter at @getosmosis.

The post Improve Your Web Design Projects with a Good Project Scope appeared first on Six Revisions.

June 14 2013


How to Get Your Web Development Projects Off to a Good Start

Advertise here with BSA

How to Get Your Web Development Projects Off to a Good Start

If you’re anything like my team, you probably want to dive right in head first into a web development project as soon as you possibly can. Because we love our jobs — we’re all very passionate about it.

We’re eager to get started without having to deal with the "boring parts" and we have a laser-beam focus towards the more enjoyable, fun aspects of web development — coding, setting up servers, designing the user interface, you know, the good stuff.

Early in my web development agency’s history, this is how we worked: The moment we returned from a project’s contract signing, Photoshop would fly open, databases would be fumbled together, and code would be quickly written. We couldn’t wait to get started with production.

And when that happens, proper planning goes out the window.

The result of insufficient planning and coordination? A project of any size and scope, big or small, ended up becoming a mess quite quickly.

The Secret to a Good Start: Project Kickoff Meetings

To get web development projects off to a good start, we now realize that effective kickoff meetings are essential.

What is a Kickoff Meeting?

An important component of planning your web development project is the kickoff meeting.

The project kickoff meeting is the initial meeting consisting of the project’s team and the client/decision-makers. It involves getting your team and all the decision-makers in a room to hash out the details about the project.

This meeting is important to web development projects because:

  • It familiarizes all the individuals involved in the project with each other
  • It extracts important details from the appropriate individuals to avoid information silos
  • It gives everyone clarity about the core objectives of the project
  • It gets everyone on the same page
  • It promotes active communication lines
  • It gets the project off to a great start

Let me share with you how I prepare and conduct my company’s web development project kickoff meetings. I promise that you and your client will have a better experience and will come out with a better product if you install a good kickoff meeting as part of your web development process.

The Project Kickoff Meeting Outline

Here is a brief digest of our project kickoff meeting structure:

I’ll discuss each of these items below.

Before The Kickoff Meeting

I suggest having a template for your kickoff meetings to promote efficiency and to ensure that you get the most value out of the meeting.

It’s nice to have a template guiding you for all the things you’re going to need from the client. You can print your template and then immediately start filling it up with information you already know well before the meeting’s date.

If you do several types of development (e.g. mobile app development, web app development, e-commerce site development, etc.) you may have to create a few different versions of your kickoff meeting template.

To help you get started, you can download my kickoff meeting template for web development projects. It’s a 7-page PDF document. It’s simple, but it serves as a fantastic way to start your projects off. You can look over this template and see exactly what you’ll need.

Be sure and read through the template and add to it based on your own business processes, workflow, and custom requirements.

Gather Basic Internal Information

The first thing you should do before getting everyone together for the kickoff meeting is to gather basic information about the project.

On your end, write down basic project details such as:

  • The project’s primary goals
  • Your project manager’s contact information
  • Secondary contact’s information in case the project manager is unavailable

Gather Basic Client Information

We are going to need technical information from the client such as server info, domain information, analytics data, previous SEO campaigns, and so forth.

Give your client a chance to get some of their information together before your kickoff meeting and send them a quick worksheet to fill out plenty of time before your first kickoff meeting sit down.

If enough time is given (1 week is enough time in my experience) it’s a good litmus test on how responsive and communicative your client is going to be throughout the web development project. Of course, this isn’t always guaranteed, but I like to use it as an indicator.

You should now be ready for the kickoff meeting after this.

Before getting into the specifics of the kickoff meeting, I’d like to first share some basic tips about meetings in general.

Fundamental Kickoff Meeting Tips

Your project kickoff meeting is an exciting time. Deposits have been paid, and the client is ready to get started on their project ASAP.

I find the more prepared I am for the kickoff meeting, the more likely the client will follow my lead and trust my judgment during the meeting as well as throughout the lifecycle of the project.

So, how can we guarantee a great kickoff meeting planning session?

Limit the Number of Attendants

Early in my career, I was working on a project for the board of education for a county near my hometown. We had just won the job and I was told the client’s team was coming into the office to meet with our staff.

When it was time for the meeting, ten people attended. That translated to ten opinions, ten people interrupting one another, ten potential bathroom breaks — ten cooks in the kitchen spoiling the broth.

It was a nightmare and we accomplished nothing but frustrating our brand new client.

When scheduling your first meeting, be sure to indicate that only the decision maker needs to attend. And if ten people make the decision, put your boots on and start walking because you should have never accepted the project under those terms.

I would suggest one or two people max come to your kickoff meeting. You will get more done, have less interruption, and have one or two people accountable for deliverables you will be requesting. Guess what? The finger pointing just got reduced as well.

State the Intended Results and Outcome

Open your meeting with what you’ll be going over, and what the client will be walking away with.

Setting expectations is something you should try to do every time you meet with a client to maintain efficiency and to show that you take their time seriously.

Most importantly, they will understand why they are meeting and be in the right mental state for your chat.

The Kickoff Meeting

Here is my meeting structure for kickoff meetings.

As you work through the meeting structure, you should be assigning responsibilities to your client and to your team.

After each task assignment, you should be asking the person being assigned the task, "When can you have that by?"

What I typically do is have a calendar nearby and I give them a little more time than they suggest. Typically, the client is eager to please and is sometimes unrealistic. Give them a little more time if you can spare it.

I do gently remind clients that if their deliverable is late, all dates are pushed back and we typically will charge extra unless given 15 days notice. It’s harsh, but it keeps people accountable and, in the end, makes them a happier customer because their project is on time.

In general, a good kickoff meeting can be accomplished in 2 hours.

Scope and Goal Review

I like to start my kickoff meeting like a thesis statement in a scientific paper: I state the primary goal of the project and provide a brief summary.

The SMARTer the primary goal, the better. For example, depending on the scale of the project, it might even be as specific as: "The goal of the project is to drive traffic to the site’s contact form and have users fill it out."

Then I review the scope of work that has been signed by the client. This allows you to set the stage and confirm what it is you are building, while refreshing everyone on what the project is all about.


Get the server, email, and analytics information out of the way early. You don’t want to be two weeks away from launch and have to set up a server.


Your technical discussion will absolutely take the most of the time.

This portion defines the project and you may need more than just the half sheet of space so have some scrap paper ready.

What you ultimately want to walk away with are three important pieces of information that everyone should agree on:

  • What are the primary and secondary goals of the project?
  • What do we want people to do?
  • What features will the project have to support these goals?

Copy and Media

Content, imagery, and rich media (like videos) is a subject neglected in a lot in planning meetings, but it’s one of the most expensive and time-consuming things to produce so it should be covered as soon as possible.

For example, most companies that I work with that produce video don’t do it quickly or cheaply. Get the ball rolling early on any video production needed, as well as reinforce who is purchasing any needed stock photography (it was in your contract right?).


The look and feel of a site is tough to nail down.

Early in my career, the conversation usually went something like this: "How did you envision your site looking?" That question would be followed by the client mentioning five of their competitors’ websites — all which would typically looked horrible.

You are the professional. You know what looks good and what doesn’t.

Instead of having them start and govern the conversation about the look-and-feel of the website project, ask them a few questions about how they want their site to feel and the general style. They hired you to figure out the rest.


When and how a site will launch seems like an obvious thing you will want to establish as soon as possible. The "when" is usually covered by the contract, but the "how" is sometimes forgotten.

Will there be a beta testing period prior to launch? How about slowly rolling it out to gain interest and test the load on our servers? These are some things to cover in the kickoff meeting.

Support and Revisions

This is a great discussion that can potentially generate recurring revenue for your company.

How do they plan on updating the site after it has launched? What if the web server crashes? What about additional features? What happens if a great idea comes up in the middle of the project that requires augmenting the original scope of work — how do we deal with that?


What type of marketing materials need to be prepared for this project? Do social media accounts need to be set up? What about traditional marketing methods? Do any parts of the marketing campaign need assets from our creative department? When and how should these efforts go live?


By this time, your customer (and you) are probably exhausted, but it’s a good exercise to quickly run through the deliverables, due dates, and a summary of the key points discussed in the kickoff meeting.

After the Kickoff Meeting

After the client has left, what I typically do is I will punch in the due dates into our project management software (we use activeCollab).

Then I’ll run a quick report. I’ll send the report to the client via email as a reminder of the things we’ve discussed, along with a note thanking them for the time they have invested into the kickoff meeting.

Related Content

About the Author

Gary Williams is the co-founder and CEO of the web development agency LogicBomb Media (Twitter: @lmb_co) near Atlanta, Georgia. He and his team specialize in data-heavy Web and mobile applications for companies like Nintendo, ESPN, and Travel Channel. Follow him on Twitter @dolbex.

June 10 2013


Lessons I Learned from Selling My Web Design Agency

Advertise here with BSA

Lessons I Learned from Selling My Web Design Agency

I sold my small web design business so that I could focus on my startup, Informly.

If you’re providing web design services as a solo freelancer, or are the founder of a web design agency with several employees, selling your business might be the farthest thing from your mind right now.

Perhaps you have never thought about it simply because you might not have realized that selling your business was even a possibility.

Maybe you are too attached to your company to even consider selling it to someone else.

Or the case may be that you have some fears about the things selling a business might entail.

You might want to get out of the web design business entirely, but are worried of the loss of income that might follow if you leave the industry behind.

Those are some of the things that might be holding you back from letting go.

However, it’s always good to think about your options.

Let me tell you the lessons I have acquired from selling my web design business, in case you are considering of doing the same thing. It’s not my first and only experience either, I’ve had other experiences in the area of buying and selling web design businesses prior to the sale of my own.

Lesson 1: You Don’t Have to Be Big or Well-Known to Sell Your Business

One of the biggest misconceptions I see people possessing, whenever the topic of selling a company to another is brought up, is that the company being sold has to be big and famous.

In my mind, that misconception comes from the fact that business brokers and tech journalists tend to talk more about the acquisition of a large, popular company by another larger, more popular company; so many of us end up thinking that acquisitions of small- and medium-sized businesses don’t happen.

In reality, there are loads of smaller acquisitions going on all the time. Like my web design business for example. It’s just that these business transactions usually don’t happen with as high a profile as, say, Yahoo! buying Tumblr.

These sorts of little transactions go on all the time because there are a lot of people who start a web design business and can’t make it work.

There are also many web design agencies looking for more clients, assets, and employees — and so one of the ways they can expand is through the purchase of a smaller web design company.

My web design agency wasn’t big. Not Tumblr big, anyways. Yet, I was still able to sell it.

Lesson 2: You Don’t Have to be Profitable

Many people think that you need to work your way up to being a profitable company in order for it to be appealing to a buyer.

That was not the case with my web design business.

In my experience, when larger web design companies buy smaller ones, more often than not, they are looking for something more than just profitability.

Web design companies and entrepreneurs are looking for signs of opportunities that the company they are looking to buy will grow if they take it over.

Lesson 3: Opportunity and Potential Are Important to Buyers

If you have terrible business processes, expensive employees, undercharged clients, a lot of overhead, etc. your profits won’t be great.

But another entrepreneur might look at that scenario and see opportunities. Opportunities to reduce waste. Opportunities to improve business processes. Opportunities for optimization.

Entrepreneurs, by nature, are people who see opportunities in things that other people are not able to.

It’s like flipping houses in the real estate business. For example, I see that in the area where I live in, houses are bought at a very low price, renovated by the new owner, and then sold at a much higher rate.

Everyone wants to buy a company with potential.

Lesson 4: Upward Trends Are Important

Prospective buyers want to see metrics going up.

When I sold my web design agency, my site traffic had doubled in its last 6 months.

Recurring revenue was going up. The number of clients was going up.

Even if you aren’t profitable, as long as important metrics exhibit upward trends, buyers will see opportunity and potential.

If your profits are good, but your trend is flat or going down, that is a big problem.

Lesson 5: Your List of Clients Will Help You Sell the Business

The biggest problem for web design companies is finding good clients.

If you have a list of good clients regardless of whether your business is profitable or not, this is going to be appealing to a web design agency buyer.

Even better than having a good set of clients is having clients that have recurring arrangements with your business. These recurring arrangements might include monthly website maintenance fees or web design service retainer agreements.

I had my existing clients on support agreements.

I also sent them an email each month with stats about their websites (which, by the way, was the inspiration behind Informly, my startup).

I was hosting most of my clients’ websites.

In the end, the main reason I was able to sell my web design business was that I had good clients who brought in recurring revenue into my business each month.

Lesson 6: Some of Your Assets Aren’t as Obvious as They Seem

What do you have within your business that could be appealing to a buyer? These assets might not be readily apparent.

In my case, one of my assets was actually my company’s web design blog. The blog ranked #1 in Australia for the search term "website design" and #3 for the term "web design". The blog was bringing in 1 lead a day to my business, on average.

My web design blog had a lot of value to someone who wanted web design leads.


They would have had to pay Google thousands of dollars a year through the AdSense platform to get the same amount of traffic for those keywords, so there was clear value in buying something that’s going to provide them ongoing benefits for free.

You might have something completely unrelated to your web design business that would be an asset to someone else. Look for those not-so-obvious assets and use them to help you sell your web design agency.

Lesson 7: Being a Small, Personal Business Isn’t a Deal-breaker

I used to give a lot of advice to small business owners. One of the things I would always say was "be as personal as you can in your business."

That means using your personal name, having pictures of yourself on your website, having transactional emails coming from your own personal email address instead of a robot like, and so forth.

The advice about being as personal as you can is very different from what I see a lot of small businesses actually do.

What I see more of is that small businesses try to be more distant from their customers and more "corporate"-looking, to appear bigger than what they really are.

Often when I’d tell people their websites should be personalized, I would be met with criticism. A lot of people think that in order for something to be valuable, it needs to be some sort of impersonal machine, because being impersonal implies that the company is too big and too busy to have its founders and employees directly interacting with their customers.

I couldn’t have possibly been more personalized in my business.

I had a blog where all posts were by me.

I had loads of face-to-camera videos.

My face was all over the site of my web design company, including right at the start of the homepage in a big welcome message.

All of my clients dealt with me personally as the first port of call for almost everything.

When it came to selling my web design company, being small and being personal didn’t get in the way.

In other words, other companies who want to buy up web design businesses aren’t looking for some huge corporation — they’re completely happy acquiring small, personal companies like mine.


Whether you’re planning to sell your business or not, it’s good to at least consider these things for when you might have to do so, and also just to keep in mind that what you’re building might be worth more than you think it does to someone else.

If you have questions about the topic of selling a web design agency, please feel free to start a discussion in the comments below.

Related Content

About the Author

Dan Norris is the founder of Informly, a startup that enables web design companies to send their clients beautiful branded reports. He’s on Twitter, Google+ and Facebook (a little bit too often, according to Rescue Time).

June 05 2013


The Secret to Building Large Websites: Website Architecture

Advertise here with BSA

When I started writing this, the idea of a skyscraper construction project came to mind.

I thought of a huge skyscraper with restaurants, retail stores, offices, gyms, and residential spaces — a large self-contained, compact community all by itself.

Source: Bernt Rostad

No one would ever start the construction process of a skyscraper like that until everything is properly planned and drawn out.

Source: Steve Newfield

I’m not a building architect or construction contractor, but I can still see the innumerable requirements you need to draw out before proceeding to construction. Room planning details, sourcing of good construction materials, managing the different teams involved in the building’s construction, zoning permits, funding allocation, natural disaster planning in case of earthquakes, the list goes on.

Everybody considers design as an important component of things; whether it’s the design of a skyscraper or the tires of your car.

Design is about not only bringing convenience, innovation, and comfort into people’s lives, but also in many cases such as skyscrapers and your car tires, people’s lives and safety becomes dependent on it.

I’m not an architect.

I’m an IT person. I’m a concept designer to be more exact.

For years, I’ve been designing strategies and conducting research for very large, ambitious website projects.

Concept design is the foundation of a robust website architecture. Like in the construction of a skyscraper, you need to have a sound blueprint for building large-scale websites.

In this article, I’ll share our company’s process for architecting large websites.

The Website Architect

Let’s first figure out whose role it is to do this thing called website architecture.

To me, this job is carried out by a website architect.

I deliberately avoid mentioning UI/UX designers and the IA guys here because website architecture goes beyond — or rather encompasses — the user interface, user experience, and information architecture of the site.

The website architect needs to have a solid understanding of usability, in-depth knowledge of web development tools, online marketing technologies, and everything else involved in the construction and maintenance of a website.

Just like an architect of a skyscraper or a residential home, she must be well-versed with the tools, materials, and processes of construction in order to plan the product efficiently and effectively.

This person, our website architect, should possess strong logical thinking, has an analytical mind, is smart with commercial aspects of websites, and be attentive to details.

Of course, for a guaranteed quality product, the architect can/should consult other specialists: designers, developers, etc.

As you see, the ideal web architect in my mind should be a broad specialist, because, as you’ll soon see below, there’s no getting away from that.

Overview of the Website Architecture Process

I’ll give you just a general overview of my company’s website architecture process.

The process is divided into these 11 stages:

  1. Project Brief
  2. Website Goal Definition
  3. Define the Target Audience
  4. Competitor Analysis
  5. User Goal-Problem-Solution
  6. Scenario Mapping
  7. Mind Mapping
  8. Information Architecture
  9. Prototyping
  10. Prototype Usability Testing
  11. Project Specification

As you can see, all these stages are related to each other, and we’ve organized it in a sequential manner.

Let’s discuss each stage.

Stage 1: Project Brief

Gathering the needed data from the client and your team can usually take 2 days. Though you should be as thorough as possible, also keep in mind that there’s always room for elaboration and additional data-gathering in the other stages of the website architecture process, so don’t get too off-track if some pieces of information haven’t been transmitted to you.

Determine Goals and Expected Outcomes

What is the client’s goals and expected outcomes of this project, and how does she envision the end result of the project?

You should be clear about the evaluation criteria of these goals and expected outcomes to make sure you’re both on the same page.

You have to be as specific as possible; goals and outcomes should be quantifiable and measurable.

Brainstorm with the Client

Ask the client to tell you everything he has on his mind. Listen to what he says patiently and thoughtfully. Take notes. Focus on what they’re saying and resist the urge to chime in. Your ideas and remarks can wait.

If the client is passionate about his ideas for the project, he can spend hours talking about it, which is completely normal.

When the client is really into the project, he’s a great help and pleasure to work with.

Client Idea Summary

At the end of your brainstorming session, you should ask the client to sum everything up — if he succeeds in boiling his idea down to one sentence, then the idea is clear. If not, you will need better clarity and focus.

Determine the Target Audience

Who is the client’s target audience? Who’s going to use this site, and how might they benefit from the site?

The client should have a clear idea of who the end user is, so that we can produce a website for them. Otherwise, it’s like playing darts with your eyes closed: You know where the target is, but it’s going to be nearly impossible to hit it.

You can also start discussing what the client already knows about their target demographic: gender, age, location, etc.

Determine Competitors

Who are the website’s direct and indirect competitors? The client and the website architect should be aware of the existing competitive environment.

There are always competitors. Even if the website’s idea is completely unique, there are at least indirect competitors.

Meet the Decision Makers

Meet with the people who make decisions. Discuss the deadlines, the budget limit, resource availabilities, and so forth.

Organizational matters, matter.

Results and Deliverables

Some of your other questions will need to wait to be answered later on in the website architecture process. What you get out of the project briefing stage will be basic data and just to get a general feel of what your client already knows about his project.

It’s crucial to understand the client’s needs and expectations at this early stage, and to choose the right direction for the project right at the starting line. The price you pay for not giving enough time to this simple but critical first stage exponentially grows as the web architecture process and website production progresses.

A project brief template. Source:

The deliverable of the briefing stage is a written document with detailed information given to you by the client and the decision-makers. This document should be approved and verified by the client. It can be in the form of a design brief.

Stage 2: Website Goal Definition

A website needs goals. The client’s goals might be these: to monetize the site, to increase the offline market share through online marketing, to better engage customers online, and so forth.

The goals define the direction of the entire website production process.

Besides determining the website’s goals, you also need to define success criteria according to the client.

A good way to establish goals is by using the SMART criteria. That is, each goal should be:

  • Specific
  • Measurable
  • Attainable
  • Relevant
  • Time-bound

For example:

  • Generate $50,000 income within 5 years through ads, information products like e-books and paid subscription plans
  • Assist users in making a choice of what pet to own
  • Provide users with advice on pet issues
  • Create a marketing platform for pet products

Results and Deliverables

As a result, you will have a document containing 2 lists:

  • A list of project goals
  • A list of the client’s goals

This document needs sign-off by the client/decision-makers.

Stage 3: Define the Target Audience

This stage involves researching the target audience. We need to identify what types of users will go to the site, and also define the needs of each group.

Gather Characteristics Data

We need to create a common persona for each group. The user interface design depends greatly on the results of this stage. To get started with this, we first need to define what our audiences’ common characteristics are.

Define Socio-Demographic Characteristics: We should figure out the sex, age, education level, and occupation of our target audience. Targeting teenagers (15-18) is going to differ from a site meant for people over 60.

Define Psychological Characteristics: We should determine the lifestyle, personality, temperament, motivation, value system, philosophies, etc. of our target audience. This information is even more important than socio-demographic characteristics in terms of user interface design. If, for example, our users are early adopters, the user interface and pre-launch strategy will be different than other websites.

Define Wants/Needs Characteristics: We should figure out why our user would want to sign up to our website, what problems they’re looking to solve with our site, etc. We define their pain points and aim to solve it with our website.

This information is vital, though it’s hard to find. If you’re working on a website redesign project, the client may already have this information if they have user feedback tools in place.

Sometimes the competitor can have it (but good luck getting them to share it with you). In this case, you need to perform user research studies and conduct surveys.

Geographic Location Characteristics: Country, city, region, continent — these are all helpful information. Being online does not completely eliminate the location factor.

Sometimes geotargeting is the first thing to think of when creating a national site, government website, or any location-dependent website.

Moreover, website content and website copywriting is heavily determined by the audience’s location.

You will need this when you’re in the information architecture (IA) stage.

Create User Personas

When the target audience portrait is well-defined, we can then create personas.

Example of a persona. Source:

The main goal of the web architect here is to determine all the possible groups of users, starting from the largest (core) group, and ending with the smallest one.

Then we create a persona for each group.

Each of the personas you develop should have a:

  • First and Last name (Don’t use the names of real people to avoid distortion of the story)
  • Photo
  • Age
  • Location
  • Occupation
  • Marital status
  • Hobby
  • Skills
  • Problems they need to solve
  • Personal and professional experience

To get a better image of your target audience you can interview potential users. This is about marketing research at this point.

Results and Deliverables

After finishing this stage, you should now have two things:

  • A document presenting the general characteristics of the target audience
  • Personas

Stage 4: Competitor Analysis

To ensure the success of the project, you need to know your competitors and have good ideas on how to get ahead of them. You should discover their strong points and weak points.

There are several methodologies involved in conducting competitor analysis research, including market participant polling, and Internet and print media research.

If you’re creating a local website, don’t limit yourself only to your country. Look through international websites that are doing similar things. Most likely, there are similar or analogous projects up and running somewhere in the world. Some of these projects can be rather inspiring.

For example, we’ve been working on a social networking site for pet lovers for a client in Russia. We didn’t find direct competitors in the local market. However, there are several foreign sites and indirect local competitors. They are:

Competitor Characteristics international, popular, quality Russian project, quite popular, satisfying quality international, popular, quality

Your website’s competitors can be direct competitors or indirect competitors.

  • Direct competitors can be defined as any website operating for the same user base and who offer analogous products. For example, a direct competitor of Microsoft Windows is Apple Mac OS.
  • Indirect competitors are competitors who offer similar products, but only partially satisfy the target audience’s needs.

SWOT Analysis

There are different approaches towards competitor identification and analysis. I like SWOT analysis the best.

SWOT — which stands for Strengths, Weaknesses, Opportunities, and Threats — helps indicate the strong points and weak points of your competitors, and more importantly, aids you in figuring out project opportunities.

SWOT matrix. Source:

While analyzing competitors, you can discover useful site features and ideas worth adapting onto your own website — general, universal site features like commenting systems, web forms, etc. There’s no need to reinvent the wheel in these cases.

All good ideas you end up with during the competitor analysis stage will be needed for the mind mapping stage (which we’ll discuss later on).

Results and Deliverables

You should now have:

  • A list of direct and indirect competitors
  • A SWOT analysis for each competitor
  • Research summaries (ideas generated, market opportunities, etc.)

Stage 5: User Goal-Problem-Solution

Proceeding from the personas we’ve developed, we can start working on goal-problem-solution.

User Goals

Every person has short-term and long-term goals.

There can also be sub-goals. For example, a person might desire to improve his career, but first he needs to find a job. The sub-goal is finding a job to reach the goal of improving his career.

For our website project, we identify a person’s goals, problems, and we look towards providing solutions for them.

All goals should be designed well. Fuzzy goals won’t help, as it’s impossible to solve all problems within one site. Focus on primary goals and keep the list of goals short.

Some clients think if users listen to music online, their site should also provide such a service, even if their website isn’t looking to solve this problem. The more features we add, the more diluted our core objectives become.

User Problems

When we have a list of concrete goals, we can determine concrete problems.

For example, a user goal on our website might be to find a contractor that can build his construction project. That goal is more complex than it seems: How do we locate the right contractor for the user’s specific construction project? Is it important that the contractor is located close to where the construction project is? How do we allow them to quickly evaluate many candidates? Due to questions like these, you’ll generate ideas easily.

Our Solutions

When we’re done identifying goals and problems, it’s time to design and develop solutions for them.

This process brings great fulfillment to the website architect because she’s looking to solve pain points that her users have.

Results and Deliverables

As the result, we’ll have a goal-problem-solution matrix designed for each persona we’ve developed for our website.

Stage 6: Scenario Mapping

Scenario mapping is the stage dedicated to revealing possible user flows.

User experience mapping. Source:

Once again, we need to think like an end user and create probable scenarios of his actions on our website.

Every goal of every persona has his/her own set of scenario maps.

These scenarios help reveal weak points in our existing ideas and knowledge. Scenarios also help the website architect develop good user flows later on.

Results and Deliverables

We should have scenarios mapped out for critical site goals that we’ve established in the previous stage.

Here’s an example of a scenario:

User Goal:

Choose a dog


  1. Go to main page
  2. Go to "Zoopedia" section of the site
  3. In "Zoopedia" section, find topics and discussions about dog breeds
  4. Read topics and discussions of interest
  5. Go to the Read Also section, located at the end of the topic because there’s more information there
  6. Choose 3 preferred dog breeds
  7. Return to "Zoopedia" top-level web page
  8. Read some more
  9. Find links to people selling dogs of these breeds
  10. Make an informed, final decision
  11. Go to a pet store to purchase a pet

When we wrote out this scenario, we ended up adding these site features:

  • "Zoopedia" rubricator
  • "Read Also" widgets
  • Links to pet stores and dog sellers on the breed information pages

As you can see, scenarios help us find opportunities for improvement.

See Also:

Stage 7: Mind Mapping

When we have a bunch of ideas, it becomes helpful when we start visualizing and interconnecting them.

The mind mapping stage is dedicated to creating a solid system of logically connected ideas and also helps us cut out unnecessary things. It’s a popular design conceptualization tool.

To create mind maps, we should use Xmind.

Find your list of ideas and divide them into logical categories. For example, let’s say we’re working on a real estate website. The real estate website’s sections might be:

  • Property Catalog
  • Community Forums
  • Articles/News
  • Information Center

Map all of your ideas into one of these categories.

If an idea fits in more than one category, choose the best fit for it.

Brainstorming will help sift out the useless and unneeded features, web pages, etc.

Each website section should be planned logically. Don’t forget about section-dependent features (such as the user being able to rate each property, in our example). Mark this connection with an arrow to remember the dependence (in our example, it would go to the Property Catalog).

You can design your own symbols to indicate different functional sections. If the web architect, for example, is undecided in terms of which section a certain site feature belongs to, she can mark it with a question mark. These symbols are really important if the project is large.

Results and Deliverables

As a result, we have a bird’s-eye view of the interconnections of site features and sections.

Stage 8: Information Architecture

Now that we have a detailed mind map of our website, we can start working on the website’s information structure, which will be the foundation of the website’s prototype.

The website’s IA can be created with the help of flowcharting software like Visio.

Results and Deliverables

You should end up with an information architecture (IA) design after this stage.

See Also:

Stage 9: Prototyping/Wireframing

You will need prototyping software for this stage. I recommend Axure, though there are a number of other similar programs.

The home page prototype doesn’t necessary have to be prototyped first. For example, in the case of an online shop or a blog, the product page or blog post page should come first, because these are critical pages, and will typically be the landing pages of most users on the site.

The website architect is going to lean on the mind map and information architecture diagrams to develop this prototype.

When creating each web page prototype, you should focus on how the user can achieve his/her goals. Before prototyping, you should refresh your knowledge of your target audience using the previous stages in the website architecture process.

Prototype the Primary Navigation Menu

The primary navigation menu is the first to create. We need to figure out the number of menu items and the number of drop-down menus.

Prototype the Header Section

Then we design the header section that typically contains these items:

  • The primary navigation menu
  • Search form
  • Contact information
  • Website logo

Prototype Contextual Areas

Now we start designing contextual areas, which will differ depending on the web page you’re prototyping. We will make content blocks, some of which are constant for every page, some of which won’t.

Prototype the Website Footer

The footer typically stays the same on each web page. Usually, the footer duplicates the main menu. It also contains auxiliary information such as the website’s privacy policy, links to social networks, contact information, copyright information, and so forth.

Client Feedback

The first web page prototype should be shown to decision-makers, and the reason for the layout should be explained to them. The client might revise and suggest some adjustments. That’s OK, because having this done on a low-fidelity prototype is much easier than if we had a higher-fidelity prototype.

After the first page is approved, we can move to the next prototypes. All the ideas represented in our mind map should be found in these prototypes. It’s crucial not to forget about the smallest detail, as it can turn to hell in the long run if you do.

Test the Prototypes Against Scenario Maps

Our scenarios will help test the mockups to ensure the logical order of every action.

This is the most time-consuming component of this stage and requires a lot of patience and attentiveness. In the case of large websites, there could be over 100 unique interface prototypes.

Results and Deliverables

The deliverables after this stage are low-fidelity prototypes/wireframes of all web page types.


There are 90 some such prototypes for the example project above. As you can see, each prototype was broken down in detail. This way, no questions and uncertainty arose during the design of the functional prototypes and finished web designs.

Stage 10: Prototype Usability Testing

This is one of the best ways to quickly validate the effectiveness of the website architecture and make changes before things progress further.

Axure generates HTML from prototypes, which make them interactive and ready to test on users.

Usability testing at this stage will help you notice gaps and flaws in the architecture.

For testing purpose, we invite some representatives of target audience and observe how they manage to reach certain pages and results within the site.

Then, the users can be interviewed regarding the site in general.

After usability testing we make final corrections.

Results and Deliverables

As the result, we will have validated and improved the user-friendliness of our web page prototypes and we get a better picture of how users would be interacting with the site.

Stage 11: Project Specification

The final stage of the website architecture process is to create the project specification document. This should contain a detailed description of each stage of the website architecture process.

The project specification is the result of all the stages you’ve gone through. It typically will contain a detailed description of each prototype, user flows, and so forth.

The specs should be full and unequivocal. Be detailed and thorough, but also keep it as succinct and as concise as possible.

The project specification should contain all the information regarding software and web technologies required for the website.

Design requirements should be clear.

Once the project specification is approved, website development starts.

Related Content

About the Author

Nikita Semenov is the founder and CEO at SECL Group Ltd. Web development has been his life’s work since 2003. Contact him via the company website contact page or on Facebook.

March 07 2013


Web Designers Making Thousands of Dollars in Passive Income

Advertise here with BSA

Web Designers Making Thousands of Dollars in Passive Income

Web designers who want to make passive income are in a very good situation right now. Most businesses nowadays commit significant resources towards their websites. This means that the demand for web design skills is higher than ever. It also means that there are plenty of opportunities for web designers to create streams of passive income by leveraging their existing skills and experience.

Let me start by defining what passive income is. Passive income is money you generate from things that require little resources and time in maintenance. You may need to provide customer support or updates to your product, but most of the work will be done in the production stage of whatever you’re selling.

What are examples of things web designers can make to generate passive income? Below are some examples and inspiring success stories.


Now is a great time for writing and selling e-books. Last year, e-book sales went up by 46%, showing that the demand for books in digital form is increasing.

Similarly, sales of mobile tablets — the devices that make e-books much more convenient to read — is growing. In Canada, for example, 1 in 4 people have a tablet. And in the UK, the number of tablets in households is forecasted to nearly double this year, from 5.87 million to 10 million.

Now is a great time to make and sell e-books.

Web designer Sacha Greif (a guest writer here on Six Revisions) made $15,000+ in sales for an e-book about designing user interfaces from scratch. It only took him 3 weeks to write.

Web Designers Making Thousands of Dollars in Passive Income

Web developer Jim Gray made over $15,000 in 6 months with his e-book Clean Ruby. He shares some stats and tips in a blog post.

App designer Nathan Barry (who has guest posted on Six Revisions before) made $6,000 in the first day of launching his e-book, The App Design Handbook. He reveals his strategy for achieving this amazing product launch in a blog post.

Online Courses

Many people around the world are eager to get into the web design industry. They are hungry for quality information that would help them master the craft.

Online video courses are an excellent medium to teach web design. Either publish them yourself or look at sites like Treehouse, Code School, Udemy, etc. to see if they can be the publisher of your online course.

Can you make a good amount of passive income through online courses?

Let’s take as an example designer/developer Chris Converse who currently has over 3,500 subscribers to his $150 online course on Udemy about creating a responsive web design.

By June 2012, the course generated $80,000 in sales during the time that it had less than half of the current subscribers.

Mobile Apps

iPhone and iPad sales are not likely to slow down anytime soon, which means that there is a constant demand for all kinds of apps, from entertainment to productivity to education.

Nathan Barry made close to $30,000 in a little over a year and a half from the first app that he launched, OneVoice.

One of Barry’s other apps, a personal productivity tool called Commit, has generated $6,000 in profit.

"Start working on your app today," says Barry in a post where he discusses his experiences generating income from his apps.

WordPress Themes

With WordPress being a leading content management platform, there’s a big demand for affordable and high quality WordPress themes that allow users to have a beautiful website without having to spend a fortune hiring web designers.

In one report, Web designer Kriesi, a top seller at the Envato marketplace, was able to produce over $1,000,000 in sales from his WordPress themes.

Serial entrepreneur John Saddington has built a successful business around a single WordPress theme called Standard. "It’s not too complex to create your own WordPress theme," says Saddington.


Web designers have a very real opportunity to make themselves more financially secure and independent by creating sources of passive income.

I hope that these success stories have inspired you to, at the very least, get started on your personal project and thinking about how you could possibly monetize it.

Share your thoughts and other inspiring stories in the comments!

Related Content

About the Author

Agota Bialobzeskyte is a writer at FounderTips, the only online marketing blog for web designers and web developers.

March 04 2013


10 Myths about Startups

Advertise here with BSA

Over the last two years of working at Buffer, I’ve come to learn that there are a few preconceived notions, stereotypes, clichés, and commonsense knowledge about startups that simply aren’t true.

I’d like to share some myths that I’ve discovered while working at a tech startup.

Myth 1: "You Need to Have Deadlines"

It’s hard to find companies, new or old, that don’t have deadlines. It’s in the business culture to set deadlines. And deadlines, on the surface, seem even more important in a newly launched Internet startup as a gauge of rapid progression.

And, honestly, in the beginning, we got sucked into thinking that deadlines were important to our success.

Here’s what we’d do: We’d set a deadline, work like crazy as the date arrives, and then, once the task is finally finished, we could relax.

As most of you probably already know, that never works when you’re trying to do something innovative and new; when you don’t have a manual to refer to on how to perform your tasks. And having deadlines didn’t make us happy either.

So, instead, we decided to apply the idea of pace. We help everyone on the team perform their work at a fast pace. We never try to build up to a big launch anymore.

At Balsamiq, we don’t have deadlines. Ever."

- Giacomo "Peldi" Guilizzoni, founder and CEO of Balsamiq Studios

Myth 2: "You Need Everybody in the Same Room"

This is may be the most obvious — and surprisingly still prevalent — myths about working at a company.

I have to admit that I was very skeptical about working in a remote team. My thinking went like this: "Yes, you can probably have a good team working remotely, but what about a great one?"

The truth is that you can build better remote teams than ever before, and most likely an even better one than having everyone in one place because you remove the geographical factor when you hire team members.

The people on the Buffer team live in Australia, U.S. and Europe.

I believe that embracing remote teams is one of the most important elements going forward.

"The technology to successfully run and manage remote teams has never been better."

- David Heinemeier Hansson, creator of Ruby on Rails and partner at 37signals

"WooThemes will always stay true to our remote roots."

- Adii Piernaar, co-founder of WooThemes

Myth 3: "You Don’t Need a Company Culture at the Start"

So, you’re a team of 4 or 6 or 10. The intuitive thinking in this situation is that company culture is a huge waste of time.

You’re small. You’re just starting out. What you need right now is users, marketing strategies, and beautiful code.

Who cares (or has time to think) about company culture?

Building a company culture from Day 1 was one of the most important elements in Buffer’s growth.

I remember that when I first got on board, Joel (the company’s founder) and I wrote a short document called "The personality of Buffer." This simple document helped us in staying aligned with our vision whenever new ideas or challenges came in.

Culture, I believe, should be solidly in place before any feature update, marketing campaign, significant code-writing, and so forth. It doesn’t have to be elaborate; it could be a short document like ours that guides you in the proper direction.

"If I could do it all over again, I would roll out our core values from Day 1."

- Tony Hsieh, chief executive of

Myth 4: "You Have to Work A Lot, Never Sleep and Feel Miserable"

One of the most common beliefs about the tech startup life is that it’s a miserable one.

You are spending day and night in the office, fueled by energy drinks and pizza, without anything else in your life going on.

We’ve found that discouraging crazy work hours and instead building up an incredibly solid daily routine is much more powerful.

What we do is in fact quite counterintuitive to the prevalent notion that work hours at a startup has to be long — we even ask people to go home even if they’re in a good flow!

You can’t sacrifice today for tomorrow.

"Happiness is not something you postpone for the future; it is something you design for the present."

- Jim Rohn, American entrepreneur, author and motivational speaker

Myth 5: "You Can’t Make Money Until You Become Big"

Making money in the early stages of a startup is often equated to "You’re doing it wrong."

The thinking goes: If you’re focusing on monetization at the start, then you’re not putting all of your attention on growth, which is the most important thing for a startup.

On the contrary, there’s nothing better for a startup than making money early. And it’s not just for the obvious reasons.

"Charging for something is the best way to truly validate your idea," is a line from Joel, Buffer’s founder.

"Making money > Raising money."

- Hiten Shah, co-founder of Crazy Egg and KISSmetrics

Myth 6: "You Need to Hurry!"

This misconception about startup companies is similar to the one about needing deadlines.

The idea is often this: You’re a small startup, you need to outrun the competition and everything needs to happen quickly and in a hurry.

That’s a recipe for burning out and for making huge mistakes.

At our company, we try many things to create a balance between being fast-paced and not rushing our work.

One of the best ways to accomplish this, I’ve found, is with deliberate reflection. Recently we introduced "Daily Pair Calls" where two members of the team have a daily call to reflect and discuss their previous days. It’s a great way to slow down in order to speed up.

"Breaking things in right requires a certain amount of patience. You don’t want to push a new engine too hard. You certainly can’t sit still. And the last thing you need is to stall on the interstate."

- Todd Razor, founder of Three Razor

Myth 7: "You Need to Focus on Hiring the Best People"

Here is another myth that definitely needs some explanation first.

We see that new CEO, VP or SVP being hired away from Google to Amazon, from Twitter to Facebook, and so on. And slowly a myth develops.

You can call it the "rockstar" myth.

The "rockstar" myth is the idea that the best engineers, marketers, designers, etc. are 10x better than us regular folks, and that these are the only people you need to be working with in a startup in order to ensure success.

But, at a startup, is it practical to focus your time and resources searching for that perfect "10x" programmer?

Wouldn’t you be missing out on working with many amazing people if you limited your options to that elusive "10x" designer that probably already works for someone else paying them much more than you can afford?

Instead, at our company, we evaluate candidates based on:

  1. Do they fit our company’s culture?
  2. Do we have a real need for the person’s talent and skills right now?

However, if we find someone who is an exceptional fit to our company’s culture, we will still hire the person, even if the position isn’t immediately obvious.

"Your goal shouldn’t be to buy players, your goal should be to buy wins."

- From the movie, Moneyball

Myth 8: "Be Miserable Now, So You Can Enjoy Your Life Later"

Another key misconception about working in a startup is that it involves sacrificing a few years of your life so you’re able to sell your company for a good profit and then live happily ever after.

You don’t need to sacrifice your health and happiness when you work at a startup.

A lot of our values and work at Buffer evolve around happiness. Everyone on the team has a daily call with another team member to discuss his or her daily improvement towards increased happiness, which I believe is important in maintaining a high level of productivity in our company.

"Instead of wondering when your next vacation is, you ought to set up a life you don’t need to escape from."

- Seth Godin, American entrepreneur, author and public speaker

Myth 9: "You Launch Lean, And Then You Can Build Things the Old Way"

So, you’ve read and understood Lean Startup. You decide you’re launching lean with your MVP until you find product market fit, doing all the customer development you can. And then you stop and revert to the "traditional" way of running a company when you’ve gotten a bit of a foothold in the industry.

That’s what we did near the beginning of our startup journey.

Instead, I think being lean should be a continual process, even well after you outgrow the title of "startup" and become a mega-huge company.

The most impressive case study of this is Eric Ries’s (the pioneer of Lean Startup) own company, IMVU. The company’s clear focus on lean throughout all processes is something we try to see as an amazing example to follow at our startup.

Myth 10: "You Can’t Share Numbers or Sensitive Details"

Another myth that we strongly aim to work against is that, as a startup, you have to keep your numbers under the hood.

After all, you’re a small company and if you share your innermost secrets, the competition will crush you!

We found the opposite to be true. We openly shared how we met each of our investors, how much revenue we are generating and have plans of turning into a full-fledged Open company over the next few months.

I believe that being transparent and sharing our progress has helped us gain goodwill with our users and also within the industry.

Your Turn

I’m sure that you could come up with lots more myths and misconceptions about startups.

Share your thoughts and experiences on the subject.

Related Content

About the Author

Leo Widrich is co-founder of Buffer, a better way to post to Twitter, Facebook and LinkedIn. He also blogs about insights on lifehacks, business and productivity on the Buffer blog. You can say “hello” to him on Twitter @leowid (he is a super nice guy).

August 23 2012


Tips for Building Trust with Your Clients

Advertise here with BSA

5 Tips for Building Trust with Your Clients

Trust is an important component of any relationship. When it comes to freelance work, trust can encourage a client to want to work with you again.

My software firm has billed over 30,000 hours in the last 12 years. In that time span, I’ve had to learn how to earn and maintain the trust of our clients in order to keep them coming back.

I’m certainly not a business expert. I’ve made some horrific mistakes and have had my fair share of struggles. I write this article in the hopes of sharing some of my experiences with you.

Why Returning Clients Are Good

Maintaining your existing clients is great for many reasons.

Having already worked together, you now know more about each other, which helps in any sort of cooperative situation. You have a better understanding of what they’re looking for when it comes to project deliverables, you know what times they’ll likely be available or when they might be out of the office, and so on.

And, if you’ve decided to continue working with a client, chances are good that it’s because you enjoy working with them.

In addition, working with the same client enables you to bypass many one-time tasks (such as initial training and education on your project management system and development processes), thus saving you time and resources.

A long-term client relationship often starts with trust. A client will most likely want to continue working with you if they believe in your capability to deliver the product they need.

Tips for Building Trust with Your Clients

Now that we’ve discussed some of the benefits of keeping your existing clients, what follows are some of my tips for building trust with them. These tips have worked for me in the past, and I hope they work for you too.

Let Your Clients See Your Kitchen

When was the last time you’ve seen a restaurant’s kitchen? We can all guess why it’s not common practice to let restaurant patrons see the backend of a restaurant. What if there’s food on the floor, or a cook forgot to wear a hat or hairnet?

But imagine walking into a kitchen and seeing that it was spotless. You would most likely trust the quality of their food, right?

Being maximally transparent also keeps you on your toes, operating at the highest-quality capacity possible at all times, knowing that your customers can walk in at any time.

If you have an office, invite them over during work hours.

Screen-share with your clients. Show off your development tools and new hardware (if they’re interested).

You can use a project management system like Basecamp that lets clients view the tasks and milestones related to their projects.

Be as transparent as you possibly can with your operations. It builds trust with clients by showing them that you’re upfront about the work you do and that you take pride in your behind-the-scenes production process.

Show That You Care About Their Expenses

Establish a relationship where your clients see that you’re being a custodian of their expenses. Show them that you care about spending too much of their money.

Even if you stand to lose a bit of billable hours yourself, be vocal about something you think isn’t worth the development costs. If they request a feature that you know won’t move them forward with their goal, or might even be detrimental to it, tell them why and also recommend better options (even if the option is to scrap the feature).

Sacrificing billable hours for the benefit of your client’s project will go a long way to building trust. This will not only lead to a better product that you can proudly display in your company’s portfolio, but also says a lot about how much you care about the client’s success, which is a compelling reason to continue working with you.

Learn About Their Business

You want your clients to view your work relationship like a partnership. By knowing as much as possible about their business, you stand a better chance of creating a better product for them.

The more you know about their business, the more they’ll feel that you’re a part of it, and the more likely they’ll be encouraged to continue working with you.

You can ask them to walk you through a typical day in their office.

Ask them if there are any particular pain points that they think you can solve.

If possible, try out their company’s products or services to see how they work and to experience how it is being their customer.

Being knowledgeable about your client’s business will give them confidence in the products you build for them.

Substitute "We" for "I"

Another way to make your client feel that you’re part of their business is by using "We" instead of "I". It’s a simple substitution of a pronoun that displays your vested interest in their project.

  • "Well, we could try that and see what happens."
  • "If I recall, we wanted that call-to-action on the top right of the layout."
  • "How many unique visitors did we get on the first week?"

Be Honest At All Times

If you play games, you’ll get caught.

For example: Don’t pad hours when you feel you’re working extra efficiently, and take away hours when you feel you aren’t at the top of your game. Be accurate when tracking your billable hours. You can use software like Billings, FreshBooks or EnterYourHours (Full disclosure: I’m a founder of EnterYourHours) to track your time (as well as invoice your clients) as accurately as possible.

A client will see genuine honesty. They’ll also see if there’s something fishy going on.

What Are Your Tips for Building Trust?

If you have tips on building trust with your clients, please share them in the comments.

Related Content

About the Author

Aaron Korff is the president and founder of Vazkor Technologies, a custom software development firm. He’s also the co-owner and founder of, a commercial time and billing software system. Connect with him on LinkedIn.

August 22 2012


Why You Should Lead with Mobile Web Apps (Not Native Apps)

Advertise here with BSA

Why You Should Lead with Mobile Web Apps (Not Native Apps)

Based on my experience, when you’re developing apps for multiple mobile device platforms, there is a huge advantage to having your HTML5 mobile web developer lead the production effort as opposed to your native app developer (e.g., iOS, Android, etc.)

In this article, I’ll share my thoughts and opinions on why building mobile web apps first is a good strategy.

A Bicycle Racing Analogy

In team-based bicycle racing, riders from the same team often form a group called a peloton to protect the team leader from wind resistance.

New Zealand Team PursuitImage credit: "New Zealand Team Pursuit" by Velo Steve

A well-formed peloton uses domestiques (supporting team members) to protect its leader from wind drag, thereby saving him energy and giving him a better chance of winning the race.

Product managers tasked with delivering both mobile web and native apps will be able to work most optimally by arranging their teams into pelotons that can move products forward more quickly and efficiently. (Read about the differences between mobile web and native apps.)

Positioning your HTML5 mobile web developer as the primary domestique (flanked by UX design and UI design) is the best way to cut through the "wind resistance" of developing for multiple mobile platforms.

Cycling in the Wind

Most startups engaged in the Mobile space are focused on developing apps that run natively on iOS, Android or both.

Expressing your idea as a native application gets you reliable access to push notifications, the user’s address book, precise geo-location, the device’s camera, etc.

For all of the success that can come from releasing a native app, they can be challenging to build.

For one, talented native iOS and Android developers are in relatively short supply right now. If you’re in a position where you must contract a native app developer, you’re probably spending a premium for each hour of development.

Native app development can also be particularly slow if you’re iterating on a product concept. Seemingly small customizations of a UI control can turn into an extended effort. Requesting new navigation paths or revisions to previous design decisions may have serious time implications and incite frustration within the team.

I’ve seen wind resistance in mobile app development from a variety of sources, both in our startup (Gliph) and in projects for Fortune 500 companies.

  • Product managers iterate quickly and may shift between ideas for the user experience.
  • User feedback on a production release may cause tasks to suddenly be reprioritized.
  • Each change of plan may drive new backend requirements and redevelopment.

When your native app developers are leading your peloton, you risk tiring them out by exposing them directly to all of that wind drag.

If you want the native app experiences to be the centerpiece of your product, you need to conserve those riders’ energy.

Leverage Your Domestiques

The product manager, mobile web app developer, UX designer and UI designer work together as perfect domestiques for cutting through the wind resistance of multi-platform mobile app development.

Working together, these folks can rapidly prototype and refine features. They can play a crucial role in uncovering issues that would affect native app development.

For example, suppose you want to implement an app feature. This feature generally starts as a wireframe or a high-fidelity prototype. Typically, these flat images would be handed over to a native app developer. She would be expected to work directly with the UI designer and server-side web programmer to get the assets and services she needs. This may lead to loss of valuable native app development time.

A completed mobile web app serves as a practically complete, very concise specification for native mobile app developers. It acts as a living example of exactly how a feature set is supposed to work, and ensures services are hooked up and ready to go.

Bumps in the Road

Bicycle races vary by course, and so do mobile apps. HTML5 has come a long way in bringing smartphone functionality to mobile browsers. However, in some cases, it won’t be possible to fully prototype and realize your product in mobile web. For example, you may need to simulate the camera on desktop web by allowing Shockwave-assisted image uploads.

It may be hard to deliver a mobile web app that is similar to a native app experience. For example, native app SDKs usually include things that speed up development time, which you may have to build from scratch if you were to do the same thing in mobile web (though HTML5 mobile web app frameworks like Sencha Touch does even out the playing field quite a bit). As a result, there may be certain features your mobile web app developer is unable to build significantly faster or cheaper than your native app developers.

Communication between your team members is critical when moving from a feature created in mobile web, into a native app implementation.

Project managers must not only track the progress of the leading mobile web app effort, but also ensure the native app team is keeping pace.

Championing Mobile Web

For all of the hype around native app development, a robust mobile web app implementation has never been more important than it is today.

At our startup, we’ve found mobile web development not only protects native app development from headwind, but also gets out in front of the pack to explore the racecourse ahead.

Native app development for iOS and Android is currently the most expensive and difficult-to-recruit resource in the Mobile space, based on my experience.

That isn’t to say a great mobile web app developer is easy to find either. The critical role they can play in successful rapid mobile app development should not be overlooked.

Protecting native app developers from wind resistance can allow you to advance the most important parts of your mobile product faster and more efficiently. When directing the creation of a multi-platform mobile app project, cut through the drag by keeping track of your product leaders and forming a peloton to protect them.

Related Content

About the Author

Rob Banagale is Co-Founder and CEO of Portland, Oregon-based privacy startup, Gliph. He’s also a mobile strategist who specializes in mobile product development. If you’d like to connect with him, follow him on Twitter: @jetsetter.

July 24 2012


Working on a Team as a UX Designer

User-centered designers aren’t just professional learners; they’re teachers, too. Our job is to reflect what we know while adopting the language of our end-users. This changes our team’s perspective which, in turn, affects its ability to solve design problems. Four ways that I’ve found effective to that end include: learning, brainstorming, (shifts in) perspective, and momentum.

When I was 11, my mother petitioned the local school board to advance my twin brother and me two numbered grades – sixth to eighth – in the middle of the school year. After months of discussion and debate, the board eventually acquiesced. One week we studied with our usual cohort and the next we were thrust into an environment wholly unfamiliar to us.

Kids in a classroom

History and English were the easiest to “get:” they were essentially classes in rote memorization. Science proved more difficult. Our eighth grade teachers introduced us to biology, geology, and chemistry. Hard sciences, indeed.

Mathematics was most the formidable, though. In my sixth-grade Arithmetics class, we reduced fractions and solved elementary functions. In Algebra, we sought answers.


I joined my eighth grade classmates at the precise moment when our Algebra teacher introduced Linear Equations. With it, we met a number of different concepts:

  • Cause and effect. In Algebra, X and Y were “variables” that could be related by something called a “function.” Any change in X resulted in a change in Y.
  • Change over time. The mathematical unit for change was called “slope” or “rise over run.”
  • Line graphs. Graphs facilitated spatial reasoning and reminded me of the old adage about a picture’s worth.

I’ll be honest: Algebra was really difficult for me. Not only because it was part of the “advanced” math program at my school (adding insult to injury) – it was an entirely new way of looking at the world. Variables? Functions? Change? I lost a lot of sleep.

As a class project, students were asked to prepare a “book of linear equations.” The idea was that, in creating and presenting their various books to the class, students would become better acquainted with the material it contained. It was a concept I was quite familiar with after several years of public schooling. The strange thing is this time it actually worked. After interpreting the material in my own words, I better understood what Linear Equations – what Algebra – was all about.

Learning is, almost by definition, a humbling experience. When we learn, we admit to ourselves that we aren’t “right” and that we don’t comprehend something as well as we could. Learning can apply to social systems (a.k.a “groups of people united with a purpose,” a.k.a your team), too. However, unlike conferences or classrooms – where people come together in order to learn – learning in the context of a social system can have unexpected consequences. Political scientist and thinker Donald Schon explains these in his book Beyond the Stable State:

The power of social systems over individuals becomes understandable, I think, only if we see that social systems provide for their members not only sources of livelihood, protection against outside threat and the promise of economic security, but a framework of theory, values, and related technology which enables individuals to make sense of their lives. Threats to the social system threaten this framework.

Donald Schon, Beyond the Stable State

Anything that challenges the values of a social system – teaching, for example – can incite what Schon calls dynamic conservatism. In other words, it’s difficult to get groups of people to change their mind.

If my entire undergraduate career in Mathematics taught me one thing, it was that although change is easy to model, it’s incredibly difficult to affect. Numbers are a great tool for modelling things, for measurement, but they tell us nothing about the ways in which (groups of) people think or act, nothing about how we might change their frame of mind.


But things are always in flux, right? Time inevitably passes so that the only constant we have is change. Design is simply the actions we take in preparation for change.

Brainstorming is a creative exercise that encourages people to suspend their judgement in order to conjure up solutions to a particular problem. It’s a technique often employed throughout a design project that bears much in common with improvisational theatre.

Say you’re Wufoo; you’ve got over 11 links in your header. During a brainstorming session, someone on your team suggests removing the Blog link. This person explains that users of Wufoo click the footer’s Blog link five-times-more often than the header’s. While it’s easy to see the fruits of this kind of labor – if you remove a link, it’ll make things cleaner – it’s what you don’t see, the assumptions guiding the exercise, that are arguably more important.

It’s quite possible, for example, that your team ignores a fundamentally better design. This happens because of what an ex-colleague of mine calls “being pickled in the brine.” After months and months of working together, team members form shared value systems. They see the world through the eyes of their peers so often that the suggestions they make today are not only informed by the suggestions their team made yesterday; they’re valued against them. If someone’s unspoken proposal seems superfluous when valued against the shared value system in which they reside, they’ll often (subconsciously) stifle it.

It’s an oft-misunderstood dynamic. While brainstorming provides a perceived “freedom of choice” to its participants, it’s likely not the same breadth of choice visible to someone outside of the system. This simple fact makes consulting possible.

In order to yield a better design, user-centered designers must facilitate new, shared experiences that form the basis of new value systems.


Artifacts of design carry with them an amazing capacity to impact the way we think and reason. Inventions such as Facebook, Twitter and Google – and, before them, Television, Radio, and Print – provided new ways for us to communicate with one another and, as a consequence, new ways to see the world. This might seem obvious, but that’s only because value systems are difficult to unlearn. For those of us who’ve grown up accustomed to modern communication technology, it’s difficult to imagine a time before these technologies existed.

Despite this, author James Gleick attempts to do so. In his latest book, The Information, Gleick tells the story of the human race as it’s adopted and adapted new communication technologies. Regarding the invention of writing Gleick says:

In our world of ingrained literacy, thinking and writing seem scarcely related activities. We can imagine the latter depending on the former, but surely not the other way around: everyone thinks, whether or not they write. But Havelock was right. The written word – the persistent word – was a prerequisite for conscious thought as we understand it.

James Gleick, The Information

This is an important point: before writing, thoughts could only be verbalized if they were to be shared. The invention of writing afforded us a prodigious capacity to capture and document; to share and scrutinize not only own own ideas, but the ideas of others as well. Things that aren’t documented – say a hallway meeting or a Skype chat – lack weight if they aren’t written down. It’s the same reason why my Algebra teacher asked us to create a book of Linear Equations: to facilitate conscious thought.

I began work with a startup early last year on a particularly thorny design problem. Before hiring nGen Works, their team had collaboratively designed and developed two different approaches to their application over the course of nearly 18 months. None of them worked. Carl Smith discussed the project at length with the stakeholders and, having decided that they had the capacity to learn, we agreed to work together.

In the usual user-centered design way, I began the project by listening. What expectations did everyone on the team have? What’s considered valuable? or not-so-valuable? Every time I had a conversation with a member of the team, I added it to an ongoing project journal:

For the first month of the project, I took 45 minutes each Friday to review what was said, what was implied, and where the team thought the project was going. What I learned was this:

  • Everyone had different assumptions.
  • Everyone had different priorities.
  • Everyone had a different idea of what we were building.

The first two issues were easily remedied: more communication (more of the same) would shed light on people’s assumptions and motivations. But the third? How could everyone have a different idea of the system being built, especially after 18 months? I began work on a concept map (something different) that pieced everything together:

It evolved over time into this:

I claim no talent as an illustrator and, thankfully, aesthetic appeal is not the point. Concept maps facilitate visual thinking. After presenting this diagram to the team, we began a new kind of conversation about the models behind the system, how things fit together, and what individual screens of the application really meant in concert with one another. This wasn’t the first time a diagram has helped me clarify things: a line graph was infinitely more intuitive to me than a pair of variables for learning linear equations, for example.

As user-centered designers, it’s our responsibility to constantly learn, assess, and represent (literally re-present) the context in which we’re designing.

At their core, designers are learners as well as teachers. The design process, for example, is something that’s been intensely scrutinized by designers in our field. We learn from ourselves. We’ve given a ton of thought to the various ways in which we collect and present data, and call them by a whole host of names:

  • Stakeholder Interview
  • Experiential Themes
  • User Story
  • Usability Testing
  • Analytics
  • Remote Research
  • Persona
  • Content Survey
  • Sitemap
  • Page Description Diagram
  • Card Sort
  • Design Dictionary
  • Mental Model
  • User Flow
  • Quick-hit List
  • Design Lab
  • Wireframes
  • User Flows
  • Storyboards
  • Prototypes
  • Photoshop comps

The goal of any of these activities or documents is to facilitate shared understanding: to clarify the solution to a design problem. But many people – especially clients who are new to the world of design – don’t understand how everything fits together. What good is our process if we can’t explain it in a way our clients will understand? To that end, I worked with my friend David Leggett to prototype an online documentation system:

The best part is there’s no boilerplate material here when it comes to “deliverables;” each bucket of deliverables is uniquely tailored to a client’s project. Further, each deliverable is linked to others in a way that helps clients see their relationships with one another. This is much more intuitive than, say, a 36-page PDF that presents deliverables in a linear fashion.

If a user is looking at a mental model:

and clicks one of the user personas at the top:

They’re taken to a screen that helps them better understand that user’s context. To practitioners, this web-based version of deliverables may seem redundant. To clients, it can be much more self-evident. Regardless of how you communicate with your team it’s essential that you do so – with both regularity and variety.


All projects have momentum, the rate at which they progress an idea. In classical mechanics, linear momentum is defined as:

p = m × v

Where p is momentum, m is mass, and v is velocity. I’d like to suggest that this definition can also apply to a creative endeavor. In the world of bits, mass is meaning. As the saying goes, “ideas carry weight.” Because developers call the-rate-of-speed-with-which-they-develop code their code velocity, a project’s momentum could be thought of as the product of its core idea(s) and the team’s code velocity.

Technical definitions aside, if a project “has” momentum, its team works well. A shared set of values pervade every decision. Conversely, if a project lacks momentum, either it’s being coded slowly or the idea(s) behind that project are in flux (or worse, both). Because clients pay for forward momentum, it’s critical that designers help determine the weight of ideas. To that end I recommend a combination of techniques I’ve discussed throughout this article: discovery, documentation, naming things, and availability. Let’s look at each.


Not everyone appreciates healthy discussion. Call it dynamic conservatism or just plain ego, some people have a fixed perspective. This is the bane of consulting. Therefore, an integral part of any design process is a discovery phase, which essentially centers around the following questions:

  • Am I / Are we capable of learning the client’s language? Their business? Their value system(s)?
  • Am I / Are we capable of explaining (teaching) my / our design process?
  • Am I / Are we willing and able to forego certain aspects of the project? my /our process?
  • Is the client willing to explain their value systems in a way that makes sense?
  • Is the client willing to learn more about their design’s context? In other words: are they willing to admit they don’t know everything about their problem?

Answers to these questions are never binary. Instead, they manifest themselves over a period of time. Before committing to any sizeable design project, set aside a small period of time to feel the client out. Ask the client what they’re looking for, make some progress towards that goal, but also explain to the client that you’ll approach their project in an exploratory way. After a month or so, re-assess these questions and see if this project feels like the right fit. For more information on this subject, I also highly recommend Andy Rutledge’s cost of services calculator.


As mentioned earlier, writing affords reflection. Although it’s tempting – and easy to forget – always ensure that conversation comes first. A great rule of thumb is this: don’t speak for people, speak with people. Because writing provides a sense of permanence, people often (incorrectly) believe that just because something is written or published it’s somehow more correct. Baloney. Whenever possible, ensure that documentation reflects the latest conversations you’ve had with your team. Documentation is never specification, just a point of reference.

Naming things

Similar to the concepts discussed in the Brainstorming and Perspective sections, naming gives us the power of distilling something’s essence. One example of this comes from the same startup I mentioned earlier. There, the client had a number of different visions for the mobile component of their application. Carl had the great idea to just call it “snap and send.” Effectively, the mobile app would take a picture and upload it to the website. Easy. After giving it a name, the mobile component of this application carried much more weight. The initiative gained momentum.

Another example of this comes from the movie Fight Club:

It was right in everyone’s face, Tyler and I just made it visible. It was on the tip of everyone’s tongue, Tyler and I just gave it a name.

Chuck Palahniuk, Fight Club

Those of you who’ve seen the movie might recall that, at this point, Fight Club is in full swing (no pun intended). Everyone wants to join. The movement had been around the whole movie, portrayed in counterculture snapshots and Palahniuk’s penchant for violence. After giving it the name Fight Club, though, Tyler Durden’s idea crystallizes and takes on a life of its own.

Make it available

Availability is empowering. Because Google, for example, provides a gateway to a vast amount of information in a fast, intuitive interface, people are empowered to learn new things. In a perfect world, our team’s design environment allows for that same feeling. To that end, consider:

  • Basecamp – If all conversations, deliverables, etc. are documented in one location, it allows your team to access the team’s collective knowledge, instantly.
  • Google Docs – Collaborative editing and commenting, in addition to notification settings, ensures that teams can come together around a particular idea.
  • Office hours – If possible, set aside an hour or two a week to just answer emails and be available for questions. Holding office hours empowers your team to answer design questions.
  • Roll your own – David Leggett and I prototyped a documentation system to explain our perspective on our client’s design problem. This makes a large body of knowledge accessible to a team and facilitates self learning.
  • Sketchboarding – This is essentially the physical analog of the digital documentation that David and I created. Being a tangible artifact gives it permanence and prominence within your office.

Be a good study buddy

Learning is an essential skill for any knowledge worker and, increasingly, we’re all knowledge workers. Designers have a unique skillset that allows them to work within their teams to facilitate both a self-learning and a shared-learning environment. This ensures that the projects they work on move towards the “weightiest” ideas in the fastest manner possible.

The post Working on a Team as a UX Designer appeared first on UX Booth.

January 19 2012


10 Essential Guidelines for Freelance Collaboration

Advertise here with BSA

Freelance collaboration is on the rise. Increasingly, teams of freelancers are now doing the work that in-house departments used to do. Graphic designers are now working on teams with writers and programmers.

But many freelancers are used to working alone. Collaboration definitely requires freelancers to make a few adjustments.

In this post, I’ll provide ten essential guidelines to help you put the pieces together for freelance collaboration. If you enjoy this post, you may also enjoy reading 15 Questions to Ask Before Collaborating.

Guideline #1: Do Your Homework

In the same way that you would research a potential client, learn all you can about a potential collaborator. Study their LinkedIn profile and other online profiles. Read any testimonials and recommendations they have received to see what past clients think of their work. Review their portfolio to get an idea of the type of work they produce. Remember, if you work together on the same project, your reputation will become linked with that of your collaborator.

Guideline #2: Provide Details

Once you have selected a freelance collaborator, provide them with as many details as you can about the job. Be specific. Remember, if the freelancer is working in a different specialty from your own, they may need entirely different information to get their job done. Give them an opportunity to ask their own questions and make sure that they get their answers. The more your colleague knows, the better able they will be to fulfill their part of the project.

Guideline #3: Use a Contract

Most freelancers understand that it’s important to get the terms of an agreement with a client in writing, preferably in contract form. However, when the project becomes a collaboration you now have an additional agreement to consider. First, there’s the agreement between you and your client. And second, there’s the agreement between you and your fellow freelancer. The second agreement should be handled as carefully as the first–get it in writing.

Guideline #4: Take Advantage of Online Tools

There are many online tools that can make managing a group project easier. Take advantage of them. Don’t try to reinvent the wheel and create your own online tools from scratch. This will only eat into your project time and cause additional frustration. Here is a list of collaboration tools, but there are many others to choose from.

Guideline #5: Designate a Lead

Whenever a group is responsible for a project, someone needs to act as project lead. If you’re the project lead, your job is to make sure the project keeps moving forward and to coordinate all the various players. If you’re not the project lead, your job is to make sure that your parts of the project are on schedule and make the leader aware of any needs that you have to get your job done.

Guideline #6: Exercise Respect

Be sure to show plenty of respect for your freelancing collaborator. Remember, you hired them because of their skills and abilities. Treat them like the professional that they are. Don’t try to rush them unnecessarily or underpay them for their part of the work. If credit is being given for the project, make sure that their part is acknowledged. Your goal should be to make working on the project a positive experience for both of you.

Guideline #7: Communicate Well and Often

Adding another person to a project adds a whole new dimension. Now, not only must you communicate regularly with the client, you must also communicate regularly with your collaborator. You may even need to schedule meetings from time to time. Good communication is an important part of a successful project. Allow for some extra time in your project plan to answer additional emails and phone calls.

Guideline #8: Keep Adequate Records

All freelancers should keep good records. After all, when you freelance you are basically running a small business. All businesses need good records. However, when you collaborate your recordkeeping impacts not only your own business, but that of your collaborator. Make sure to keep copies of all records that pertain the project including meeting minutes, important communications, project expenses, and any payments made.

Guideline #9: Pay Promptly

If the client is paying you a single flat fee for the project and you are responsible for paying the team members, be prompt. Don’t make your fellow freelancers wait to get paid for their part of the job. Nothing can sour good morale like late payments. Besides, you like to get paid on time for your work and so do your colleagues.

Guideline #10: Be Open to Feedback

Feedback is an important part of any project. No matter how well the project went, there is always some room for improvement. Ask for feedback from both your fellow freelancers and your client. Also, make sure to pass along any relevant feedback from the client to your team members.

Your Turn

Have you been collaborating on projects with other freelancers? Add your own tips and suggestions in the comments.

Image by Genista

Advertise here with BSA

January 10 2012


Bunker App Giveaway: Manage projects and invoices

It’s that time again… Giveaway time! I love a good project management software, especially trying out new ones. Recently, one that has caught my attention was Bunker App.

Being the nice folks they are over at Bunker App, they’ve decided to give away eight (8) one-year subscriptions for free.

For those new to Bunker App, it’s a project management software with sleek, minimalist interface. Tasks such as project management, time tracking and invoicing clients is intuitive. I particularly enjoy the unique URLs invoices create to send to clients. It’s also web-based, so everything is on the go and where you need it.


In order to win, tweet about this giveaway with a link to this post and the hashtag #bunkerapp (the hashtag is important as this will be how we’ll be tracking entries).

Here’s a sample tweet: (feel free to copy and paste if you like)

Free project management giveaway: @behoff is giving away 8 free subscriptions to @bunkerapp #bunkerapp

I’ll be selecting eight people by random at the end of tomorrow (January 11th). Jump to it.

December 14 2011


Should We Always Deploy Content Management Systems?

Advertise here with BSA

Should We Always Deploy Content Management Systems?

Content management systems are a wonderful tool for empowering website owners. Most of us have witnessed the power and ease of use of CMSs like Drupal and WordPress. They have changed the web development industry in a significant way.

Now, even average Internet users who have very little technical knowledge can have the ability to run and manage websites without any help from trained web developers.

Because of this CMS revolution, a major segment of the web development industry — dedicated to developing simple to complex CMSs for a broad set of users and premium themes for popular publishing platforms — has blossomed.

There are quite a few benefits to developing a site powered by a CMS. Chief among them is that the website owner is able to add and manage their website’s content, thus keeping visitors interested and search engines tuned in. And for the web professional, he has much less responsibility in maintaining the website.

But is empowering the business owner with a CMS always the way to go? Sometimes leaving tasks such as website maintenance and system upgrades to a professional leads to better results for the owner.

To explore the question of whether or not we should always deploy content management systems for our clients, let us first go through some types of clients who would not fully benefit from them.

Owners of Static Websites

Not all websites have content that constantly changes. Websites for small- to medium-sized businesses and brochure websites that provide relatively static information usually require only a few changes throughout the year, such as when featuring a new product or making an event announcement.

The brochure website of Pic Fresh (a catering company) has information that changes infrequently.

These websites just include an overview of the business, a presentation of its products and the company’s contact information. We see this with restaurants, small shops and local organizations (such as a non-profit animal shelter’s website).

Such business owners usually have a small budget, so the extra cost of a CMS might be unnecessary if they don’t use it to its full potential. Asking a professional to make a couple of changes per year could be easier and cheaper.

Owners Who Don’t Want to Be Empowered

When I entered the Web industry, I assumed that every business owner would absolutely want a CMS to manage their content. But then I had a string of clients who made it clear that they wanted absolutely no involvement in technical matters or that they would just rather a professional maintain their website after launch. This is when I decided to cater my services to this category of clients.

Some clients simply don’t want to be empowered for various reasons; whether it’s because they’re not the best of friends with technology or they just don’t want to add to their existing workload and responsibilities.

By hiring a professional, clients that fall in this category feel more confident in the changes being made to their website and they have one less thing to worry about.

Many of my clients have told me that it’s like hiring an accountant to manage their finances or a secretary to manage the office; the work is done more efficiently, and the owner has more time to focus on their field of expertise.

Owners of Websites with a Shelf Life

Some websites have an expiration date. These usually support an event, such as a conference, a cultural event or a promotion of a special deal on a product. The website promotes the event ahead of time, stays up during the event and a little while afterwards.

The single-page promotional site for a 2009 event, HDLive 9 ( would not fully benefit from a CMS.

Projects like these require heavy maintenance for a short period of time (several months to a year), and doing it efficiently is critical. The event’s organizers will be preoccupied with planning the event and reaching out to participants through newsletters, media, the website, email, etc.

Hiring a web professional, then, is much easier, if not essential. Empowering such a client with a CMS would do them little good.

Owners Who Rely on a Web Professional’s Expertise

We have all come across websites maintained by people who don’t follow any design or usability principles. And preventing a hapless owner from ruining their own website is difficult, which is why we so often see links in multiple colors, excessive use of bold and underlined text, mixed font families, body text the size of headings, images squeezed in here and there, navigation menus that pop out of their containers — the list goes on.

The truth is, when we let non-technical website owners maintain their own Web property, we can’t expect them to adhere to the rules of aesthetics and usability, simply because it’s not their job to know these rules.

The moment the owner takes over their CMS, we should expect that the beautiful and functional website we so painstakingly created will start to look a tiny bit (or a whole lot) less perfect. This isn’t a big problem for every website, but some websites rely a lot on detail and uniformity of content.

Poorly styled text, for example, might not look so bad on a teacher’s blog where visitors mostly seek specific information, but it can be a disaster on the website for a new fashion line where users want to get a feel for the company before browsing the collection.

Empowering owners of websites that fall into the latter category is questionable.

By the way, some Web professionals worry that a deterioration of their work will reflect poorly on them when potential clients visit their portfolio. The potential client might be impressed with a screenshot in the designer’s portfolio, but then be surprised when they click through to the actual website. For this reason, mention whether you or the owner is currently maintaining a particular website, so that potential clients are not caught off guard.

Website Maintenance as a Service

Now that we’ve gone over some examples of business owners that wouldn’t benefit from a CMS-driven website, let’s now talk about what we can do to fulfill their needs.

For site owners that don’t need a CMS but would still like to have a site that’s taken cared of, we can offer them website maintenance as a service.

The following are some benefits that come with offering website maintenance as a service.

Extra Income

Maintenance is a paid task, and you can increase your income a little or a lot, depending on:

  • The difficulty of tasks that are requested
  • The frequency of updates
  • The number of websites you’re maintaining

Keeps Existing Clients Close

Providing website maintenance as a service strengthens your relationships with clients. Not only will you be at the top of their mind by providing long-term quality service, but you’ll also get to follow their business as it evolves. This will make you a prime candidate when they have a new project.

Promoting your services also becomes easier, e.g., when creating a mobile version of the website, or redesigning for a small discount.

Easier Upgrades

As with every technology, websites get rusty over time. A client might want to add features down the line. Adding code and updating site features will be easier if the code and product are your own. If the client has meddled with it, upgrading could entail a lot more work.

Before You Offer Website Maintenance as a Service…

The main disadvantage of maintaining websites is that it can really fill up your schedule. In case you decide to add this to your roster of services, be clear about the following.

What You’re Charging

I suggest that you offer maintenance only to customers who have been pleasant to collaborate with and who don’t give you trouble with payments. You can charge by the hour or by the amount of work done.

Overcharging can scare clients out of requesting changes, so be careful with your pricing. A website maintenance plan is a sensible approach. For example, a customer could prepay for a three-hour maintenance plan, which could be spread out over several updates during the year, equaling three hours of work for you. Or it could be a casual maintenance plan; for example, one new page of text and five new photos per month.

Here’s an idea: You can bundle these website maintenance plans as part of a new project.

What the Deliverables and Terms of Services Are

Draw a line between maintenance and redesign. Be clear on the definition of website maintenance. You could allow for minor new features, such as new icons or a fancier photo-gallery script or a new color for links. But draw the line when a request looks like a big change. You wouldn’t want to end up doing a redesign by making hundreds of gradual little changes.

Expected Delivery Time

Website maintenance work should be scheduled so that you don’t fall behind on other commitments. Ask clients to inform you of requests ahead of time (for example, an email one week in advance).

Also, give yourself enough time to fill the request so that it doesn’t interfere with other projects. My current arrangement with clients is to fill casual requests within five working days and to perform urgent updates within 24 hours. This can vary according to your own capabilities and priorities.

To Empower or Not to Empower?

The answer to that question depends on the type of client and website you’re dealing with. Empowering the owner to maintain their website is great as long as it’s worth the cost of implementing the CMS, and as long as they feel comfortable doing it.

Present the client with both options, and explain the reasons for opting for one choice over the other. Some websites absolutely need to be maintained by the owner, while others are best left to professionals. Some websites can go either way, in which case the client’s preference could be the deciding factor.

Last but not least, if you’re not willing to maintain websites yourself or are not willing to let clients do it, let potential clients know this in advance. And don’t recommend one approach over the other merely because you don’t want to offer both solutions. You shouldn’t feel inadequate for preferring one method to the other. Rather, try to excel in the services you offer, focus on your target market, and keep your clients and the Web happy!

How do you handle website maintenance? Do you use one approach over the other? What are your clients’ preferences? Share your strategies and thoughts in the comments.

Related Content

About the Author

Maria Malidaki loves creating and managing websites, focusing on clean and simple design primarily using semantic HTML/CSS. Planning to also work as a vet and researcher, she specializes in building the web presence of academic and scientific events. Keep in touch with her on Twitter @mthunderkit and at her professional website at

December 13 2011


…And another ‘Solo’ Project Management giveaway!

A few months ago the fine folks over at Thrive gave away 5 free year-long subscriptions to Solo, an all-in-one project application which helps freelancers make “more informed business decisions.”

The last give away was such a hit, we’ve decided to go one more round of 5 free subscriptions! Note, that this competition is intended for new customers only. Unfortunately existing Solo subscribers may not enter.


In order to win, tweet about this giveaway with a link to this post and the hashtag #thrivesolo (the hashtag is important as this will be how we’ll be tracking entries).

Here’s a sample tweet: (feel free to copy and paste if you like)

Hot damn, @behoff is giving another 5 free subscriptions to @thrivesolo for your freelance management needs #thrivesolo

I’ll be selecting five people by random at the end of tomorrow (December 14th). Happy Holidays to all!

November 23 2011


6 Web Apps To Manage Team Collaboration More Effectively

There are many collaboration web apps out there for business users, but getting by free and good ones is not that easy. That is why I am sharing 6 Web Apps To Manage Team Collaboration More Effectively. Read each entry in the list and see which one suits your needs best.

You are welcome if you want to share more collaboration web apps that our readers/viewers may like. Do you want to be the first one to know the latest happenings at, just subscribe to our rss feed and you can follow us on twitter and follow us on Digg as well to get updated.


Binfire’s collaboration tools are dedicated to creating multiple communication, sharing and interactivity opportunities between users to enhance productivity. They keep you up to date and in the loop.


Webplanner is an online collaborative project management tool. Brainstorm goals, obstacles, and tasks with our easy-to-use planning wizard. Next, work out scheduling with your team in a click-and-drag Gantt chart.


Otipo is a web-based application which provides a new and fun way for scheduling shifts. With Otipo, all the required information is in one place, and all the team members can access it from anywhere, anytime. It’s time to say goodbye to the pen and paper and let Otipo schedule like a pro.


Cohuman is ideal for any group of people that needs to communicate more dynamically and effectively than email or traditional collaboration tools will allow. Startups, Distributed Teams, Small Businesses, Deal Teams, Departments in larger organizations… in short Cohuman is for any group that requires a solution designed to coordinate people and manage projects more intelligently.


Manage your projects in an agile way, create user stories, sprints, assign tasks to your team members. Scrumrf has only the necessary functionalities to manage your projects, sprints, tasks, and people involved. You can also collab with your team members in your daily work, know who is doing what, comment tasks, sprints, user stories.


ideapi allows you to create briefs, proposals and documents quickly, share them easily with your team and/or clients, work together to create better content and share ideas.

Brought To You By

Premier Survey
Do you want to advertise here? Click to get more info…

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...