Key elements of a Design Process

We designers were born with the urge of making method out of madness; it’s how and why we became designers in the first place. But till date, we struggle to methodise the madness that is our daily work.

In between scheduling endless follow-up meetings with clients, working on the nth feedback round of the same design, re-exporting assets because “you forgot to correct that one thing”, hunting for the latest design file amongst your team, and discussing a new client’s expectations with your teammates whilst trying to land on a reasonably short timeline for the project, your entire day goes by and you feel like you barely did anything properly at all.

And then someone finally says what everyone is thinking out loud;

“We need our projects to be more organised from now on.”

You’re not alone. We all are looking for a way to work more smoothly and efficiently. But there is no magic bullet to nailing a Design Process; everyone can only try and come up with ways of optimizing their workflow, and over time, hope to have enough things systemised to stop complaining about the lack of a process entirely.

If you’re looking to set a new design process within your company or agency, or just trying to improve your existing process, you should keep four key aspects of it in mind —

1. Team communication: set up structured ways and channels for your team to communicate, and split them by project, role, and stage;
2. Scoping: use the project’s Scope of Work to organise the deliverables, the timeline, the accountability, and the payments for each project;
3. Delivery: control & consolidate the various deliverables by defining various aspects such as file hierarchy, QA process, Presentation process, Feedback & Iteration Process, and Handoff process;
4. Documentation: create and enforce methods of documenting both the design aspects and the project aspects for all parties to refer to during and after the project timeline.

1. Team Communication

Your team is going to communicate, one way or another. But under pressure, communication is often the first thing to break down. Bad communication sets your team up for a series of cascading failures, starting from simple errors and going all the way up to a very destructive work culture.

Your design process should be a mechanism by which you prevent the issues of under-communication, and also over-communication. Every new project should always be set up with answers to the following;

• Who all are part of the project, and in what role & capacity;
• What are the agreed-upon channels for each kind of work; and
• When (and how often) does the team get together to discuss progress, hurdles, and feedback.

In addition, you should try and demarcate conversation avenues in a way that each team member can stay informed about whatever is relevant to their work and is able to safely ignore what is not. While larger boundaries are often clear (design teams should not be talking day-to-day on the same channel as development teams for example), smaller boundaries are also equally important.

For example, if on Slack, create a channel for each project, which you then only use to convey project-wide announcements and roadblocks (eg. the UI for x project is now on stage 4), and is used by both clients (to stay updated on their respective projects) and team leaders (to stay updated on all projects).

The day-to-day work of each project should instead be discussed on a separate channel, which could be anything from an Email thread to another Slack channel involving only say the UI design stakeholders, or a communication tool built-in with the UI tool being used (Sketch, Figma, InVision & Zeplin all offer commenting tools within their products now).

Another great method of communicating within the team, especially if your team comprises largely of freelancers or remote personnel, are tools like Twist, which encourage you to break conversations into specific threads as well as into specific channels, and also choose with each message whom to notify about the messages you send. This keeps everyone’s notifications to a minimum and messages become more detailed and specific.

Lastly; although very tempting, do not add your senior team leads onto every channel the team uses. The excessive number of unread messages does your leaders no justice, and even the most dedicated people will eventually lose track of (and subsequently, interest in) all communications altogether.

Remember that the senior stakeholders of any project almost always have other projects to keep track of; only give them an overview of the project and its progress, so that they have the bandwidth to drill deep into whichever project needs their attention the most.

2. Scope of Work

An ill-defined project scope derails projects before they even begin. Because a scope almost always comes with an expected timeline and delivery schedule, a bad scope can easily mean;

• Inappropriate time allocation (easy tasks might be given a lot of time to be worked on, and difficult ones may be given too little);
• Vague expectations (clients may argue that certain deliverables weren’t as expected, because neither party agreed beforehand as to what was expected in the first place);
• Resentment between both parties due to low quality or product or frequently missed deadlines, or
• An incomplete product being pushed to production due to time constraints, setting the stage for weeks (or even months) of design and development debt.

