Man, why’s the office computer guy or gal such a jerk? A common refrain, right? It’s such a well known trope, Jimmy Fallon wrote a series of SNL skits about it. If you work in software development, you’re probably sick of hearing it. I am. But not as sick as I am of it ringing true.

Arrogance and unkindness were long de rigeur in an industry and culture of fake-it-’til-you-make-it and trying to seem like the smartest person in the room. Thankfully, at long last, that is starting to change. And that’s great not just for our industry, but for what our industry builds. Compassion and kindness don’t just build better people, they build better products.

On one level or another, we all build software for humans (unless you find yourself inside a Terminator movie, then probably just keep your head down and do your best not to anger Skynet). A funny thing about humans is that we appreciate kindness and we can become loyal to the people we meet who are kind. Kind software products win. The type of products that are easy to use and anticipate a person’s needs are the ones that people keep coming back to. Apple won’t be dethroned by a superior technology, but I bet they’ll someday be defeated by a superior user experience.

Can you imagine how far along our industry would be if we’d been thinking about people all along? Software that builds relationships and loyalty in the same way an agency like Centresource builds relationships and loyalty with our clients is a way more exciting future than software that ticks off functional requirements. Try it. We are.

The day has finally arrived. For the past few weeks, you or your team have put in a lot of effort, time and unwavering dedication just so you can launch a perfectly functional website that offers exemplary user experience. The only thing separating you from calling it a job well done is to formally publish the pages and declare the website officially “live”.

However, before you do that, there are a lot of things you need to double check. Putting together a website is no joke. Every overlooked error and mistake can hurt your website’s user experience level, even minuscule things like a misspelled word or a single broken link.

Believe it or not, even seasoned web developers and marketers have made the mistake of being too eager to publish a website that they forget to check and double-check important details. To prevent yourself from falling into the same trap, here is an easy-to-follow, yet comprehensive checklist that can help you cover all the necessary bases before launching your website.

Content Is Key

The cliché “content is key” is popular in the Internet marketing universe for one reason – it remains true to this day. Even if you have the flashiest and most unique of website layouts and the most interactive of page elements, if your content is incomplete or horribly placed, then all your efforts are for naught.

This does not apply to text alone, although it still comprises majority of all website content. Make sure you have an editor or beta reader on your team to go through all pages and make sure that everything is complete. All articles, posts and web copy should be at the proper place, and devoid of glaring grammatical and spelling errors. Formatting should also be taken into consideration, from the headings to the text alignment. Paragraphs should be kept short and in order.

Even other page elements like videos and images should be in their proper places. Make sure they are inserted into appropriate sections and that all image and video links are working. Gone are the days when most website visitors are limited to the PC, so cross-platform responsiveness should also be ensured.

Lastly, make sure all copyrighted materials are properly noted and that you have rights to all images and videos placed on your site. Also, ensure that all content is plagiarism-free.

Design Elements

When it comes to design, the first thing you need to check is whether all codes are working properly. The last thing you need is a wayward html code standing out like a fish out of water amongst your page text. If all coding and scripting is done properly, all page elements should load properly and all design elements in their proper places.

Check if your website is responsive and intuitive. Load the website using several different browsers to ensure it is optimized for all browsers. Check if the website is optimized across all platforms by opening it via a smartphone, a tablet or a mac.

Functionality and User Experience

This section may be the hardest to check of them all, especially if you have a large website. Functionality means your website pages should work as they should and all visitors should be able to engage in several activities in your website without any hassle.

Make sure all submission forms work properly from start to finish and that the finished form is sent to the correct address or database. Also, ensure that all prompts are working, from redirect prompts to thank you messages for different forms.

Also, double check to see if all internal and external links are working, and that all external links open up in a new tab or window. Check if RSS and social media feeds are properly embedded and updating in real-time. If you are using any third-party tools, double-check to see if all applications are not only working, but also user-friendly. You may need to tweak some settings if certain processes like purchase tunnels and customer service portals are too convoluted and confusing.

Search Engine Optimization

