The Superawesome Playbook.

What's this all about?

This guide is primarily meant for new and existing employees, but at the same time we want to give anyone that may be interested a glimpse into what kind of a company we are, and perhaps more importantly what kind of company we are trying to be.

Needless to say, this document is not finished, and it most likely never will be. We plan to add and remove from it as we go along and learn.

✌️

What kind of a company is Superawesome.

First of all, what is Superawesome? Well, the name is tongue-in-cheek, of course. It was chosen as a reminder to never take our work too seriously. As makers of things it's really important to be able to — as well as know when to — be careless and bold.

At Superawesome we create things. Mostly for screens. Some of us design these things, some make them functional so other people can use them, some are so awesome that they can do both! However we don't like calling ourselves “creatives” because we believe it is a term that implies that there are people in this world who are not “creative”, which is complete and utter bullshit.

In essence, we are a service provider to people and companies who can't do what we do.

As a design team, we have the power to provide tremendous value to our customers' products, and impact their business in a meaningful way. Sometimes they use us as a simple service provider without a deeper relationship, and sometimes we are their entire design department.

We strive to maintain the image of a reliable, affordable partner. It's something we've been cultivating and nurturing for years.

We are not in the design business. We are in the service business.

Our customers already know they will get quality design work when they hire us — that's a given. It is the service that they get along with the deliverables, that sets us apart.

How we do things

We like to think of Superawesome as a company that values people most of all. Sure, profits are important — this is a business — but we do our best to make the people that make up this company feel as good as possible about working here.

And we're not talking about the fancy perks and whatnot — although we do have some — it's the sense of belonging and being able to enjoy your work, grow professionally, and contribute to something greater than something you yourself could singlehandedly create.

Your work and its effects on our customers and our company respectively, will always be the thing that will be valued the most.

When we started in 2007 we didn't know what kind of a company we will be, but we knew what kind of a company we definitely didn't want to be.

Here are some bullet points that we use in order to sum up our company:

  • As far as rigid procedures, rules and policies go, you won't find any. What you will always find is advice.
  • There is no corporate ladder here, but you can definitely choose how you would like to grow within the company. Keeping things flexible while we can is what we plan to do. These are some of the best perks about being a small company.
  • The company is set up so we don't have managers per se, but we're really not a flat organization either (a meritocracy, they call it). It's more about finding your place where you will be able to contribute the most, rather than wanting to be in control.
  • Outranking someone is not something you should strive for if you work here; leaders and mentors over bosses and managers, any time.
  • Projects are managed, people are lead.

If there's an analogy to be made here, we like to think of Superawesome as a band . You have your lead singer, your drummer, and your producer, and everyone fills their role within the collective, which is the environment that enables them to create awesome things that exceed their capabilities as individuals.

Superawesome is our band.

Organization and hierarchy.

At the moment Superawesome only employs full time staff, designers and front-end developers specifically. We’re still so small that we don’t have a real need for a managerial layer within our organization, and honestly we like it this way.

We are a company that prefers its employees to be self-managed, as much as possible. This means that they have direct contact with the clients and are hopefully able to manage their own workloads.

Over the years we've learned that entrusting people with a sense of ownership and responsibility, is a much better motivator than having someone telling them what to do, how and when to do it.

Setting up things this way means that employees have direct responsibility towards the clients, and they are free to make up their own schedules with them.

Team organization

The vast majority of our projects require the teams to be arranged according to the type of work that needs to be done. This usually means that — on our side — the project will be lead by a single lead designer who is acting as the primary point of contact. This is the person we all go to when we have questions, and this is the person that is making the decisions for the project.

There is a reason it is the lead designer who is the primary on the project, and it's because that's the person who usually has the most knowledge and information about the project since it is they who will be working alongside the stakeholders from the start.

Of course, sometimes the entire project will be handled by a single person, and no “management” is necessary at all.

Our clients are usually the ones that are orchestrating the projects, and all we need to do is establish a good communication rhythm within our team, in order for things to run smoothly.

Apart from projects, all other matters such as the operations, HR, sales, billing, expensing, etc. are handled by Dragan, and he's the man to go to regarding them.

Communication: voice and tone.

Being humans and all, each of us has different perceptions regarding communicating our actions and expectations. This is even more exaggerated considering the fact that we're working with customers all over the world and they all have different cultural norms of their own.

If you're in doubt, its always better to over communicate, than to under communicate.

