The first difference you encounter is when onboarding your agency into an enterprise client's procurement system. There are many more hoops to jump through and terms to agree on than with an early stage startup. Higher indemnity insurance, criminal record background checks, non-disclosure and IP agreements to name a few. Completing the procurement journey can also take months which can negatively impact a small agency's cash flow, especially if you're unable to get your invoices processed until listed on the approved suppliers list.
It takes time to enact change in any organisation, working quickly is easier said than done meaning your first enterprise project is unlikely to be as smooth as the second. With any new client it takes time to get used to their preferred method of working, communication and internal practices but this takes the longest with bigger companies. Often creative agencies are brought in during a time of transition and aren't just replacing an existing incumbent. This creates an opportunity to help companies craft their process and introduce best practice at an early stage. As with any client relationship it is best to start as you mean to go on, so for example: if you want to introduce user testing into the process, bang the usability drum from the very start.
Usability testing with enterprise clients deserves its own paragraph. Often there is much resistance to this practise as it's a relatively new phenomenon in the corporate world. Frequently, this is due to security concerns about the product's IP being leaked, client data being revealed or competitors gauging what's being built. It can take years for teams to come around to the idea that user testing prototypes at the key stages of the design process can streamline the design and build phase, saving them money in the long run whilst producing a better product. It is our job as designers to champion usability testing! If frequently suggested with a clear testing hypothesis in mind, eventually it will become an accepted part of a larger organisation's process.
Security is often the trump card within large organisations when it comes to decision making. If the internal IT team decide a feature carries a level of risk, the idea is removed even at the expense of the customer experience. This is understandable due to the scale of many products. When you're working on a Startup's MVP you'll be lucky to get hundreds of users on the platform but a large company's V1.0 product could immediately be rolled out to 100,000+ users as soon as it's launched. At this scale, over time with enough users, eventually any security vulnerability will surface. This also means it's unlikely they'll allow you to include the project in your portfolio or even feature their logo on your website to prevent your organisation from being a back door to their own data or systems.
The scale of the products launched also influences the process. A reluctance to test products with external users and the need for security to be water-tight a waterfall approach to product development is still prevalent. Generally, this means you'll have longer design phases and what you produce must be more rigorously checked, tested and more frequently signed off. Although you may not be able to test with external customers, you can perform usability tests with members of both the client's and your own team, testing that people can navigate through the product in order to fulfil their goals.
Communication methods are notably different when working with larger clients. Although the technology may be the same (lot's of emails, Teams calls and Slack messages) getting feedback and questions answered can take much longer. Due to the larger team sizes you're working with many different people who need to review your work before you receive an answer. You may not even be in direct contact with a project's senior stakeholder in which case feedback is slow, can be misinterpreted and isn't directly challengeable.
This leads nicely onto the inter-departmental setup of large organisations. It's likely you'll be working for one part of the business that is in turn providing services for another, entirely separate team. Again, this leads to longer feedback loops and no direct line of communication with the senior stakeholders but also exposes you to internal politics. You may never know the reasons why certain decisions are made, it could be that the product's direction pivots at a moment's notice or the project is cancelled altogether. All you can do in these circumstances is act professionally, doing the best you can with the information and resources available to you - don't take it personally, it's highly unlikely to be a result of your work.
Guidelines, guidelines, guidelines. It can take a while to get up to speed with all the requirements for both design work specifically and the more general protocols you must adhere to. The latter includes; confidentiality clauses, secure ways of transferring data, understanding the company hierarchy and even how best to communicate with people. Brand guidelines are of particular importance because if you establish a good working relationship with key members of the brand team, going through the review and signoff flow can be a much smoother journey. Understanding at the start of a project what the accessibility requirements are prevents nasty surprises later on as often there are the usual WCAG AA guides to follow in addition to brand specific requirements, (based on previous lessons learnt when applying their visual identity)
From the very beginning, Inktrap has always strived to achieve the best possible outcome we can with the resources we have, never looking to trick people into paying as much as possible whilst delivering as little as possible. This is because you will always get found out. This not only risks the client moving on but also tarnishes your reputation, the people you've interacted with at that organisation will remember you for many years to come. If you produce good work there's every chance they could seek you out once they're either higher up in the organisation or moved companies, gaining you a new client repeating the process all over again.
Often product updates are released to thousands of users. This means rigorous UAT (User Acceptance Testing) processes need to be followed at different steps throughout the process due to the higher risk involved compared to launching an early stage product to a smaller user base. There's also more unexpected processes to follow that are industry specific. Many larger financial services companies require their contractors to have completed a criminal background check, as they may have access to sensitive financial data during the project.
The common theme reflected in all these points is; larger companies want to reduce risk, startups want to take risks. There's far more to lose if a larger company get something wrong especially when the culture doesn't fully embrace a lean approach to product development. You'll need to modify your mindset accordingly taking more time over your work to mitigate risk.
These are just some of what we've learned over the years. What have you learnt when working with bigger clients? Please share, we'd love to know!