In the world of client services, no matter how skilled you are at the actual output of design and development, the true barometer on the success of a project is the satisfaction of the client. Client satisfaction is something that can be very hard to manage, especially with technical dev-oriented builds, but is absolutely paramount to ensure success for both the product at hand and the relationship between agency and client. Client satisfaction starts early and needs to be accounted for often, always keeping expectations in check, and communication lines open.
At Authentic Form & Function, we thrive on projects that not only have a design component, but ones that include large technical builds, often times crafting custom content management systems or from-scratch web applications. These large projects require complete and thorough scope outlines, accurate and itemized estimates, and the mutual understanding between client and agency, that while we can absolutely estimate where a project stands now, it’s inevitable that things will change, bringing timelines and budgets into question.
This notion of ever-changing requirements, budgets, and timelines is scary; scary for both client and agency. No one likes to hear that the cost of their investment might increase during the build process. No agency likes to hear that the functionality originally presented has become more complex and they need to build it using original cost.
What’s the solution to this quandary? The short answer is trust. What’s the best way to earn trust? By managing expectations, and communicating early and often about project status and scope.
In theory this all sounds great: Trust, Managing Expectations, Communication; all a bunch of fluffy words that are hard to actually execute. The truth of the matter is there is no sure-fire way to manage all of these things; however I’ve created a list of approaches we take at Authentic F&F, to help ensure many of these items are accounted for.
First, we immediately start helping the client better determine the scope of their project.
Usually this means putting in a handful of hours to better outline functionality, discuss typical (as well as fringe) user stories, and providing our guidance and consulting to help frame the goals of the product being built. We want to fully understand and help guide the project from it’s conception, providing our expertise early to encourage success. On some projects we put in many hours pro-bono before we start charging, but this extension on our part helps create the trust necessary further down the road during the project build.
Many times clients come to us with rough ideas of what they want, and we help them better define what exactly they are looking for, providing insight into how we can best execute their vision while keeping budgets and timelines in mind.
This process is absolutely a back and forth. Clients will at times give us a laundry list of features with a very limited budget, and in that case it’s our responsibility to tell them why that specific feature set and budget isn’t feasible, and furthermore, recommend a comparable solution that does fit within the budget. This piece is crucial on large technical builds. Being a “yes-man” to functionality at this point in the process will only lead to disappointment later in the project.
During the project build we stay vigilant, open, and honest about additional scope items as they arise.
Even with all the help scoping and planning done before the build starts, you need to assume things will change. Being vigilant means making sure to meticulously inform the client when something does fall out of scope.
Open means being open to their concerns and doing your best to resolve the concern. Sometimes this means implementing the feature without receiving additional budget, and other times it means "iceboxing" it for later, informing the client their request is on your radar and you will do your best to circle back after in-scope items have been completed. If you have done your due diligence on project scope, you should be able to navigate through these issues, keeping the overall success of the project in mind.
Being honest means being realistic with the client (and yourself) about each request. Again, being a “yes-man” does no one any favors. Being able to say “No” to the client and having them understand your position is something essential to managing their expectations and the project as a whole.
When we’re expecting potential hiccups in the build process, we inform the client and prepare them for what to expect.
A perfect example of this is after handing off a completed CMS integration to the client to enter final content. The issue is, no matter how hard you try to test the CMS with pseudo-final content, the final content a client enters is always slightly different than what you are expecting. This can often times cause issues with layout and even introduce new bugs that didn’t surface before the real content was in place.
During this process, even before the client starts entering the content, we inform them to expect bugs to surface while they are entering content. When bugs inevitably do surface, we record, track, and communicate the issues back to our team and respond quickly fixing anything that does come up. When addressed before the bugs arise, the client is better able to manage and handle these small issues which are nearly impossible to completely avoid. Taking the time to understand and empathize with the client during this process helps to build trust and strengthen the relationship.
Lastly, we communicate with the client regularly, never leaving them wondering what we're working on.
During the course of any project, there are lengthly lags when we are in the middle of a design or development phase; periods when we might not need any information from a client. During these phases a client can get uneasy, as they haven’t heard anything from the team, and this uneasiness can absolutely hurt trust in the relationship.
To avoid this, we send out Weekly Status Updates, each Monday morning, where we address what we worked on last week, what we are working on this week, and any major items that warrant discussion. Many times we are restating information the client already knows, but this simple 5 minute task reassures them they are on the top of our priority list, and we are actively engaged in the working on their project.
While some of these things may seem obvious, we find they are all necessary to ensure the successful running of a project, and to have a happy client after our work has launched. The biggest challenge is creating a manageable client communication system and a work culture that puts pride in their communication. When schedules become tight and workloads increase, communication sometimes becomes the lesser priority, when in actuality it should become the top priority.
Earlier in 2015, at their annual React.js conference, Facebook made an exciting announcement with the release of React Native: a platform bringing the brilliance of React JS to the process of developing native apps. For years web developers and designers have looked for a platform allowing them to use their web-based skills to create mobile apps, the question remains, is React Native the platform to bridge this gap? Furthermore, is it a game-changer in the landscape of platform architecture and development?
In this article I want to provide an introduction to React JS, for those of you interested in the latest and greatest, but potentially a little hesitant to jump into something so new and different.