The Superawesome playbook

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. Although they sometimes use us as a simple service provider without a deeper relationship, we much prefer to be in a position where we are able to introduce change.

In a world where things are measured to death, we believe there is value in the immeasurable.

Even though we are designers, we are not selling design. 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. Only when they succeed, we succeed.

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 & hierarchy

At the moment Superawesome only employs full time staff. 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. That said, in 2017 we've hired Marija Stevanovic to help us with client management and pre-sales.

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 giving people a sense of ownership and responsibility over their work and activities is a much better motivator, than having someone telling them what to do, how, and when to do it.

Setting things up 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 majority of the projects will be lead by a lead designer, along with Marija who is acting as the primary point of contact. She is the person we all go to when we have questions, and this the lead designer 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, however Marija is still the primary contact for the client.

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. Marija makes sure this rhythm is set up and maintained.

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 & 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 that someone is waiting for a response from you.


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.

It would be awesome if you booked all your meetings in the common calendar called Superawesome. This way we all know who's talking to who, and whether the conference room is occupied.

If you send your clients this Google Form to fill out, the meeting slot they request will be automatically created in the calendar and they will be added as an attendee.

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 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 & 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.

Since we don't require disclosure about why you are taking time off, it doesn't matter if it's for personal or medical reasons.

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 Marija 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. Marija 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.


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

Hours, worktime & 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.



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.

Partner dividends

Superawesome partners are foregoing any monthly compensation in favor of end-of-year profit split.


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.


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.

Performance bonuses

All employees and contractors are eligible for a performance bonus which are handed out on a case-by-case basis.

Client onboarding

Here's a checklist outlining the process we go through in order to kick a project off.

  1. Pre-Commitment.

    1. Initial contact.
    2. Informative meeting/email discussion.
    3. Receive and process a formal project brief.
    4. Determine project setup (creative or executive, ongoing or short-term).
    5. Check schedule and propose rough timeframe.
    6. Prepare and send an estimate/quote.
  2. Administration.

    1. Collect company information.
    2. Determine billing preferences.
    3. Prepare and sign contract.
    4. Issue invoice and receive advance payment.
    5. Confirm kick-off date, or reschedule.
  3. Briefing.

    If the client is not able to supply us a complete enough brief or specification, we conduct a pre-project discovery session in order to produce one.

    1. Create a work document (an official brief to work off of).
    2. Conduct team meeting.
    3. Set up project phases and extract initial work orderd.
    4. Make introductions between client and team and mark the official kick-off.
  4. Production.

    This is a cycling phase (similar to a sprint in agile-talk), and can be repeated as many times as necessary.

    1. Define and schedule a work block.
    2. Schedule a review session.
  5. Handoff/Deployment.

    1. Quality assurance and testing.
    2. Settle outstanding invoices.
    3. Prepare all graphic assets in appropriate formats, and deliver.
    4. Grant access to code repository or send .zip archive.
    5. 🎉 🍾 🍻

Organizing projects & 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.

Creative setup

These are projects that are more akin to what one would call R&D (research and development), than an agency engagement. We do a lot of speculative work and experimentation.

While we generally don't commit to deadlines on this project setup, all projects have and must meet some kind of time-based expectation a client might have, but we generally prioritize getting deeper into the matter, than meeting a deadline.


It takes experience and patience to be able to work on something long-term and with commitment. There are always a lot more questions than answers. A lot of responsibility.


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.

Executive setup

Essentially, we set up a project this way if the deliverables are straight-forward and there's a deadline to meet.

Over time we've developed very rigid processes for certain deliverables which people are advised to follow whenever possible in order to achieve maximum efficiency and control over the outcome.


Relying on the client to make certain decisions which influence the quality of the deliverables. Packed schedule, no wiggle room. Deadlines.


They blaze by fast and provide a sense of accomplishment. Practice to perform under pressure.


We're currently in the phase where we're doing our best to enforce a weekly schedule routine, and use it to pace ourselves as well as our clients' requests.

This means projects are assigned weekdays for each person on the team, during which each of us are working on a particular project.

This is how our projects are billed as well as how they are estimated in terms of time available and required to execute them.

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 and/or Marija.

Managing projects at Superawesome

Not having a clearly defined design process, its stages or priorities can be a very serious problem as it can hurt the workflow of everyone, and we are not talking about the designers only. Skipping or mixing the stages of the process will almost certainly result in chaos. This is the reason behind the idea of creating a documented design process.

Phase 1: Defining the goals

This is the initial phase in any design project process when we get ourselves familiar with what workload we can expect and plan our schedule accordingly.

This is also the time when we set up overall structure, decide on the scope, talk over the budget, timelines, milestones (if any) and try to get familiar with the client’s needs and wishes.

Phase 2: Backlog and backlog grooming

The clients are asked to formulate the tasks (we refer to them as “work orders”) and send them to us. We go through them daily and make sure that those requests are realistic in terms of time and budget and if they contain all of the necessary information the team needs in order for it to go into production.

Phase 3: Assigning the work orders

Once the work orders are in our backlog, we need to go over them and figure out their priority, and then decide who in our team will be in charge of them.

This is a daily occurrence, and is the responsibility mainly of the account manager, although some discussion with the team is almost certainly required.

Phase 4: Production

This is where we get to work! With all the input from the client and the information collected we are ready to move things into production and do actual work.

Phase 5: Collecting feedback

Once done with the work we send it to our clients for their feedback. In case the client has some changes to make, they provide us with a set of new instructions and we go back to phase 4. Or if the client approves of our design, the work is considered singed off on.

Phase 6: Over and out

People who use the product should be the ones who will provide the feedback and it is crucial to get it asap so that we can get official sign off from the client and optionally hand our work over to another party and move things to the next phase (e.g. back-end development).

Briefs — AKA “statement of work”

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.

Once you do, you will have what we call a “statement of work” and it represents the official brief you are going to work off of. Make sure the client reads, understands, and agrees with this brief. It's something to fall back on if things get out of hand.

A statement of work document 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.

Duties of the account manager

The account manager — in our case it's Marija Stevanovic — is responsible for doing certain tasks in order to ensure the project keeps on flowing nicely.

In particular, they are responsible for:

  • the final version the project document/brief,
  • planning and project schedule,
  • preparing work orders and making sure they are ready to be put into production,
  • direct communication with the client not concerning deliverables and making sure the client never needs to ask you for project updates,
  • being the go-to person for first-hand information for the client,
  • sitting in on meetings,
  • communicating exchanges between the team and the client,
  • incident handling, aka firefighting,
  • updating Dragan weekly on the progress and communicating any client requests for him to handle.


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.

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.


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.


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).


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.


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 & 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 Marija 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!


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


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 (psst: ask Dragan to set you up with a zap so this happens automatically).


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

UX vs. UI

Lately we are doing our best to enforce a separation between UX and UI work. Before we handled both things in a single pass which resulted in a lot of strong reactions and simply a lot to take in and process at once — for us and the clients both.

Nowadays we insist we take care of user experience design first, and that the clients sign off on it.

By user experience work we mean:

  • understanding the fundamentals of the project,
  • defining user flows and developing features,
  • lo-fi design work in terms of wireframes,
  • prototyping.

Once the UX work is done, the project can move into the UI design phase with all of the UX decisions in place. This way the UI designer can always rely on the decisions made in the UX phase and know that the client is on board with that way of going about a thing.

Only after this is it possible to move the project forward to front-end coding.

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.


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


All front-end and back-end code is staged on our DigitalOcean instance under the 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.

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!

Submitting & 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.


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.