SEO now plays a big role in website development, so make sure you have an expert on your team to check if your website is not only appealing to readers, but also to search engines. Double-check all page titles and meta descriptions to see if they pass SEO standards. All content must have the proper keyword densities and metadata should be present on all applicable areas. Make sure that your website has its XML sitemap and that has been submitted to all search engines.


More often than not, people often neglect Analytics when launching a website. It is important that before a launch, all web data capture devices and analytics tools are properly functioning. This way, you know how your website is doing from day one. Make sure all your Analytics accounts (Google webmaster, Adwords and Analytics) are synced to your website.

Website Security And Compliance

Here, you check if your website is ready for any attacks from outsiders. This is also where you check for any legal-related issues on your website. Make sure all monitoring scripts, firewalls and other security measures are up and running before you launch your website. Don’t forget to tweak your data backup settings to allow for regular data backups at your desired frequency. All confidential information, website credentials, usernames and passwords should be stored in a separate, secure database.

It is also recommended that your team hire a legal counsel to double-check all compliance-related items on the list, preferably someone with a lot of experience in Internet laws. You must also make sure that all content is plagiarism-free, and that your website is complying with all requirements related to borrowed images, fonts and scripts.

Final Words

Launching a website can be stressful, even for seasoned veterans in the industry. However, with the help of a checklist or a seasoned web development firm, you can cover all your bases in an organized fashion. This way, you leave no stone unturned without taking too much time and delaying the launch date.

Have questions on pre-launch steps? Drop me a message on Twitter or share your own pre-launch checklist in the comments below.

If you don’t spend your days heads down, immersed in technology it’s easy to feel intimidated. It’s complicated, it’s full of unfamiliar acronyms and it always seems like there’s some secret knowledge that you can’t quite grasp. And sometimes, well, it is hard. But it’s not rocket science either. At its core it’s something you already understand. It’s building, construction, putting things together to make something new. Sure, we’re using code and not boards and nails, but in the end they have more in common than meets the eye.

Every building starts with a goal. Not with a hammer. Not even with a blueprint. Just a goal.

“I want to house two adults and two children on 0.2 acres of land.”
“I want to provide public library services to an area serving about 100,000 people, and I want to offer them about 25,000 books.”

Those two are very different. You’d hire a different architect. She’d build you a different blueprint. You’d hire a different contractor. It would take more money and more time to build the library than to build the house. And you would certainly never start building a house for a family of four and halfway through decide you wanted to turn it into a public library. That’s common sense. It’s smart planning and decision making. You started with the end in mind.

Technology is no different. You’ll never make smart decisions if you don’t understand your goal. And just as in building, there is no such thing as build it and they will come. Who will come? Why? What do we want them to do when they get here? Will they pay us to be here? If not, who will?

Start with the end in mind. Don’t decide what you’re going to build until you know where you’re going. “We want a mobile app?” “Do you? Why? What is the purpose of having a mobile app? Do your customers have mobile devices? Are they open to using the internet to do business with you?” Smart planning. Smart decisions.

Even though the web industry is fairly young, we’ve already seen an innumerable number of trends come and go. Obviously, some elements of web design will naturally follow trends, but there is one long-standing trend in particular that could be hurting your web presence and your bottom line.

The past decade arguably has been defined by the rise of the Content Management System (CMS). The benefit of a CMS is in the ability for non-developers (marketers, site owners) to control the website content. It’s putting the control into the right hands – after all, developers don’t typically think in terms of messaging and content. I am a developer that specializes in the Drupal CMS, so I have spent the majority of my career creating projects in this way. But I think in too many cases, we’re missing the forest for the trees. So, I want to take a step back and encourage you to ask an important question at the outset of your next website engagement. Do I really need a CMS?