While talking to a client, our recommendation is to use the “American” communication style. We don't want to be overly formal, and we don't want someone to think we are impolite. Don't be afraid to crack a subtle joke and lighten the mood every once in awhile, but it is generally a bad idea to get overly chummy with a client. This is serious business™, after all.

If you're asking for something — no matter how trivial or obvious it may be to you — always start or end with a “please”. If you are being sent something (an answer, an asset, etc.) always say “thank you”.

While in Serbian culture the absence of a “please”, or a “thank you” is considered perfectly normal, it can come off as rather impolite to people of other cultures.

Generally, our customers are well aware that there may be a cultural difference when they decided to hire us and will not take offense, but it is always better to be safe than sorry.

Written vs. verbal communication

We always prefer written and asynchronous communication. However, some people don't share our preference and this is why we have to make some rules.

The rules are:

  • email is the primary way of communication,
  • feedback can be given verbally, but must always be finalized in writing,
  • Slack and other IM tools are cool as long as they are not hindering progress on the project, and are used for specific purpose (e.g. sharing inspiration/moodboarding, conversing on a single topic, etc.)

Why email, you ask?

Because we want to have a paper trail of communication, and we don't want to let our clients get the impression that we are available all the time.

Imposing certain limitations will bring order to a project. No one likes being bombarded with unorganized bits of brain dump throughout the day.

Handling crisis situations

It will inevitably come to a situation where you and the client won't see eye-to-eye on something. The most important thing in this type of situation is to distance yourself from your work, and avoid becoming emotional. If they have issues with the work you produced, remember that it's not a personal jab at you.

Most of the crisis situations stem from misunderstanding or under communicating expectations. Always remember that and don't jump to conclusions.

These situations call for levelheadedness more than any other, and it takes a long time to master this fine art. Just remember, it's most likely something stupid, so remain calm, and be proactive about the solution.

Never blame anyone. We can't emphasize this enough. If there's a problem, who cares who's fault it is?

If you can fix it, be the cool dude who steps up. But if you can't contribute to the solution, take the back seat on the conversation.

Lastly, if there's a big crisis threatening to end the world as we know it, call Dragan because he'd like to know early.

Response times and availability

Always reply as soon as possible, and don't let emails linger unanswered. If you don't have an answer for someone, let them know that you have received their correspondence, and you will get back to them when you are able to.

If you are out of office, you are encouraged to set up a vacation responder containing the date range of your absence from the office.

Communication is entirely limited to your working hours, and no one at Superawesome is expected to handle any kind of communication or work outside of them. Since we all make up our hours and schedules, this will obviously vary from person to person, but in general try to avoid being reminded of that someone is waiting for a response from you.

Meetings

Most of our client meetings will obviously require conversational English skills. If your English happens to be poor in this regard, ask someone from the office to sit in on the meeting and translate for you.

Internal communication

While everyone is free to use whichever tool to communicate with their team members, it’s really nice if you’d take notice of their personal preference regarding communication tools. Some people prefer to talk over the phone, others absolutely hate it.

Whatever the case may be, we find that if you follow this guideline, you’ll do well.

Urgent communication:

Phone and SMS are considered personal, and should be avoided for business use at all cost. Consider using them for business only when you can’t get a hold of someone, and there’s a mission critical shitstorm going on and you absolutely need their attention.

Standard communication:

Slack is our official method of communication, and should be your go-to in order get a hold of someone. The good thing about Slack is that it shows a presence indicator, so you know who’s online, hence you know when you can expect a response. Even though Slack is an instant messaging tool, don’t expect a reply right away and give people some time to respond.

At the moment we are using Slack as a chat service, and it's channels are structured like so:

  • _random is used for whatever,
  • designporn is used to share design pieces we like,
  • notifications aggregates Git commit messages from GitLab, no one posts to it,
  • pomocprijatelja is used to seek indirect help from coworkers.

Apart from these public channels we all chat in between ourselves privately. It is always smart to ping someone through Slack first and ask to come over, than to come up to their desk unannounced.

Asynchronous communication:

There’s no better tool than plain old email. In an ideal world everyone would be using timely sent email messages to communicate, and people would respond in a timely manner.

General considerations

While in the office, if you see someone is wearing their headphones, this is a sign that they don't want to be disturbed. They are probably deeply concentrated on their work. Either way, please be considerate when interrupting someone and always ask yourself “can my question be answered by Google” first.