While it’s usually tempting for both parties to rush through scoping, it should be the most deliberate and detailed aspect of your design process. And though each scope is a unique challenge in itself, they all serve four primary functions, each of them critical to the ultimate success of your project;

1. To break down the entire project into defined chunks of work.

Clients usually know what they want; they just aren’t sure about how it looks or works. This is where you have a golden opportunity to help them flesh out their product behaviour, individual features, expected deliverables, and whatever else is applicable in their case, and use them to divide broad business goals into measurable chunks of progress and delivery.

When done well, this even gets them excited about the road ahead, and helps you get a clearer picture of their needs, expectations, and assumptions.

2. To estimate the amount of time each chunk of work would take to complete, and therefore provide a timeline on the entire project.

It’s very common for clients to approach you with a hard date first, and ask you to work backwards from that date. But this almost always guarantees a bad scope, because the date rarely provides you more time than you need; so a good practice is to counter with your own schedule based on how long it will actually take you to deliver all the work they’re asking for.

The difference between your schedule (which is based on the expected deliverables and quality) and their schedule (which is based on their hard date) automatically shows them the scale of compromise that may be involved.

This is actually more productive than you think, as it sometimes encourages the client to scale down some of their initial expectations, and roll out only what can actually be done in time. If you do this well, the same client will come to you after the hard date with a new project — to improve the product you just delivered earlier. In the long run, clients appreciate work done right rather than work done fast, even if they come to you initially saying the opposite.

3. To tie each chunk of work to payments.

This is the hard part — and usually something designers never do. More often than not, it’s because the final price was agreed to prior to design scoping; but the pitfalls of not asking for payments in increments are well-known to the entire design community and needn’t be mentioned here.

Essentially, the total price should be open to negotiation post-scoping, in case the scoping process reveals more tasks than originally anticipated, or fleshes out some tasks to become much more intensive than normal. Your sales and/or financial team should come back post-scoping and set a schedule for payments based on your project delivery schedule, effectively tying your deliverables to payments (as should be the case).

3. Delivery

Deliverables are the simplest in theory, but actually the trickiest during execution. The major portion of your design process should document ways to control how deliverables are created, stored, presented, delivered, and archived — and access control over each aspect of this process. At minimum, a good design process sorts out the following;

File Structure & Hygiene

If you’re using a cloud storage service like Google Drive or Dropbox (which you should be using), segregate access to the same; allow only a few key individuals access to the entire drive. For everyone else, create a system where each individual has access only to relevant folders — designers should have access to any design folders for projects they’re working on, sales team should have access to all sales documents, finance team should have access to all financial documents, and so on.

Your folder hierarchy should also include folders that are meant only for clients to use, and a folder for each project’s reference documents, and folders meant for all discarded design files of a project. The rest of the folders and their hierarchy depend on your team’s unique working style.

Design QA

A critical component of any design process you setup is the mechanisms to ensure the quality of design. The best way to ensure QA is to assign any one person as the QA Engineer for the entire project, and ensure this person stays in close contact with client needs and expectations throughout the project timeline.

A single source of QA makes it much easier to ensure consistent delivery of quality to the client, irrespective of the actual set of designers working on any particular deliverable. You can also set up dedicated communication channels for QA, where all designs are sent internally for review before being approved and sent to the client.

Client Presentations

Your design process can also set up consistent methods of presentation to the client if necessary; for example, you may choose to always present the UI via an InVision link, and the UX via an Overflow link, and so on. Consistent presentation methods also help in setting a consistent quality expectation, and makes it easier for both sides to track the status of all deliverables.

Your presentation links and methods should ideally be detached from your actual designs; i.e. you don’t want to send clients the source files directly during presentations. The client should also not be able to manipulate any aspect of your design through the presentation tool you provide. If necessary, you can separate your working files from the production files to achieve the same objective, and design only on the working files.

Feedback & Iterations

There is no avoiding persistent feedback and iterations from the client; but you can at least systemise their influx, and document all requested changes in a consistent manner. Your design process should

