First, let’s start with what “decision making” is, and more importantly – good decision making.
When trying to make a good decision, a person must weight the positives and negatives of each option, and consider all the alternatives.
Clients come with problems. And they want them solved. Most of the time that’s a business problem, not technical. They want growth, they want improvement, they want income. Designing and developing must come with this core idea in mind. You want to provide a product that will improve your client’s business.
But to do so as an agency, you have to understand the business of your client. Why a certain design decision is better than another. What is the user base? How will this design decision affect the technical implementation of it and therefore the budget of your client? Long term commitment is crucial for understanding this.
What are the problems?
I work in a WordPress development agency. My job apart from simply working on tasks is to make decisions. And the same goes for any other developer.
“What are these decisions?” you might ask.
They are about what is the easiest, most cost-effective and robust way of dealing with an issue. Articles like “Javascript Fatigue” explain the whole process of making choices very clearly (and funny.)
There are just so many libraries, tools and techniques out there that you can easily lose yourself.
Then you have to decide what is the best front-end framework that will help you out. Is it Boostrap? Is it Foundation? Problems like naming conventions used by them, technology (like flexbox) or preprocessor can weight on your decision.
And let’s not get started with browser support, even thought our beloved IE10 and blow has less than 0.1% usage.
1) UX problems
All of this is important for one very simple reason. Clients often come with a particular set of requirements. They might serve content to banks, to hospital personnel or people using their work laptops with old software.
You have to take all of this into consideration when building the website. How will these people use it, where do they expect to find the navigation, the headlines, the search bar?
A very simple example: layout with a vertical menu on the left formed just by images and conventional layout with header and horizontal menu on the top.
You should design with the client’s users in mind. Don’t go crazy unless they specifically want it. And to say “but they liked it anyway” doesn’t prove anything.
The clients come to you because you have all the experience and knowledge in building websites for large companies. It’s important that you as a designer/developer have to make decisions for your clients.
You can create a breathtaking design with the mentioned layout above – menu with icons on left, large pretty photo on the right, but will current userbase find it’s way around it? Are they going to freak out and leave – destroying your client’s business? Could happen.
Navigation must be straightforward, you shouldn’t create anything too artsy for serious corporations, and nothing too boring for fresh and artistic startups.
All of this is valid for any other aspect of the site’s usability. You can go crazy with your designs naturally. Most likely your client will like them, but you have to think for the users more. It’s your responsibility.
2) Redesigning nightmares
A wipe of everything is welcomed thing sometimes. When the code gets too bloated or when the design is so 2000s-ish, you want to start clean.
But what are your expectations for this redesigning phase? How will it go? Will you have enough time? Is the project just too big? Did you send your redesign idea to the client a little too early before talking it through with your marketing team?
Don’t get me wrong, there are some excellent reasons to consider redesigning, but there is a lot to think about when you’re proposing it. Adding neat design elements just because won’t cut it. You will have to think how will they affect performance as well.
Adding some slider can mean that 5000 lines of JS and 3000 lines of CSS will have to be added to the whole project with more complex backend connections to make everything work.
Or that simple, cute widget with five random news shown on every page load.
You might say “What is wrong with just five random posts shown every time, we list like 40 on our homepage”. Well, caching. These 40 posts are the same for at least 10-15 minutes, but these random ones?
They aren’t. And then you will have to explain to your client that your cool idea won’t work because you didn’t communicate this with your development team.
3) Teamwork
Good team communication is important. You’re in a development agency, doing freelance work on your own. You must take these decisions with the rest of the team.
As a front-end developer, you will need to communicate with the designers about individual elements. A problem very often becomes the content.
The designer usually shows the best case. Example: beautiful image, two lined headlines with three lines of the excerpt. In real life – ugly low quality 4:1 aspect ratio image uploaded by the content writers, 22 words title with one line excerpt. What do you do then? Do you cut the title? Do you change the font-size, do you remove the image or show default one? What?
Some solutions can be:
- Write a guideline for the content writers to follow.
- Create secondary view with/without featured image (will make the design more lively if done correctly)
- Remove the excerpt completely if it’s too short
- Use default featured image if the provided is too small
Of course, all of this depends very much on the project. It’s possible that every solution will fit or none will. You have to make these decisions on the fly based on your experience.
This is why a client is paying extra for your services as an agency. The professional experience and knowledge of marketing specialists, designers, developers and content writers. This is not a one-man show.
How to find the proper solutions
Your number one goal must be satisfying your client’s business needs. This goes before any feature, before any design proposal and before any article written. They must be molded around your client’s business. Therefore, you need to study and understand it well.
1) Make it fit the budget
Since all your decisions must be complying with your client’s business, they will also have to fit in the budget. Your job is to plan that well. You can eighter go for one payment/development or a retainer plan. These two paths will make a big difference in your decisions.
A one-time thing means that you have a strict limit and you must fit in it. Your focus should be on improving what’s currently there. Building from the ground up is expensive and it takes time.
It’s best to identify all problems the current implementation has and fix them. Some of them might be:
- Slow load times – focus on improving loading times. In one of the projects at DevriX, we’ve got from 25s to 4-5s load time just by improving script loading, plugin management, image and server optimizations.
- Bad mobile view – mobile users are nearing 70%. Improvements in this area can increase conversions.
- Bad visuals – A complete redesign is a very good solution if the budget is there, but if the schedule is tight and the client is on the low end of your services, just visual updates across the site can solve part of the problems. Better fonts, better colors, more contrast, nicer paddings will make the whole site look refreshed and easier to use. It’s possible that the site will keep many of its minutes, you will deliver in the deadline.
And this is the benefit of the long-term development plan. You can deliver on sprints instead of everything at once. That will give the time to clean up any previous work, will allow you more time to test and understand the business and make the proper decisions.
Keep in mind all limitations you have when you create your plan. A good thing to do is write down weekly sprints. Then you can delegate the tasks from this sprint to each team member. Make sure you will fit in the deadline and the budget.
2) Two approaches based on your deadline
What are the most common issues I encounter when developing a new theme?
How much time to spend on planning. Building a brand new site from the ground up is exhausting because you constantly have to decide what approach to take. What will you need in the future? How will things change? There are many questions like these.
The answers are again, tightly related to the deadline and budget. If you have to be ready in one day, you won’t spend hours on planning the complete structure of everything. There is no need to think too much about modifiers, utilities or separation of components.
Years of experience come in help in these cases because you can come up with relatively good solutions for the time being. Using good patterns of development will deal with a large portion of potential problems. That way you will simply code right now, get everything done quickly and deliver on time. Only after that, you can start refactoring.
This is the important separation. If you don’t have time, make sure you deliver, no matter of the hacks/copy-pasting. Just make it work, your priority is to get it done on time. You will have as much as you want time afterward to refactor and improve.
Make it easy to maintain and extend
If the budget and deadline allow it (like weeks/months of time), then laying down a solid foundation is paramount. Thanks to it, you will be able to grow the application/website without the need of rewriting older bits of code or hacking left and right.
If you have enough time, make sure to spend a good portion of it in planning everything. How will components interact? How many variations of the same component exist? What is your naming convention, is it easy to understand the function just by the selector?
Days can pass with almost no visual progress, but once you lay down all of this, any future changes will be much easier. The component-based structure will limit the possibilities of regression.
So make sure you have your priorities right – build quickly, use hacks and deliver very quickly (and maybe with a messy code) and refactor afterward or spend days in good planning to build a solid foundation in order to scale freely.
3) Don’t use unrelated tools/techniques
Trying out new stuff is cool. I too love playing around with new Javascript libraries, CSS tricks, and whatnot. But when working on a client project using tools you know is crucial.
When you come up with the decision: “Should I try this new fancy and pretty plugin that I haven’t ever tested before on the project with deadline tomorrow?” or “Ah, damn, I guess we will use this plugin that I am so familiar with again, even if I am sick of it, at least it gets the job done”.
Or if we go a step back – naming convention. You’ve read a few articles about BEM and you’re dying to try it out. Think about the risk of it. Are all other developers gonna understand how it works? Is Joe gonna write in his own way just because he’s sick of your innovations?
When you make such decisions, you have to think about all of this. Introducing new technique, plugin or approach must work well with everyone else in the team as well as the project as a whole. This is one of the main differences compared to working as a solo freelancer.
4) Improve the conversion rate (CRO)
Let’s go a step backward to the design phase. As mentioned above, thinking about your client’s business is of priority. Do not design just to make a page pretty. It has to convert.
When you design, see what is the main important CTA to show on top of the page. Discuss this with your marketing team. Design while thinking about the users. Is the sales page button easy to spot? Because it’s rather important.
If you decide the color scheme, make sure you have enough contrasting colors for main CTA elements. As a designer, you must have good knowledge about CRO. This will help you decide what type of design elements will fit better for a particular use case.
Do not design just to make it pretty! Make it functional, make it usable. Use graphics and images that will make the visitors act in the desired way. As a designer, you will constantly have to make decisions about it.
Streamline your workflow
To improve the general workflow, it’s best to make these decisions only once. After that just refer to what you’ve decided and then use it.
What we’re doing at DevriX is to have a list of plugins that we’ve tested and used on multiple clients. We know how they work, they haven’t failed us and they’re doing the job quite well.
1) Try to use a starter theme
To have every developer make fewer decisions, we’ve created our starter theme. It is a fork of underscores but with all different assets/ structure.
In there we’ve also taken care of many problems that we’ve encountered before. How to organize the whole Sass code – components, layouts, settings.
Then how to proceed with the mobile menu – we’ve written sample code to take care of that. We can extend it or modify it through options (variables).
We have also added sample customizer settings as well as minor tricks like versioning for assets to deal with caching issues. We add all of this in one place from which every developer can grab what’s needed. If someone encounters a problem that we often face in previous projects, we add the solution in the starter theme. That way we won’t have to make the same decisions every time and therefore save valuable time.
2) Save time by using or writing plugins
Okay, this is not so much for front-end developers or designers, but it must I will still say it – functionality that solves an often seen problem is best to be written as a separate plugin that you can reuse.
The problems you solve with these plugins will make you take fewer decisions during development time. The less you think about solving a problem and only using a solution, the more time you save (time = money). And of course, less prone to mistakes.
But is it always smart to write a plugin? If there’s one already existing – use that. Do not reinvent the wheel. Do not decide “I should write my plugin for that” instead of “I should try to find someone who already solved this issue and use that instead.”
This can very well apply for any other CSS framework or Javascript library/framework. What I do is this:
- If it’s something small and specific for some project, I write it directly for it. Example – almost every section on a landing page, blog stylings, comments, etc.
- If it’s something more complex (slider) I use already existing solution. In our case, we pick Owl Carousel for almost everything.
- If it’s again something rather complex and there’s a solution that is way too heavy but has the exact feature we need and there’s not much time to develop our own, we fork it and strip from the unwanted features.
While working in an agency you’re learning, but that’s not your primary goal. Your goal is to solve a problem in a timely matter. You should strive for a simple and fast solution that is easy to understand.
3) Write documentation
Describing the whole project will also allow each team member to take fewer decisions when developing the project. This documentation is not created for the client; it’s for your team.
There you can add the full information about assets, fonts, colors, elements, usage, features and anything else that comes to mind. In there you can also write guidelines about creating new components/features. You can have a requirement that states:
Every functionality that can work outside of the scope of a specific theme should be written as a plugin
What does that mean? It means that even if you change a theme, the functionality will still work. Now the visuals might be different, but you will still get the same outcome.
This will make your developers say “Okay, we should add this in a plugin then, we might reuse it somewhere else.” With that, you will make them take less and less decisions.
Summary
Designing and developing means that you have to take many decisions all the time. They must be guided by your client’s business needs. Reusing components, designing with CRO in mind and the users is critical.
- You should not experiment freely with new tools when you’re on a tight deadline.
- Everyone else in the team should be able to use your tools.
- When you have the time, make sure to spend a good portion of it in building a good foundation on top of which you can extend.
- Always think about reusing code.
- Streamline your process by introducing documentations and starter assets (themes, plugins, templates)
What makes you struggle the most? What are the most often problems that make you think about the best approach?