Never let anyone respond to you with a lmgtfy.com link as it is a sure way to expose yourself as an internet n00b, and it will be followed by copious amounts of office banter.

Time off, holidays and vacations.

All Superawesome employees are officially given 20 days of paid absence from work per year, on top of all official Serbian holidays. Should you not have used this allotment, you may transfer the vacation days to the next year and use them by July 1st of the following year.

Everyone is also allowed a day off for “slava” if they celebrate it. If you aren't religious, you are encouraged to consider it as having an extra paid day off.

No one is required to state a reason for taking time off. It's your right to disclose that information at your own will.

When you want or need time off, let Dragan know so he can enter it into the shared calendar.

It is also equally important to let the clients you're working with know your vacation/time-off schedule. Dragan will most likely send an official email to the clients informing them of our collective/seasonal time off, but please be so kind and make sure they are in the loop, yourself.

Taking time off should be no issue unless your projects are under deadlines or in a critical state. It is a big no-no to ask for time off when a project you're working on is in a crisis.

If you don't want to use your paid time off, but need a day off, feel free to ask to take a day off during the week, and come in on the weekend and work it off.

Should you want to take unpaid time off, please talk to Dragan directly.

Holidays

The office is closed on all official holidays, and you can check out this reference about the official state holidays in Serbia.

Hours, worktime and productivity.

Officially, our office is on a Mon–Fri, 09:00–17:00 UTC+1/2 schedule, however we are all free to make up our own schedules in accordance to our preferences and project requirements. If you choose to work weird hours, please consider having enough overlap with your coworkers in order not to hinder communication.

Working from home is totally an option, and if you choose to telecommute — some or most of the time — be extra attentive to what's going on, and be proactive about communicating with your coworkers and clients. Obviously we prefer if you'd work from the office, but we also understand that open-plan offices — such as ours — are not to everyone's liking.

This said, most of our customers are US-based, and this makes communication a bit tricky at times, because we are sometimes an entire day ahead of them. Please take this into consideration, and take appropriate measures when working on projects like these.

Productivity vs. time spent in the office

We perceive “work time” a bit differently to how it is usually perceived.

All we care about is your productive time. This is the time you spend working on projects that we — hopefully — bill clients for.

We call this “producing”.

Considering this understanding of work time, we don't expect people to be productive seven or eight hours a day, but we do expect them to be available for eight hours a day.

There is a lot of stuff that we don't explicitly bill for that needs to be taken care of, your colleagues may need you, etc. That's why being available only during your productive hours is not possible.

In general, we consider 4 hours of productive time per day, the norm. This is also the amount of productive time we take into consideration when estimating project deadlines and their duration.

Compensation.

At the moment Superawesome only employs full time staff, although we are not anti part-time, or anti any other type of setup. If we click with people, we’re willing to find a way to work together.

Salaries

Straight salary

Our full time staff is salaried on a monthly basis, every 1st of the month, sharp. We don’t have an official compensation plan, and each employee negotiates their compensation at the time of hiring.

Variable salary

Some of our staff is compensated on a variable basis, meaning they receive a fixed minimum pay, and a monthly dividend based on performance metrics.

Raises

Each straight-salaried employee gets a 5% raise for every year they are with the company.

It is possible for any employee to receive a raise based on performance, but we don't have a specific plan for that at the moment.

Bonuses

End-Of-Year bonus

Of as we like to call it: Thank-God-It’s-Over bonus!

Each employee gets a bonus 13th salary at the end of the year. In order to qualify the employee needs to have been with the company for at least 12 months prior to December 31 of the current year.

If the employee’s salary is variable, the bonus is equal to the fixed part of the salary.

Project management bonuses

In an effort to promote self-management, we encourage our employees to take responsibility for the production side of their projects, and get a bonus for doing so.

Simply put: you can get a 10% bonus — based on your salary — per project, if you assume the role of the project manager. If you are under a variable salary, the bonus is calculated for the current month.

It’s a completely voluntary decision, and we understand some people simply have no desire to dabble into organizational activities and — ugh — politics. It’s 100% up to you.

The terms under which our employees can become eligible for this bonus:

  1. Must be with the company for at least three years.
  2. There must be at least 10 logged billable hours for the current month in order to get the payout.
  3. Contract duration must exceed 30 days.

An employee doesn’t have to work in production on the project in order to become eligible for the bonus. In other words, you are free to manage someone else’s project and get the bonus. Ka-Ching!

