The Superawesome playbook

What kind of a company is Superawesome

At the moment Superawesome employs full time staff, as well as contractors. 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 hired Marija Stevanovic to help us with client management and administrative work.

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

Besides projects, other matters such as the operations, HR, sales, billing, expensing, etc. are handled by Marija as well.

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 a while, 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 decide 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 purposes (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 anything else, 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 girl or guy that will step 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 anyone from management because they'd like to know as early as possible.

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.

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 help you.

Keep all your meetings in your GSuite calendar, this way we all know who's available when.

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:

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

Each project usually gets its own channel where these projects are discussed, as for other channels this is how our Discord text channels are structured at the moment:

• announcements is a one-directional channel for all formal correspondence from the company,
• general is used for whatever,
• i-need-help is used when you need assistance,
• design-porn is used to share design pieces we like,
• ekstra-mema is for memes and gifs,
• show-off is for sharing your own work and work in progress,
• sweet-finds is for sharing links,
• good-reads is for sharing interesting articles and prose,
• office-hours is used for discussions regarding Wednesday office hours.

We also have several voice channels:

• Conference 1 general conference room 1,
• Conference 2 general conference room 2,
• Design collab is an open room meant for designers to jump in to at any time to collaborate,
• Kafana is an open room to chill.

Apart from these public channels we all chat in between ourselves privately. It is always smart to ping someone through Discord 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.

All Superawesome employees are officially given 25 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.

All time off taken by contractors is treated as unpaid, and contractors are free to take as much time off as they want within the scope of their collaboration agreement.

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.

When you want or need time off, let Marija know so she 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 make up for it.

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

Holidays

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

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, or behind 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 “production time”.

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.

Time in the context of estimates

When giving out estimates we encourage everyone to use man-days or man-hours, as well as calendar days. This gives the stakeholders better clarity, and sets up expectations more clearly.

Notice how from the first estimate one is not able to deduct how long will the actual work take, and whether it's a full week of billable work, while the second estimate clearly states the billable/productive portion, as well as the overall duration of the work.

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.

Fees

Contractors fees are arranged up front based on the collaboration agreement. All fees are paid either on the first of the month, or on project completion.

Partner dividends

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

Raises

Any employee is able to negotiate a raise at any time after first 12 months of employment. A raise can not exceed 10% of current compensation per year.

Contractors can negotiate their rates at any time.

Bonuses

Performance bonuses

All employees and contractors are eligible for a performance bonus given upon their 12 month evaluation. Things which are evaluated are the quality of work output, workload and its management, client relations, and colleague relations.

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 the schedule and propose a rough timeframe.
   6. Provide a rough ballpark estimate if possible.

2. Briefing.

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

   1. Create a work document (an official brief to work off of).
   2. Conduct a discovery workshop with the stakeholders.
   3. Finalize the workshop by completing the official brief including our estimate or fixed price quote for the job.

3. Administration.

   1. Collect company information.
   2. Determine billing preferences.
   3. Set up project phases and define initial work orders.
   4. Issue a finalized Statement of Work for the project at hand.
   5. Inform them of the official way to request work under that SoW.
   6. Inform them how the project tracker works.
   7. Prepare and sign a Master Service Agreement.
   8. Issue invoice and receive advance payment.
   9. Confirm kick-off date, or reschedule.
   10. 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. 🎉 🍾 🍻

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 were the only ones we were doing work for, and that we could 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 call,
• client sends long-winded emails with no actionable points or clearly defined next steps,
• radio silence until the project becomes mission-critical, then 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, over meeting a deadline.

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.

Scheduling

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, an 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 often 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 signed 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).

Statements of work

You should never start working on a project or a task unless you have a written brief in the form of an SoW. 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. Better yet, use our discovery workshop.

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.

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 of 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 and contractors are required to maintain a time sheet for every project they are working on. It’s usually 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 Clockify, and you should have access to all the projects you are currently working on. If you don't, just ping Marija.

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.

Clockify tasks

All projects should 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.

Sometimes we employ temporary 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 with 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 containing a non-disclosure clause.
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 cannot 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 generally don't practice marking up outside contractors' services, and 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 an outside 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.

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 the 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 did implement a backup system, 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.

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.

Here are some examples of client-speak you should learn to recognize.

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.

Here are some examples of counter-questions you may choose to use.

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.

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

Notion

This is our knowledge hub, and the place we try to keep all of the information we use on a daily basis. Our internal wiki is there, it's where we keep track of things we need to do around the office, etc. If it's not in Notion and you are looking for it, than it should be.

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!

Clockify

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

Discord

This is our informal chat, with the addition of voice channels where we can talk in closed or open spaces.

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

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.

Product & UX vs. UI

Lately we are doing our best to enforce a separation between product and UX, and UI work. Before we handled everything 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 product design and user experience design first, and that the clients sign off on it.

By product design and user experience, we mean:

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

Once the product and 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 implementation and onwards.

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 various static front-end frameworks, 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.

Design assets

In an ideal world we have a 📁 Project Name folder under the current year 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 each year we do a full sweep of Google Drive's 📁 Work Files folder and move the finished projects' assets over to an off-site archive.

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 the jury expected to accept or decline designs based on their personal preference.

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 presentation — or even an email at times — 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.

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.

We should not be relying on our customers to find and track bugs, 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 work, m’kay…

No, seriously, there will come a time when other people will have to continue where you left off, and there will be problems if they can’t get the code to run, or it’s just 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!

If it's the design work we're talking about, make sure you are maintaining a style guide, and that the components are clearly labeled and accompanied with example usage and descriptions. Design systems are useless if other people aren't able to adopt them because they can't figure them out, so put some time into documenting your design work!

Additionally:

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