Let’s look at the ramifications of this decision. First, a CMS costs more. It costs more up front and it costs more in the long run. It involves heavier needs/support in terms of a web server. So, you’re making a conscious decision to devote a large chunk of your budget to this need. Budget that could be put towards higher design, user testing, or better-defined paths of success on your website – things that all can have a very measurable return on investment. Second, a CMS nearly always will be less performant. And despite network speeds increasing regularly, performance matters more than ever because of the rise of mobile usage. Now, any CMS worth it’s salt will offer ways to optimize for performance but this is typically not estimated into a project and is only done if the developer cares about his/her work enough to go above and beyond to provide it. In short, the decision to use a CMS is one that needs to be made wisely.

So how do you make an informed decision here? Begin by asking yourself the following questions:

1. Do I have content on my website that needs to be updated daily/weekly?

These are likely the dynamic sections that you will want control over in a CMS-like fashion. If you will only need changes made every few months, weigh the cost difference here. If you are using an agency that can respond quickly to your needs or you have an internal development team in-house, it will likely be more cost-effective to forego a CMS build in this case. That said, if you answered this with a “Yes,” move on..

2. Does this content fit into the news/blog post type (title, body, post metadata)?

If these sections fall into the post/article category, there are a slew of options to give you control over these without encasing your entire website in a CMS. There are hosted blogging engines like Ghost, Medium and Tumblr and also some lightweight static options such as Jekyll and Statamic (and many more). These will all allow you to control this content easily, but without the overhead of a CMS wrapping your entire website. Also, these hosted options often have the best content editing experiences on the market. If you answered “No” to this, move on..

3. Do you have the ability to support the regularity of these changes in-house?

This one requires some thought and honesty. Most clients have unrealistic expectations about their ability to update their website content regularly. Knowing that a blog is a good idea in terms of long-term SEO success is one thing, but being able to support this feature is another. Not only does it take time/energy regularly to actually create the posts, any CMS involves some level of training/familiarity that must be supported internally on your end. An untended blog is worse than no blog at all.

Even if you answer the above questions and it appears to come out in favor of a CMS, talk to your agency about options to meet your distinct needs. The overhead of a CMS in terms of budget/performance is a very real thing, and should be avoided if possible. There are definitely cases where a CMS is perfect, but there is a distinct cost/benefit ratio to be weighed. Make sure you’re spending that money wisely.

You have an idea for a startup but have very little money and no coding expertise. You’ve come to the right place. There are so many services out there that can allow you to launch your startup with minimal cost and little technical expertise. But how to know which ones are right? And what steps should you take before knowing when to code? I’ve outlined the steps you should take before writing one line of code.

  1. Wireframes/Mockups
    You need more than an idea on the back of a napkin before you start coding or hire somebody else. Wireframes are a great way to get your idea out of your head and easily communicated to others. Wireframes are low-fidelity sketches or drawings and can be done in a notebook or on a whiteboard. To make your wireframes digitally presentable we recommend POP or Flinto. But there are also many more out there. Feel free to explore.If you’re looking for services that offer more hi-fidelity output that is presentable for clients and offers a lot more functionality we suggest Invision.
  2. Get Interest
    If you’re launching a startup, hopefully you’ve told all your friends, family and social networks. You’ll need a place to direct them to when they ask where they can learn more. Do you need to code a website now? NO. Create a barebones website with Wix, Squarespace, Weebly, WordPress, or Populr. All of them require no coding to get up and running. If you want to be an all-star, add a sign-up form to capture visitors to notify them of when your startup goes live. You can embed a Wufoo form or even link to a Google Doc Form if that is easier for you.How do you know if people are visiting your site? Be sure to install Google Analytics.
  3. Paying Customer
    If you have gotten somebody to pay for the service your startup provides, I think it’s safe to start coding. However, there is no shame in keeping the process manual until you get more paying customers than you can handle.If you haven’t gotten somebody to pay, GET THEM TO PAY. Having your friends say your idea is awesome is much different than them handing you their credit card. Getting payment is the ultimate validation that your idea is worthwhile.Collect payments on-the-go with Square, embed a payment form with Stripe or sell your digital product with Gumroad. Make money before coding!

If any of these recommendations seem to advantageous for you, feel free to DM me on Twitter or leave a comment below and I’d be happy to walk you through it. We’re here to make your business successful.