Organizing projects and scheduling.

In the past we were giving it our best to make ourselves as available as possible to our customers which — while good for them — caused chaos on our side of things.

We realized that our mistake was due to the fact that we were giving them the impression that they are the only ones we were doing work for, and that we can give their projects all the time in the world. It caused them to act in a more informal manner when requesting work to be done.

Naturally, this was not the case since we balance many different projects for many different clients at all times. They considered us — and treated us — more like their employees, rather than an agency.

Here are a few examples of this behavior, just so you can recognize it, and act to prevent it:

  • client stumbling through random thoughts of what we could do during a Skype call,
  • client sends long-winded emails with no actionable points or clearly defined next steps,
  • radio silence until the project becomes mission-critical, than everything suddenly becomes P0, etc.

Lately we’ve been implementing various setups of preventing this from happening which has in turn enabled us to form several types of collaboration into which we frame the projects coming our way, and it’s how we set up the projects from the start.

Setup 1: Long-term engagements

We really prefer taking on this kind of projects as it enables us to really employ the power of design towards a real business goal, and affect them significantly. We treat customers with long-term projects with special care, since they are putting a lot of trust into us.

Challenges

It takes experience and patience to be able to work on something long-term. It’s in our nature as designers to naturally want to move on to something new, but these projects require focus and constant output over a long period of time.

Rewards

These projects allow us the rare chance to create design systems and languages, maintain consistency, and control the visual communication within a larger design ecosystem.

Setup 2: Short-Term engagements

We take on these projects mostly to fill the gaps in our schedules. During periods we are fully booked with long-term engagements, we will not accept them.

Challenges:

Working on something for the first time takes a lot of energy and research needs to be done in order to be familiarized with the matter, which is not always possible due to time and budget constrains.

Rewards:

They end quickly and allow you to move on to the new hot thing. One can view them almost as a design exercise sometimes, before getting back to “work as usual”.

Scheduling

No matter how the project is set up, it should have a clearly stated schedule.

Sometimes we like to set it up so we handle the project on specific weekdays, and sometimes we carve out a block of time and work on the project exclusively.

We strongly suggest you take some time at the beginning of the week — or at the end of the previous week — to arrange a work schedule with the client for the following week.

Nothing beats having a clear set of tasks you can focus on, otherwise you are at the mercy of other people’s schedules. Not to mention, “forcing” a schedule on clients makes them more organized as well, which means projects are more organized, and everyone is happy.

The only thing we’re not advising you to do is to wing it when you work on several different projects at the same time. It is certainly nothing that will take the house down, but it does make our internal organization harder to maintain, and takes us back to the situation where the clients are in charge of our time and schedule.

Weekday Scheduling

We stole this one from our friends at Rendered Text. Who knows who they stole it from.

Basically what you do is — depending on outside factors, like time frames, and budget — you map your work to specific weekdays where you will be working on the project. This allows you to focus on the project 100% with minimal context switching, and clearly communicates your availability to the client.

In our previous experience, once set up this way projects need no outside management at all, and friction points are few and far between as expectations are clearly set from the get-go.

Blocker schedule

This type of scheduling is applicable to fast-paced, short-term projects the most. Basically you devote all your working hours to a single project for a period of time; usually 5–10 days. This yields great results for design sprints, and on-site work.

Winging It

Sometimes unfortunately we are faced with exclusive situations where we need to take care of something that can’t be planned for. Maybe there is an emergency on a project we worked on before, and unplanned deadline, or a project is lingering on when it should have been over.

These situations should be handled on a case-by-case basis and you should aim to fit them into your existing schedule as a second priority. If in doubt, consult with Dragan.

Interruptions

On another hand sometimes while working on a larger project, you will get a request from a client that takes a small amount of time (<4 hours).

General advice in this case is to treat it as a distraction and aim to take care of it as soon as possible — we also don’t want the client to want too long for a delivery on a small request — in order to enable yourself to focus back on the work you are spending most of your time on.

Briefs

You should never start working on a project or a task unless you have a written brief. You should ask the client for the brief, and they will hopefully be able to give you one. Once you get one, you will most likely have to massage it into something useful, so ask a lot of questions and edit it into something you can use.

Often a client is not competent enough to write a brief themselves, so you — or the project manager — must do it for them. Ask a lot of questions and put one together.

Always get a confirmation from the client about the brief — in writing (email is fine) — and make sure they are OK with you proceeding to move forward into work based on its contents.

