Today, I'm going to cover a topic I get asked about quite often. Every time a client emails me for the first time about a design project it inevitably leads to some variation of the question:
What details do you need from me to get a quote over and to get going?
This article (listicle? who knows?), will answer that question in ten parts and starts... now.
Let’s get the "hardest" one out of the way first.
People seem to have an ingrained fear of talking about money. Not just in the design world; but in the tech community as a whole. When trying to quote a project though, this is anything but helpful.
Knowing a clients budget range helps a designer to tentatively estimate the size of a project and if they’ll be able to help within those boundaries.
Hiding the budget or waiting for a quote draws out the estimation process and can lead to a big conflict in expectations later down the line.
So talk about the money early, to help both parties see if things are a good fit.
How do you want to be seen? And do you have any existing guidelines that will impact any design work we do together?
These two questions help understand the boundaries of the project. There's a big difference between a project that needs a whole new brand and design system and one where all of that is already in place. And the information on how the client wants to be seen has a big impact on how the designs will be put together and ultimately feel.
Who are you speaking to? For example, for a VC firm this would be two main targets:
This will be completely different for every single project and each business will have its own nuances. Even with the above example of a VC firm, there are a host of different kinds of firms that position themselves completely differently. Knowing these things alters and refines the targeting to exactly who is being created for and also makes finding people to test what we make with a breeze.
Who you're targeting is only a part of the battle. You also have to solve a problem for that potential user. And not only solve it but solve it in your own way. (Wow, I said solve way too many times there).
This is another thing that will vary differently on a case by case basis. But it’s important to know exactly the problem being solved and how it gets done.
That leads us into number 5...
Once you've established the problem (or problems) you solve, you need to put your spin on it.
This is where you differentiate your product and business from others. By showing your character, edge and what makes you different from everyone else doing exactly the same thing as you.
Too many people overlook this and end up with something that doesn't have the vibe or resonance that it should. So always take time to explore the things that will set you apart.
Here we determine what we want the end goal of the user to be on the app/website/product/whatever. This ties into the functionality and features of what will be made.
This knowledge helps a designer to build out the "loops" the app will feature. Loops is a term I borrow from the gaming industry quite a lot to explain how people interact with things. In video games, a "gameplay loop" is the repetitive action that a player takes in the course of the game. There will usually be only a few loops and all of them will form around a "primary gameplay loop".
For example, in Call of Duty the primary gameplay loop is to run around and shoot people. There may occasionally be secondary loops such as capturing flags or zones, but the primary loop always remains the same.
Why am I talking about games? Because just like games, what you create needs gameplay loops. A task or series of tasks (in some cases repeatable) that your users partake in when they visit your website or use your app.
Let me explain in the context of a product everyone will know, even if they hate it: Facebook.
On Facebook, the primary loop is to open the news feed and ingest content. While the secondary and tertiary loops lie in things like sending messages or interacting with and posting content.
Every product requires this kind of thinking. I got a bit carried away and did a long-form explanation for this one point, but it's an incredibly important part of scoping out, and ultimately creating, a design project.
This isn’t resources in the sense of money (we covered that above, remember?), but more in the technical or existing assets you have.
These can be anything from you having already gotten a front end developer on board, to detailing a big PR campaign you have planned for the launch.
Ultimately, anything that will help the project be a success or have an impact on it before or after launch, is good to know about as early as possible. So that a plan can be made to best take advantage of these assets.
Just as it's great to know anything that'll make the project easier. It's just as (if not more) important to know of any limitations.
Examples of these could be things such as the following:
The knowledge of this kind of information allows for contingency planning and ensuring that any significant workpieces are scoped in advance. Saving any resulting headaches later down the line.
I pondered over including this one or not for a while. But ultimately as we move into the 2020s, content has become the most vital pillar of a business. It's how people find you, and why they come back.
Knowing how important content is to the "where people come from" part of the equation, it's a good question to get answered early on. This lets a designer get an understanding of the frame of mind and mentality someone might arrive with. As well as how much information is readily available for them on your brand.
I'm not expecting anyone to pull some Mystic Meg type of shit with this one. I'm more speaking in the vein of what updates and expansions are planned for the future?
Knowing where the product is going in the future helps guide the decisions made today. It means that things can be planned for that will be there down the line as part of the foundations of the project.
I tried to keep this one pretty clear and to the point (apart from my brief tangent on video games in the middle), so it doesn't include every question that will eventually need to be asked. It is intended as a base to build from and scope things out correctly.
Think there's anything I've missed? Let me know in the comments!