Move over, Objective-C. Swift is the new language of choice for Apple developers and it has the potential to not only make apps run faster, but speed up development processes.

A surprise announcement at The Apple Worldwide Developers Conference (WWDC) 2014, Swift has been generating a lot of excitement. Haven’t been able to keep up? Don’t worry. We’ve got you covered.

Here’s everything you need to know about Swift – and to even get started using it:

What it is

Swift is Apple’s new programming language for building apps on iOS and iOS X. Apple is billing Swift as a faster, more efficient and effective means of building software apps for iPhones, iPads, and Macs.

What’s great about it

Swift makes it easier for developers to write apps because it’s code is easier to read, write and collaborate on than Objective-C, the current language used to build apps for Apple platforms. Additionally, Swift appears to be very easy to learn. By lowering the barrier to entry required for developers to master a programming language, Swift could open the doors for a newer, bigger generation of talented developers and innovative apps.

Why you should care

Consumers should care because Apple apps are about to offer even more functionality. While this is partially due to Swift, it’s also related to a number of other, powerful software development kits (SDKs) released by Apple, such as HomeKit and the TouchID API, which can help apps incorporate parts of your house and fingerprints, respectively, into mobile apps. It borders on what you’d read in science fiction. If you’re interested, you can read about some of these SDKs released in conjunction with Swift here.

Developers should care because Swift truly is the future of iOS development. Apple already has made it clear that Swift is here to stay. And what’s not to like about it? Swift works with and is interoperable with Objective-C, so even if you want to drag your feet, you can still write in the current, lower-level language. Heads-up, though: all signs point to Swift one day replacing Objective-C entirely.

What we think

Like others in the developer community, we think the sky is the limit for Swift. It’s much easier to write than Objective-C.

At the same time, we’re exercising a patient, exploratory approach with Swift, as we do with any new programming language. If you’re interested, you can read more about our general thoughts on why new languages are created, whether or not a new language will be adopted, and how it might affect your business in an article for the Nashville Technology Council here.

What others are saying (aka what you should be reading)

For developers, we’d recommend checking out:

For the rest of us:

Where you can begin to learn, code and test it

Developers wanting to dive right into Swift can download the XCode 6 Beta and test it out. However, according to Engadget, submitting an app written with Swift to the App Store will have to wait until iOS 8 and OS X Yosemite arrive this fall.

For those seeking tutorials, code samples and references, we’ve found the resources at to be helpful.

Will it live up to hype?

Our prediction? Yes. Swift looks like a solid improvement on top of Objective-C. It’s more readable and requires far less extraneous code to achieve the same results as before. More importantly, Apple has already given Swift its seal of approval – so we believe it’s here to stay.

What do you think of Swift? If you have any questions, comments or links on your mind, share them in the comments below!

So here’s the scenario: you have a product you want to build, but like most people you are not one of those “coder” types. At a minimum, you need to hire a freelance web developer to bring your idea to life. Ideally, this developer also has the vision and technical know-how to help with product development, too.

This means you face quite a challenge, especially here in Nashville. This isn’t Silicon Valley, where the developers grow on trees. This is Music City, where the only species of trees we grow are “guitar player” and “songwriter.”

If you need development help, you really have two choices: hire a digital agency or go find a unicorn.

In the web business, a unicorn is what we call a developer who can do it all and do it all really, really well. We call them unicorns because they’re almost impossible to find.

That being said, if you lop off the doing-it-well part, you can probably find  a person who at least can do it all. But is this unicorn a better option than going with a digital agency that might have more up-front costs?

I’ll be the first to admit I’m biased, but the smart move is to choose an agency for your initial product development needs. Here are five reasons why:

1) Finding a unicorn is hard

It’s hard enough just to find a developer-for-hire, but finding a unicorn can present an entirely different set of challenges.