• Control the amount and timing of client feedback; ideally you should take all requested changes on deliverables in one go rather than one-by-one, and encourage your client to do the same as well;
• Vet all feedback, and counter if necessary; clients don’t always know what’s best for them. If you feel certain client changes are getting out of hand, are unethical, or may adversely affect the quality of work you’re delivering, do not hesitate to argue or even deny those changes.
• Condense all feedback to simple actionable tasks, and deliver them to the appropriate team members; not everyone needs to know the reasoning behind everything in the project. If an illustration needs to be reworked, convey why the client didn’t like the illustration only to the illustrator involved. It saves everyone’s time, and keeps grumpiness at bay.
• Put a cap at the number of iterations, and bill clients if they get out of hand. In my personal experience, a client who knows that excessive iterations on a deliverable will incur additional costs is always more deliberate and precise with their feedback. No mess, no fuss.

Handoff

Ideally, final handoff should occur at the very end of the project; but in some cases, clients are looking to commence product development as soon as possible. Tools like Zeplin and InVision have made design handoff particularly easy and organised, but as a general rule, you do not want to deliver source files and assets to your clients before you’re paid for the same. So always aim to be paid before handing off a deliverable.

Your design process should also include a separate checklist for handoff; a series of organisational and design checks to ensure that the final deliverable has everything that the client may need to develop the product. This checklist can be anything, but may include items like asset rasterisation, artboard naming, file naming, copy editing, and intellectual property checks.

4. Documentation

Easily the most overlooked, documentation is probably the most important aspect of your design process. Good documentation anchors your team’s priorities, tasks, conversations, feedbacks, and design decisions in one place, which otherwise are scattered all over your email threads, design files, whiteboard photographs, and resource folders.

Documentation for a design process can be split into two parts; design documentation, which documents all the discussed, designed, and delivered product behaviour; and project documentation, which documents the entire timeline of the project including key conversations, decisions, dates, feedbacks, tasks, deliverables, and files.

Design documentation

There will be several aspects of the product that will be “understood” by both the client and the designer, but not really written down anywhere; these “understood”s are usually key aspects of product behaviour that aren’t sufficiently explained through any of the designs you deliver.

Although it’s not necessarily your job to write down the entire product’s documentation, it is still good practice to provide detailed explanations of key design decisions, behaviour, and expected outcomes to the client (and by extension, the development team), so that the trail of decision-making is followed through to the very end and available to anyone downstream to pore through. Design documentation, to save unnecessary effort, is best written after all major aspects of the product’s design are finalised.

Rudimentary interactive prototypes, such as those that can now be made in Sketch, Zeplin, Figma, InVision etc. can be paired with comments within the prototypes to deliver an extra layer of behavioural understanding; but few things rival the clarity of flow diagrams paired with actual screens, such as those that can be created using Overflow. Powerpoint slides can also do the trick, even though they’re old-school and mundane.

Project documentation

If you use a project management tool like Jira or Trello, and/or have a dedicated Project Manager on board, you most likely already have some form of project documentation in hand. Project Management tools serve as good substitutes for task documentation — if the project tasks were created well, and everyone in the team vigilantly kept their task lists updated, you have a good record of who did what and when within a project.

But proper project documentation takes things up a notch, by noting the following things;

• Key personnel involved in the project, and what were their roles, responsibilities, and final contributions;
• Key decisions that were taken during meetings, and how they served as anchors for the designs that came after them;
• Key feedbacks offered by clients during & after design presentations, and how they were worked into subsequent iterations;
• Key timelines of the project, and how the actual pace of the project deviated from them (and why);
• Links to all major files, resources, scope docs, task lists, and links relevant to the project.

My personal favourite for project documentation is Dropbox Paper, but feel free to experiment with any combination of tools to achieve the aforementioned. Well-organised deliverables, coupled with concise documentation, helps both designers and clients stay on the same page months after the project is concluded, track project progress with minimal effort, and stave off any ongoing or future confusions that may arise.