Part Three: What to expect when working with a development firm
Joshua Davidson wrote this article
For those of you who happened to jump right into this blog series, you’re reading the third of four parts that we will be releasing over the next four days. It’s highly recommended that you read this series in order, starting at Part One: Preparing to work with a development firm.
Contracts have been signed.
The proposal has been hammered out.
You are ready to get started on bringing your application to life, or as we like to say here at Chop Dawg, you’re ready to make this app’n!
Few things. To begin with, the first thing a company like us will do is schedule a kickoff meeting.
Traditionally these are about 1-2 weeks after the contract has been executed. During this timespan, companies like us will begin assigning our team members to your project and getting them prepared to start. At the same time, we will begin working with you, scheduling our kickoff meeting, weekly meetings, giving you some homework assignments to prepare you for the upcoming months.
It’s finally game day. The kickoff meeting is ready to go!
The kickoff meeting is a critical meeting.
It sets the tone for your entire project.
A lot of the groundwork is laid here.
This is where you are introduced to the key team members assigned to your project. This is where you begin getting questioned on everything from your favorite applications, brands, products, to start understanding your personal preferences. This is where you are questioned about why you are building this app, why you are passionate about this, asking the hard-hitting questions.
There is a reason for this.
The first step to your project is always design.
Companies like Chop Dawg spend almost half your projects in the user interface design stage. This is by design (no pun intended).
Remember in the first part of this series where we discussed that room for interpretation is bad?
Imagine having that on your app, where a development team develops your product differently from what you had envisioned.
Communication is key!
From there, expect to have weekly meetings.
You do not want to work with a company who leaves you in the dark, giving you once a month updates.
Remember, you are the customer, you are the one paying, this is your baby.
Weekly meetings are essential.
This gives you the chance to always hear what was done the week before, the game plan for the week ahead, and where you are overall.
Your chance to ask questions, talk to your whole team and see, discuss and review progress.
It also gives the chance for a company like us to ask you, the client, questions and for feedback. Open communication should always be encouraged because again, communication is key. Both parties are a partnership and should always be approached in such a manner!
You should also expect when working with high-quality companies like to us to be treated as an extension of the team. Even with weekly meetings, this shouldn’t be your only updates from us. You want your team’s cell phone numbers and email addresses. You want to be easily collaborating through tools such as Google Drive, Trello, email, TeamGantt, and even Slack or Basecamp.
So now that the communication expectation is nailed down, let’s get into the actual project, shall we?
Your project design process is broken into the following deliverables…
2) Mood Boards (also known as Style Tiles)
3) High Fidelities
4) Product Flows
Let’s break down which each one means!
Wireframes are the longest part of the design process. Think of these as the black and white blueprints for your entire application.
They define everything.
Every single screen.
Every single button.
Every single animation.
How things will look, feel, touch, move.
This is where every screen is carefully thought-out.
It is important, as mentioned, to handle this now vs. doing it in development later.
You want your developers to knock this out of the park once.
You don’t want constant redevelopment or worse, room for interpretation.
You want everyone to know, from the designers to the developers, to you, how your app should look, feel and behave. Get it done right without needing to be redone, without frustration. Plus, it is easier to tweak an idea in design vs. development. Think about how you can make edits in design in less than a few hours? That same edit, in development, can translate to months.
So now that wireframes are approved, what is next?
Simple. Mood boards.
This is where you nail down your branding, the start of your app icon and logo design, and most importantly of all, your color scheme. Identify the typefaces to be used with your brand, the colors planned to be used, the way your product will feel. As we like to call it at Chop Dawg, the narrative your app should follow.
This process is typically quicker than you might think. Once it feels right, it feels right.
Now that mood boards have been nailed down, the part you have been waiting for the most, the high fidelities. Otherwise, known as mockups.
These are pixel-for-pixel versions of what your app is about to look like. You can show anyone on the street a hi-fi (high fidelity), and they would think you are showing them a completed app. Think of these like an IKEA Kitchen Model. They just aren’t hooked up to the plumbing or electricity yet (that is when the development comes in).
This is where you nail down and complete all of the designs of your app.
What is the verbiage and language that should be used?
What will every single screen look like?
And this brings us to the last piece of the design process, product flows.
Have you ever noticed when an animated movie sketches out every scene and passes them to a wall in order from start to finish? This is what a product flow is.
Again, we hate leaving room for interpretation and you should too. You want to avoid at all costs anything being left open-ended.
Product flows do just that.
This defines where data will go. This defines every screen in the order they should load and appear. This defines how an unread notification should be determined and when a notification should display. It shows every detail of your app.
Again, make it so everyone involved already knows how the final product should look and function. This way in the later steps we will explain in a minute, it is easier to track bugs and avoid having to redevelop anything, driving up your costs and time. The goal is to get to the finish line as quick as possible for you without sacrificing an ounce of quality.
Quality over quantity, and urgency over rushing. Never forget this.
The design process of your project is done.
Your vision has manifested.
Here is where the magic happens.
Development for both the web and mobile are nearly identical. Over the next several months, your team will turn your pretty images of what your product will look like into functioning code.
Suddenly, each week, you have a new visual to look at. If you’re building a web app, you will have a website URL to visit and track updates. If for mobile, you will use an application to install updates of your app, called a build.
Weekly meetings at this stage are just as critical as ever.
The biggest frustration most people have, if not communicated to properly, is that development isn’t instant.
Some features can take months to develop and until the development of that is done, you may not be able to visibly see it. It does not mean it isn’t being built or on target, but it doesn’t have the same visuals as a user interface design edit or the creation of a new screen. These can take time.
Potentially even more frustrating, sometimes features can be done, but do not appear completed because they need to work with other functionality still being developed.
This is natural.
It is important for companies like Chop Dawg to openly communicate progress and explain these details. If a company fails to do this, it can become frustrating and to someone non-technical, feel like progress isn’t happening.
Remember, communication is key.
Most app development projects fail for companies, not because they can’t produce the work, but because they failed to communicate.
The reality is to plan for your app not to fully function, to test it fully, until development is completed. It is important for companies to remain open about expected completion dates at this stage. Never let it be ambiguous, though do expect date ranges, as estimating to the best of their ability is well, the best of their ability. Development is just as much an art as it is a science.
So, the day finally comes, your team informs you that your project has completed development and is ready for testing.
Here comes the biggest thing to communicate.
It is ready for testing.
This doesn’t mean you are ready to launch quite yet.
No, it means it is time to crush bugs and make this app perfect.
More often than not, as features are completed, new features are worked on. New features can break old features or make them no longer work as intended.
This final phase of the project is the bug fixing stage.
This is where you identify errors of the product not working as intended or defined in the product flows (wink wink) and fix them. Similar to how these broke with new features being built over time, the same thing can happen to working features as bugs are fixed. They can break them.
It is important to be very detailed when defining bugs and with companies like us, be open about what is being found, worked on and prioritized.
Companies like us will define our bugs with three priorities.
Priority 1 items, Priority 2 items, and Priority 3 items.
Priority 1s are items that break the product from working completely. They need to be fixed in order for the product to function.
Priority 2s are items that need to be fixed to launch, which though do not keep the product from working as intended, they will turn off potential users and harm the user experience that everyone worked so hard to carefully craft.
Priority 3s are small bugs. Things that most people won’t notice but aren’t quite perfect yet.
With most of our clients here at Chop Dawg, it is ideal to nail down Priority 1s and 2s in order to launch. Traditionally most Priority 3s can always be tackled after launch. This is especially helpful to avoid what we like to call scope creep, keeping you raising that bar/standard to launch due to your fear to launch. Again, we like to cover all of these topics and have written an awesome blog post in the past about this very subject matter which you can read right here!
So it has finally happened.
Your application, after all, these months of hard work, planning and meetings, is ready to finally launch.
You’re ecstatic. You’re anxious. You’re ready to go.
The launch button is pressed (figuratively) and it is now in the market.
What is next for your app development company and you?
Does it all end here?
It should only just be beginning.