Outside of trolling coffee shops, your best bet to find a developer is to look online. But generally speaking, individual developers don’t have the same SEO juice that an established firm will have. They might have a simple resume site, but marketing and visibility is more of an afterthought. Personally, if I didn’t work in this industry, I’m not even sure I would know how to find talented freelance developers. You might be able to find a freelancer on an outsourcing site, but that experience always feels so overwhelming– to say nothing of the quality or communication issues you will inevitably face.

In a company’s early stages, you’d be better off focusing on your business, rather than a unicorn hunt.

2) Vetting a unicorn is hard

Even if you found a bonanza of developers somewhere, how do you know who is good, who is great and who might be your unicorn? Do you know whether or not the alphabet soup of  skills in his/her resume is what you need to accomplish your goal? More importantly, do you care? You just want someone who can execute the idea you have.

The tricky part about vetting a potential developer is knowing if the developer is telling the truth or exaggerating. I could tell you I’m an expert in Java and bombard you with various official-sounding terms. You would have no way of knowing that, at least at this point in my career, I have not written a single line of Java– and I’m not even a good liar.

I’m not saying that freelancers are crooks and thieves. I know many freelance developers who are talented, honest, and hard-working people. I’ve just noticed they tend to have trouble having bosses.

If you’re fastidious, you can ask for references or to see other client work the developer has done. But at the end of the day, you, with your limited budget and your big idea, likely do not have the skills and experience necessary to accurately vet software developers.

3) Keeping a unicorn is hard

There are many reasons to be a freelance developer. Most will probably tell you they do it for the freedom. What does that really mean?

In my profession, freedom means two things: not working on projects you don’t want to work on and not working for people you don’t want to work for. (Remember what I said about unicorns and bosses?) What freelancer freedom means for you is that the moment you or your project becomes unpleasant or boring, your unicorn can simply move on.

Freedom is great for unicorns and terrible for you.

4) Continuity between unicorns is hard

If you think hiring a freelancer to build your project from the start (“green field”) is difficult, finding a freelancer to maintain and/or rescue your half-finished (“brown field”) product is nearly impossible. The market is so good right now that freelancers don’t have to take on the gargantuan task of picking up after the last developer, if they are even able to. Unicorns can just wait for the next “green field” opportunity and enjoy their freedom.

But let’s say you do find another freelancer willing to pick up your project. How much time do you think you will have to spend bringing him/her up-to-speed? Did your previous developer keep detailed and current documentation on the way your app works and plans for the future? Spoiler alert: he/she didn’t. You know how I know? Freelancers never, ever, ever plan for the next developer. That kind of thing is always the first thing overboard when there aren’t enough hours in the day — and there are never enough hours in the day.

Even if your old unicorn could find the time to keep detailed documentation, the amount of knowledge that must be passed from one person to another in this scenario is too great for the written word. I get chills just thinking about finding myself in that situation.

5) Being a true unicorn is hard

Above all else, I am a developer. My skillset leans heavily towards application development and not any of the other things that go into product development. Thankfully for me and the clients my agency serves, I do not have to do project management/UX/design/budgeting/billing, as well as looking for more work at the same time. I spend my time doing what I’m good at: web development.

When you hire a unicorn for product development, you are asking one person to wear multiple hats. Not only is it extremely difficult to find a unicorn who can do all of those things well, but it is nearly impossible to do it all at once. We’ve all heard the stories of “communication black out,” where developers just don’t respond for a while. Well, any time a unicorn spends answering your emails or creating a report is time he/she isn’t spending  on your code base — the very code that you hired them to work on.

Digital agencies to the rescue

Agencies are a great choice for early product development because they solve all the problems listed above with three, general traits: experience, consistency, and diversity.

Agencies are easy to find. In fact, digital agencies are generally falling all over themselves to find new business. Even if you have only heard of one (ahem, Centresource), most agencies will tell you about their competitors if you ask. They also should be able to show you recent work and give you verifiable references of past and current happy clients. This way, you get to leave the developer vetting (and the unicorn hunting) to the agency.

More than anything, you should look for the agency with the experience to understand your vision and the expertise to deliver your product.