A brief can be a Google/Paper document, a Trello or a Pivotal Tracker card, it doesn’t matter as long as it clearly states the problem to be solved, and contains everything you need to start working on the project/task.

Timesheets.

All employees are required to maintain a time sheet for every projects they are working on. It’s our main method of billing the clients, but most importantly it’s a backup in those unpleasant situations when our productivity is being questioned and we need proof of performance.

For time tracking we are using Harvest, and you should have access to all the projects you are currently working on. If you don't, just ping Dragan as he most likely forgot to create the project or invite you.

We are sending out time sheets to clients for all our projects, and it’s absolutely important for them to be clearly entered and described.

If a description is missing from a time slip, you will be asked about it, and you won’t be able to remember, and that is just a shitty situation to be in.

Harvest tasks

All projects have a set of default tasks you will be logging the time against, and these tasks are mapped to your productivity while performing them, and not to the actual task you are doing.

We are using these Harvest tasks a bit differently, in that we are not referencing “Interface design”, or “Front-End development”, but a certain productivity rate. The reason for this setup is the simplification of logging, and more importantly invoicing.

Productivity multipliers

A while ago we invented a special way to affect our hourly rates in order to be more fair and transparent towards our clients.

Previously we had only one rate per project and logged everything towards it all in order to simplify logging. This made us alter the time slips when we figured we weren’t as productive as we thought we should have been (e.g. “I'll log just two hours for this whole day, I’ve found it really hard to concentrate”).

So now we have three different productivity rates that take three different productivity multipliers:

  • PM 1.0 (default),
  • PM 0.75 (semi-productive), and
  • PM 0.5 (barely productive).

We feel these represent the real-life situation while working on projects more accurately.

Also, these are not always tied to productivity. Sometimes it’s the type of work that will make you log it with a productivity multiplier applied, e.g. when you are working with a new technology, or generally doing work you have little experience with.

Billable tasks

  • Rate 1 (PM 1.0): this is our default task and you will normally be logging everything to it.
  • Rate 2 (PM 0.75): log to this task when you are not being 100% productive (i.e. hungover, have a headache, the spring came, it’s raining outside, etc.)
  • Rate 3 (PM 0.5): use this when you are working on things you have no experience with (e.g. new software, technology, etc.).

Unbillable tasks

  • Personal development: self explanatory, time spent learning something new that you feel shouldn’t be billed to the client
  • Unbillable: self explanatory, things that shouldn’t be billed to the client, e.g. fixing something that was your fault, email correspondence, paperwork, general busywork, etc.

If your project doesn’t contain Rate 2, and Rate 3 tasks, it just means that it was set up without productivity multipliers, and you should log everything to Rate 1.

Things to remember

  1. It’s always wise to use a time tracker — there's one provided as an OS X app by Harvest — rather than going by memory when filling out time sheets.
  2. Track both productive and unproductive time as billable and unbillable tasks.
  3. Always take the time to enter descriptions for your time slips, or log time directly from Trello cards where they are automatically referenced (re. Harvest Chrome extension).

Working with contractors.

Sometimes we employ contractors to help us out with projects. Usually it’s for work that’s outside of our expertise (e.g. programming, complex JS, etc.), but sometimes it’s simply to get us out of a pinch, or because we really want to work with someone who has a certain skill set or a style.

These guys and girls are always brought on, on a per-project basis, which means we are contracting them to do a very specific job. It is extremely rare that we will hire someone and outsource entire UI design, or front-end development. It will usually be just illustration, animation, video, WordPress custom plugin development, etc.

Before we get them on board, we always make it 100% clear to the client that we are involving a third party to the project. Sometimes customers are not comfortable with this because of sensitive IP, or simply because they fear that the project management will become more difficult. This is when we tell them they will need to find someone to do the job.

Paperwork

If the client has given us the go-ahead to bring someone on board as a contractor, there are a few things we need to do before we are ready to involve them into the project.

  1. We need to have a contract signed with them.
  2. We need to sort out how they will be paid.

Contracts

The contract needs to clearly state that Sprawsm doo owns full rights to the work they perform (this is known as “work for hire”), and needs a strong privacy clause.

We can not afford any confidential information to leak out, and we need written proof that they agreed to treat this information with proper care.

Should they want to showcase the work that they did for us, the contract should require them to agree to a notice to be put into their portfolio that the work was performed for Sprawsm doo. This is so we don’t risk the unpleasant situation of a client finding our work in someone else’s portfolio and freak out (it happened).

Payments

We are never marking up our contractor’s services, instead we charge a 10% project management fee on top of their invoices.

Our clients choose whether the contractor will be paid through us, or they will be paying for the contractor’s invoices directly. This needs to be known early on because of the said project management fee.

If we are the ones handling the contractors payments, they need to be able to issue us an invoice as a company, as we don’t do cash payouts.

Briefing

Considering that we have brought on a contractor for the project, and considering they are usually local people it’s for the best if they can get to our office for an in-person briefing and just to get to know each other. If they want to work from our office while employed on the project, that’s great and we should accommodate them as much as possible.

Whether or not the briefing has been done in person or through video conferencing, a written brief should exist as an official document that they will work off of.

Project maintenance and availability.

In general we don’t handle project maintenance, such as CMS updating, server maintenance, etc. unless the client has a signed maintenance agreement with us. Consider that by default we are not worrying about their projects once we hand them over, and they sign-off on them.

Since this is the case, it happens that some clients neglect their websites so much that they get hacked, or defaced. This is when they will call us to fix their problem, and this is where it gets interesting, since this is a highly stressful crisis situation for them. By Murphy’s law, it always happens at worst of times, and it’s always a disaster if it isn’t fixed immediately.

The first thing to do is to remain calm and explain that there is a backup (you do have a backup system in place, right?). We will then give them an estimate on the time it will take for us to restore their site from said backup, and the time we will be able to get to it.

On the other hand, some of our projects are short term by nature, but clients come back from time to time, with new requests for changes and additions to their projects.

These projects are handled on a per-request basis, so that we schedule their work in accordance to our schedule. We give them an estimate based on their brief, and once they green-light it, we schedule it.

Handling feedback.

We don’t expect the stakeholders to know design. However, that won’t stop them from taking the role of someone who has the authority to accept or reject our proposals based on taste and/or their personal preferences.

While this is the case in reality, it is by far our most important task in the design process to establish a friendly, respectful connection between ourselves and the stakeholders. We are the ones who are the professionals, and they came to us for help.

We should be running the show, not playing along.

This means that we need to be inclusive, and aim to learn as much as possible from their feedback because they won’t always be saying the right things, simply because of their ignorance.

Asking the right questions is of utmost importance, and it’s a skill developed over time and through experience.

We will know we haven’t done a good-enough job of presenting our work and the decisions that went into it when we get feedback in the form of a demand.

Examples of client-speak:

Client says:

Can this text be a different color?

Client actually means:

I think there should be more emphasis on this text.

Client says:

Can you make the logo bigger?

Client actually means:

I am afraid our brand is not represented enough.

Always be prepared to defend your design decisions with facts, previous experience, empirical evidence, or most favorably: research as it's something the stakeholders will always lack.

The feedback may come to us in the form of a demand or a request, but we should always challenge it.

Always demand the stakeholders to explain their reasoning for giving certain feedback or request. Not only will this make them think twice about reacting impulsively to your work, but it will let them know that you know what you're doing, and you have integrity.

When we challenge their feedback we can see where it is coming from, and finally decide whether to adopt it, or not. Nevertheless, always aim to get to the bottom of things.

Example counter-questions:

Client says:

Let’s move the sidebar over to the right.

Your response:

The sidebar has been placed on the left-hand side as it contains navigational elements which we wouldn’t want the user to miss. Considering we are working with a western, left-to-right language, the left-hand side is the first thing their eyes will go to when they scan the page.

The reason was most likely:

They saw a site they liked that features a right-hand side sidebar.

Client says:

I don't like the color, can we do something else?

Your response:

This color choice is derived from your branding. Why do you feel it should be changed?

The reason was most likely:

The wife/son/daughter don’t like the color, which is a personal preference, thus not considered valid feedback.

Client says:

I don’t like the font you used.

Your response:

OK. What is it in particular that you don’t like? The size? The feeling it invokes? The color?

The reason was most likely:

They are not tech savvy enough to phrase their question properly, so we need to dig deeper to find out what they really mean.

If the worst come to the worst…

Sometimes though, no matter how hard we try we won’t get the feedback we are looking for. This is a special situation that needs to be dealt with care, considering that the stakeholders are impacting the project in a way we feel is negative.

Without being judgmental or inferring blame, we should explain that we feel that their request is counter productive and goes against our professional better judgment, but we will honor their requests as there is nothing physically preventing us to do so.

In other words: it’s on them.

Should these occurrences happen frequently on a project, it is a clear case of “creative differences” and a sure red flag. We’ve fired clients because of this before, and we will not waste time on people who are looking to use us as their pixel pushers.

Take warning.

In some cases the stakeholder might be right even though their feedback doesn't make sense to us, because of the knowledge of their market that they possess.

Always ask questions in order to find this out.

Handling urgencies.

There is one thing to be said about clients trying to control our schedule: they shouldn’t be able to.

It’s everyone’s responsibility to be able to provide clear reasoning how the urgency will affect the current production schedule.

The client should not, in any way be able to transfer their urgency onto us. Ever.

If we decide to accommodate them, a special rate is to be applied towards urgent work, and the employee is to be compensated accordingly should the work cause overtime commitments.

If your project runs into this kind of thing, always run it by Dragan as soon as possible.

Collaboration software.

We are rather simple when it comes to software we use.

Google Drive

All project files and their assets should reside in the company Google Drive. Please never rely on your own hardware to store work and assets that belong to the company. Always back up to Google Drive!

Harvest

This is our time tracking service and its usage is described thoroughly in the timesheets section of this document.

Trello

At the moment this is our project management app, and the way we are using it is very simple. Each project gets a board, each board get the following columns:

  1. Inbox: this is where new things go, e.g. when you send them to the board through the Chrome extension, in SCRUM speak, it’s our backlog.
  2. To Do: these are outstanding tasks.
  3. Doing: once someone takes a card they should assign themselves to it, and move it into this column.
  4. Done: when you have completed a card, remove yourself from it, and move it into this column.
  5. Notes: put all important information related to the project into this column as unassigned cards. Things like server information, CMS logins, briefs, bookmarks, etc.

While we all have our special ways of organizing our day-to-day tasks (pen and paper, sticky notes, text files, etc.) please keep the big picture stuff in Trello so other people can get an overview of who’s working on what, and how much work there is at any given time.

Here’s an example:

In Trello, you would have a card “Home page design” assigned to you in the Doing column for a project, but you’ll have all notes from the client’s feedback and actionable items on a paper note on your desk.

This way we all know you are working on that home page card, but we don’t necessarily need to know the specifics of that entire process. This is super-useful for taking a glimpse at someone’s current workload, and estimating the availability when trying to book a new project.

On the other hand, some of us prefer to keep everything in Trello, and that’s cool to. Even better.

A while ago we stopped giving access to clients to our project management tools, because we work with a lot of people who all have their own ways of using these tools, and it just becomes chaotic in there to the point that you dread opening it in the morning. However if you are comfortable with it, go knock yourself out, but don’t say we didn’t warn you.

Sometimes clients will require us to use their tools, such as Basecamp and Pivotal Tracker. In these situations they are usually the ones responsible for data entry and general project management, and we just submit deliverables, and communicate in there. It would still be sweet if you would manually duplicate the high-level tasks over to our Trello.

Slack

This is our informal chat, with the addition of the notifications channel, which we connect to GitLab repositories, so we get notifications in Slack when someone pushes to the repos. It cuts down on the “how’s the project going” fluff.

Also, please see the internal communication part of this document, regarding our use of Slack.

GitHub and GitLab

We use these primarily as code repositories, but they have some nifty features for collaboration on code, things like pull requests, ability to comment code line by line, reviews, etc.

Project setup.

Usually our projects contain of both design assets, front-end code, and a staging environment where we are showcasing our work to the customers.

Design assets

In an ideal world we have a 📁 Project Name folder in the 📁 Work Files folder of our company Google Drive which hosts all current projects, and work directly from that folder.

In the real world where Google Drive OS X app mysteriously fails to sync from time to time, some of us are moving their design assets to the 📁 Work Files folder only when we don’t need to sync as often (e.g. on every save).

The folder structure within the project folder is something we all do differently. It would be awesome if we had this standardized, perhaps in the future…

It is however advised to have folders that contain exports of deliverables per iteration, so that a clear timeline of progress can be observed.

At the end of the project, we share this folder with the client, or zip it up and send it to them, at which point we are moving it into the 📁 Work Files Archives folder for safe-keeping. The main reason for this is so we don’t have to sync the archives folder which would take up a ridiculous amount on our hard drives. Selective sync is your friend!

Front-End code

Each project gets a Git repository on our GitLab account. Usually we use Gulp, or Grunt for local development with SASS or LESS. Milan and Danijel are pretty good at this stuff.

We use Bootstrap, as well as our own starter kit called Mustra.

We ❤ Pug.

WordPress

Marko has created his own WordPress starter kit Faktotum that he uses to kickstart his projects. Check it out.

Staging

All front-end and back-end code is staged on our DigitalOcean instance under the superaweso.me/project-name domain. This is where we showcase the work to our customers while we’re in development.

The whole domain is uncrawlable by spiders, and requires a HTTP login at the root level. You can obtain this from anyone in the company, and are free to share it with our clients.

The server access parameters you will need can be obtained by asking.

Submitting and presenting deliverables.

At Superawesome we prefer the designers to present the work to the clients, themselves. There is no one better to explain and back up your design decisions than yourself. We understand it may be stressful if you haven’t done it a lot, but it’s really nothing to worry about. You may even learn to like it!

There are many ways you can present your work to the client, depending on the type of work, and the situation, and here is some advice drawing from our past experience.

If you are working on a new design for a project that has just kicked off, we found it is better to develop and present the deliverables in smaller chunks and pieces, with a lot of variety. This is the time in the project where you want the client’s input the most, and don’t want to go all-in into a single direction only to find out after 20 hours of work that you’re not on the right track. This is a recipe for disaster.

Let the client be a part of this process, and explain your design thinking by leading them through your process, rather than dumping the mockups in their lap, and expecting them to be amazed. This way they will feel as contributors, rather than stakeholders who accept or decline designs based on their personal preferences.

These early sessions are best done in person, with video conferencing coming in second.

If a project is not high-stakes, putting together a nicely formatted email with the mockups and explanatory text is also a good way to get the clients to understand our work. This method is also very suitable for projects that have taken shape and there are not that many unknowns in the design process.

Quality assurance (QA).

This is a very often overlooked part of any project, and it’s important to set some time aside in order to ensure things are working properly before hand-off.

More often than not, we’re relying on our customers to be the ones doing this as most of our projects are handed over to internal teams for final implementation, but it is us who are responsible for the final representation of our work.

Besides the obvious “there should be no bugs in our code”, this means that we should ensure that:

  • our designs are usable on touch devices and there are proper mockups or written instructions for implementation,
  • our front-end deliverables work in all required browsers,
  • our designs have been implemented properly (check for visual consistency, animation smoothness, typographic precision, etc.),
  • there is a style guide associated with a design deliverable outlining the usage of certain design elements,
  • there is a readme associated with a front-end deliverable explaining how to set up local development,
  • all functionalities of a site we’re launching are working (i.e. contact forms), and all old content has been properly redirected if necessary,
  • all third party accounts have been transferred to the client,
  • the client has received instructions on how to manage the content on their CMS-powered site (in video, or writing),
  • the CMS is set up to be backed up (off-site) on a weekly basis,
  • etc.

ReadMes.

It’s really important to document your code, m’kay…

No, seriously, there will come a time when other people will have to work with your code, and there will be problems if they can’t get it to run, or it’s too confusing for them to find their way around it.

This is why it’s a good idea to have a “readme” document for every project that explains how to work with the code. It’s also smart to generously comment your code, so that whoever needs to work with it doesn’t have a hard time doing so.

Things to consider documenting, regarding front-end:

  • Ownership: who is the tech lead on the project, and how to reach them.
  • Code versioning: Git repo and associated process for committing and working with the code.
  • Preprocessing: task runner installation, and how to start it up.
  • Deployment: how are you deploying the code, and which servers are you using for staging and production, etc.
  • Frameworks: are you using Mustra, Bootstrap, or something else?
  • Coded style guide: please maintain your style guide!

As for design:

  • Icon sets: include a link to the icon set, and make a note if you are altering the set in any way.
  • Photography: include links to the lightboxes/collections, and individual photos you’ve purchased.
  • Fonts: include links to foundries’ store, and make a note which license has been purchased (web only, full license, etc).
  • Style guide: please maintain your style guide!

Please take care of the assets and their originals, and always include the original assets somewhere related to the project (the Git repo itself, the official Google Drive folder, etc).

Creative Commons License

The Superawesome Playbook by Sprawsm doo is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

You are free to use, distribute, and build upon this work as long as you share it under this same license.

Give respect and get it back.