Unlike the land of unicorns, agencies use consistency to marginalize the pain of keeping talented developers. Developers come and go, but agencies like Centresource have the experience to manage the turnover with well-tested company standards. This way, if I’m working on your project for my agency and I get hit by a bus, I know the next developer will find comfort in the fact that your project was done the way she expects. The standards, practices, and tools we use allow us to bring developers rapidly up-to-speed. With the support you receive, your agency is your team. And that’s what really matters: having the right people on your team.

With a whole agency working for you, offering a diversity of talents, you receive the sum of its collective expertise. I do Ruby on Rails pretty well, but the projects I work on have the benefit of input from UX Experts, Strategists, and Designers, to name a few. If I run into a problem I have not solved before, chances are someone on the team has been there before. I have task-master Project Managers who keep me focused and under budget. More than that, the Project Managers keep in contact with you, so I can stick to writing code. That is good for your bottom line.

Coming up with a great idea is hard. Executing the technology is hard. I hope finding the right people to help you just got a little easier.

From working the last 6 plus years in the web industry, I’ve come to learn a good bit about working as a part of a development team. In development, a lot of thought goes into how to structure, name and organize code. When you work alone, this really becomes less of an issue. The piece of code that you leave in one place, is there exactly where you expect to find it when you come back. Working with teams brings the benefit of more horsepower, but unless you are intentional about being in sync — you run the very high risk of wasting a lot of that potential power as a team.

While writing performant code is always a primary focus, I’d argue that writing readable, quickly understandable code is almost just as important. Many times I’m faced with a situation where writing performant code is easy, but writing code with a low level of cognition is the challenging part. Here are three quick tips I’ve learned to produce easy to understand code:

1. Be Consistent

Be diligent about maintaining patterns in your code. If you decide to order your CSS attributes by the alphabet (I do), then do not break that habit anywhere. Get together has a development team to have open, inclusive discussions about the best way to write your code syntactically. Your team may have lots of differing views, but avoiding conversations about them is only going to slow your team down. Come to the table with an open mind and a goal of improving the entire team’s efficiency.

2. Provide Mental Breaks

A problem I see often is large, complex chunks of code. Whether this is a single file with 900 lines of back-to-back HTML or it’s a JavaScript function that performs six very different tasks. Consider inserting line breaks in to HTML providing a buffer between “blocks” of common HTML. Take the giant JavaScript function and split it into five or six separate functions to promote separation of concerns. There are plenty of ways to reduce the complexity of code, but looking for areas to give your fellow teammates mental breaks is a nice favor.

3. Pretend to be a Coworker

When organizing, naming and writing code, take opportunities to ask yourself “if I were to be given this code base with no prior domain knowledge, would I understand what is going on?” If the answer is no, then you aren’t doing a very good job of preparing your next teammate for success.

It’s easy to live in the moment and say “I’m the only one that is ever going to touch this code”, but nine times out of ten that I’ve said that it’s turned out to be untrue. Make attempts to push that mindset away and always be on the look out for your teammate that’s opening in your code next.

These are just a few tactic that I use when I’m writing code. What are some steps you take to improve your teams efficiency? Let me know in the comments below.

Recently Centresource published our first open source tool to the world. Please welcome Playbook. Playbook is a Yeoman generator to get you building interfaces faster. Jekyll is included for static site generation. Bourbon, Neat & Bitters are included to help you write CSS faster.

The goal for Playbook was to help the Centresource UX team be more productive faster. Every product that we design needs concept validation at some level. At times that’s accomplished with something as simple as a series of low-fidelity wireframe sketches on paper; othertimes, however, we want to convey user flows in the browser. Enter Playbook.

Playbook allows the Centresource UX team to quickly and efficiently build out clickable HTML prototypes. Our prototypes will consist of varying levels of polished style depending on which stage of the project we are in. Centresource offers three levels of prototypes:

  • Flat Prototypes
  • HTML Prototypes
  • Production Prototypes

Flat Prototypes

Flat prototypes are just that, flat. They consist of hand drawn sketches or Photoshop designs that we string together using apps like Flinto or InVision.

HTML Prototypes

HTML prototypes are clickable prototypes that we can have users interact with inside their browsers. We typically forgo focusing on aesthetic design and rely heavily on the existing styles of Bitters. The idea is to focus on how the product works and validate user flows, before spending time on the way the product looks.

Production Prototypes

Our production prototypes are the most production-ready versions of prototypes we build. The majority of the time we build production prototypes for clients that have validated their idea already or have gone through a flat or HTML prototype with Centresource.

With production prototypes, we build all of the front end markup, styles and interaction JavaScript that a product will need. At the end of building a produciton prototype, we have a front end code base that is ready to be integrated into a framework. Many times it’s handed off to the Centresource production team to build an Ember.js or Ruby on Rails app in-house. Other times we hand of the production prototype to a client’s in-house development team — to build a .NET app for example.

Open Sourcing

While building a tool like Playbook benefits Centresource, we did not want to stop there. Centresource’s development team makes heavy use of many great open source tools, so it only felt right to share our tools with the open source community as well.

Playbook is available via the npm website and can be installed like all other Yeoman generators: npm install -g generator-playbook. For more information, visit the Playbook website.

Centresource’s approach to product development includes a product planning and prototyping engagement. Bryan Clayton is the co-founder of GreenPal and our neighbor in the Missioner Building in Germantown. In this guest post, Bryan has written about prototyping and what it means to his business.

About 2 years ago, three ambitious friends and I decided to take the plunge and bring our startup idea GreenPal to life. GreenPal is a mobile/web application that enables homeowners to order lawn care for their home fast and easily. We describe is as Uber for Lawn Mowing.

At the time, not one of us knew how to code, but we didn’t let that minor issue get in the way of pursuing our dreams of tech startup success. Our first inclination was to partner with a development shop to build the first version of our product, and then, we would go to work marketing and promoting that product.

Our team met with every development shop in Nashville, and ultimately decided to work with one of them. This was our first critical error in our approach to building version one. We met with the development shop’s team, laid out our product vision, and began to work on a specification document with their team that outlined features and functionality the product would perform. Quite honesty, our team didn’t know what the hell we were doing, and at the time, this seemed like a logical first step.

Fast forward five months, after several meetings and discussions, our team got to sit down and test out the “finished” product for the first time. I remember the sinking feeling in my stomach when I first laid eyes on our user interface… I was immediately terrified to see that our product was difficult to use, non-intuitive, and very different from the vision I had initially had in my head. My team and I began to voice our concerns, but it was too late; they had already built this application front to back so any changes would result in change order expenditures.
Despite the awful user experience and interface, we launched the application in the Nashville area. We then met with every early adopting customer that would meet with us to get the painful feedback on the product we already knew was terrible. We listened to the same issues over and over, noted all the customers’ disappointments, and conducted usability tests with them diving into the minds of our users to figure out the large gap between their expectations and what we had built. The idea in our heads, what was built, and then, what the users expected were all miles apart. Ultimately, we realized that we needed to rebuild the entire application from scratch.

On the second go around, we have taken a different, much smarter approach. We started by creating a prototype which consisted of entirely redesigned screen shots linked together by Solidify, a handy prototyping software. This created a simulated experience that we were able to place in front of users and get immediate feedback. We observed over a hundred usability tests on the newly laid out interface, making adjustments after each group of five testers. We found this iterative process really smoothed out the speed bumps on our product, reduced friction, and added clarity for our users.

After countless of these product iteration cycles, we developed an interface and user experience that we were proud of and that people loved. Then, we handed that off to the developers to build. The best part is that all of the iterations were easily performed in Photoshop on the psd designs, rather than having to adjust hard coding each time.

I strongly recommend any startup to take this approach when creating a new product from scratch. It is easier, faster, and more cost effective. You’ll preserve your sanity and create something you’ll be proud to show your mom. If you do create a prototype, feel free to reach out to me, I would love to try it and give you my feedback.