Loading...
Menu

LiveApp - 12 Code Commandments

  • *

The 12 Code Commandments are the twelve steps to follow when building a new software. Each step highlights a fundamental piece of the project and then provides some insight for what to look out for.

 

 

To get started, here are the 12 Code Commandments:

 

1. Outline the main purpose; the functionality you need vs want.

 

2. Wireframe everything! Every page, button, pop-up you can think of.

 

3. Architecture design. Plan to scale.

 

 

4. Tweak the wireframe and optimize for usability.

 

5. Milestone the priorities. MVP first and then the UX.

 

6. Start developing basic needs. Any uncertainties should come first.

     

7. Get weekly/daily updates.

 

8. Alpha Testing: Involve yourself in weekly testing.

 

9. UX testing: Plan to optimize the UX and incorporate feedback.

 

10. Beta Testing: Thorough testing from actual users not involved so far.

 

11. Incorporate Feedback: Make final adjustments to UX.

 

 

12. Launch Software. It generally helps if you throw a party!

 

The following chapters will explain these Code Commandments in detail.

 

Outline the main purpose; the functionality you need vs want

What does your software really need?

  • Needs and wants can sometimes be difficult to differentiate.
  • Your needs should be centered around the[* main purpose*] of your software.

 

Do you need a prototype or are you building this for actual users?

  • Prototypes are only useful for proving you can do something or demonstrating a use case that could not be experienced without it.

 

Is the first version to raise investment or to sell?

  • Even if you’re aiming for investment, it’s always a good idea to[* build your software to be ready to sell.*]

 

What features are needed to accomplish this goal?  What else do you want to add?

  • Make a list of the rest of the items you want to add to a priority list.

 

Next, it’s time to[* wireframe*] and let your first set of users help determine the necessary next steps before you go to market.

 

 

[]

 

[* *]

Wireframe everything! Every page, button, pop-up you can think of.

What is a wireframe?

  • A wireframe is essentially just a drawing of each screen. It shows the placement of elements in a user interface and demonstrates the intended functionality of the software.
  • The main focus is not on graphic design but on layout and functionality. Some projects that require investors may spend some time cleaning up the wireframe with graphic designers.

 

How should the wireframe be used? What should be added to the wireframe?

  • In order to get[* accurate estimates ]and[ results ]from your developers[, every page, button, pop-up ]you can think of should be[ wireframed.*]
  • Every function and button should be thought out and documented for others to review.

 

Why is it so important?

  • It enables[* accurate technical planning*] of the timeline and hardware requirements for the project. A developer can only estimate what you ask them to build, most of the time they will not add work to their tasks.
  • You’ll be able to identify[* missing elements *]and act accordingly; it’s better to know late than never.

 

How will it enable the developers to provide an accurate estimate?

  • Because they can see the amount of visuals to be coded and the functionality associated with them.
  • You will be able to [*plan your project by visual milestones *]to accomplish what needs to be done.

 

How can the wireframe impact the architecture design?

  • Depending on the technical scale, the wireframe and expected user growth will determine the hardware resource requirements to run the software.
  • Smaller projects like facial recognition may still require a lot of processor speed to run effectively when they scale.
  • It’s a good idea to include notes for security requirements and business logic that cannot be shown within the wireframe.

 

Check out these cool wireframing tools or use a napkin if you decide:

  • Balsamiq Mockups
  • Mockingbird
  • Lovely Charts

 

Now that you have the[* idea, ]the *necessary functionalities and the wireframe for your project, it is time to start planning your software architecture.

 

 

 

 

 

Architecture design. Plan to scale.

What is a software architecture design?

  • If you don’t want your software or hardware to go down (stop working), you need a plan for your database sizes,[* processor load,] and the *hardware requirements to support them.
  • It should include information about expected user growth, performance expectations, and security requirements.

 

Expected User Growth

  • How many users do you expect during beta? How many once you launch?
  • Having this plan ready will help determine what the architecture needs to be. If you don’t need your software for a large user base, you might be able to cut down your project size, hardware requirements and costs.

 

Performance Expectations

  • Depending on your project budget, stage and expected user growth, you may be able to get away with running the project on a simple PC.
  • On the other hand, if you’re looking to scale and want to grow quickly, you should have a server in a data center or with a hosting company.

 

Security Requirements

  • Does your data need to reside in a certain country?
  • Do you want the database encrypted?
  • How many levels of authentication do you want/need?

 

With a solid plan for your architecture design, you can now move on to optimizing the wireframe for usability.

 

 

 

Tweak the wireframe and optimize for usability.

Get Feedback

  • Have a team meeting to review the contents within your wireframe.
  • You can use a thought experiment. Walk through how people would use the software. Then you’ll be able to identify missing or redundant features in the wireframe.
  • Ensure everyone you show your wireframe to has signed a Non-Disclosure Agreement to protect your idea.

 

Optimize User Experience

  • Try to build your user interface so that your users won’t have to read the instructions… we all know how popular reading instruction manuals can be.
  • Keep it simple and intuitive. The more people have to learn, the more it will feel like work and push users away.
  • Guide your users’ eyes to make the [*experience natural *]by following the F pattern from the top left-hand corner of the screen. (For North America).

 

Planning for different Screen Sizes

  • Prepare the interface for different types of desktop and mobile devices depending on the purpose and your user base.
  • Even if the initial release is only for a single screen type, your software should have a layout that can be easily modified for different screen sizes.

 

Making it Pretty

  • Wireframes help plan the software but aren’t usually the prettiest to present. If you plan on pitching to anyone to join your team or invest, you might want to have a graphic designer to jazz things up.
  • A good designer will consider both usability and style in the design.
  • Make sure the graphic designer plans a strong colour scheme for both the desktop and mobile version of your software.
  • Depending on the creativity and skills of your designer, you may want to keep your mind open and let them be in charge of the visuals.

 

Now that your wireframe has been tweaked and optimized, it’s time to milestone the priorities and prepare to develop your software!

 

 

 

 

 

Milestone the priorities. MVP first and then the UX.

What is “Milestone the priorities?”

  • It’s a [*way to divide up *]your software project into manageable chunks so it’s easier for your coders and yourself to understand. These milestones will help track the progress of your project.

 

Where to start?

  • Start with the MVP (Minimum Viable Product). The minimum set of features needed to demonstrate that your product can actually provide value to a set of users.
  • Then move on to making the user experience better and adding what they need to enhance your MVP.

 

Why are they so important?

  • Project milestones act as goals for the developers and identify problems that are slowing the project down.
  • Adding milestones will act as a guide to ensure that you are on the right track to finish your project by the deadline. Breaking up your gigantic project into smaller simple sections will signal that the project can be completed and fully functional.
  • If you have a client, you can keep them updated and informed about the software development progress.

 

How can you create effective milestones?

  • You can divide up your milestones into the Model-View-Controller categories so you can have multiple coders build the software at the same time.
  1. Start with a model. This is your business logic, including the interactions of all the data.
  2. Then add views. Views display what the user will see.
  3. Then add controls. These are buttons/actions done by the user to interact with the software.

 

 

 

 

[]

Figure 1 Image provided by RegisFrey

http://regisfrey.com/

 

The time allotted to each user interface should be 4-8 hour pieces.

  • You can also set a schedule to the milestones to ensure the project keeps ahead of the deadline.

 

Now that your software milestones are in place, your team is ready to start developing. Make sure you sit down, fasten your seat belt and hold on for a fun ride.

 

Start developing basic needs. Any uncertainties should come first.

First things first:

  • Address the basic needs so that you can demonstrate the product and confirm if it’s possible.
  • This is like a foundation to a house. You only build everything when you know that the basic necessities work.

 

Can we start on other pieces at the same time?

  • Yes, you can start building other pieces but the code might be thrown away if the basic needs are not able to function.
  • It’s more efficient to complete the needs first. Then, you’ll be sure that the additions are worth finishing.

 

Now that you’ve started developing, make sure you [*communicate with your developers regularly. *] 

 

 

 

Get weekly/daily updates.

Your baby needs attention:

  • With consistent updates and communication, you can stay informed about the project’s progress.
  • By having a way to communicate with your team, you can help guide them and make sure they are customizing the coding of your software to the best of their abilities, and to the best of your expectations.
  • There are lots of small decisions to make along the way. Effective communication can help you and the team implement them in time and prevent any complications down the line.

 

Here are some simple ways for you and your team to stay in touch:

  • Process: Write out and explain the tasks that the team needs to complete and the order to complete them in.
  • Repository: Using a shared repository can keep your team on the same page and delegate tasks easily.
  • Goal Setting: By having clear goals, you and your team can effectively hit different objectives while keeping track of the progress.

 

Consistent communication is crucial but it won’t be enough, it’s also time for you to get involved testing your software as features are being built.

 

 

[]

 

 

 

[* *]

 

Alpha Testing: Involve yourself in weekly testing.

What is alpha testing?

  • It is when developers test the project to find bugs and make sure the project works.
  • This process lets you and your team discover as many fundamental problems as possible and make sure the software functions before beta testing.

 

Why is it important for you to get involved?

  • Things don’t always go as planned and bugs will creep up during the testing. You need to[* identify and fix these problems*] with your team.
  • When patching up these problems, your inputs are important in order for your project to stay true to your vision by the end of the process.

 

What can happen if the tests go wrong?

  • In an alpha test, something will go wrong! It is your team’s responsibility to fix and adjust the product.
  • You can further improve the final result by being involved and providing the team with directions to save them time.

 

After completing the alpha testing it`s time to move on to fix the bugs and then start UX testing.

 

 

[]

 

[* *]

 

UX testing: Plan to optimize the UX and incorporate feedback.

What is UX testing?

  • UX is short for “User eXperience”, and UX testing is when your team tests the experience of using your software.
  • “Is it intuitive? Easy to use? Are there bugs?” UX testing addresses these questions so that you and your team can identify inadequacies and start fixing them.

 

Will my software have bugs if we planned it all out?

  • Yes, there will be bugs and your software can always be improved upon. With testing, you can fix the problems in order to perfect your software.

 

Is my software easy to understand? Can a 5-year-old use it? Or more like… can my grandma use it?

  • It is important to put yourself into the shoes of new users and make the UI.
  • You need the learning curve to be smooth so that even a technologically challenged person can just pick up the final product and use it right away.

 

Make sure you focus UX on your target market

  • Keep the target market in mind and[* tailor your software UX*] to the needs of your customers.

 

Finally, plan time for bug fixes… even just tweaking the User eXperience to be exactly how you want it can take time.

 

After you’ve fixed your bugs and finished your UX testing, you will want to start with Beta Testing.

 

 

[]

 

[* *]

 

Beta Testing: Thorough testing from actual users not involved so far.

What is Beta testing?

  • This is testing done by people external to the project to ensure it works in real use cases.
  • The purpose of this testing is to confirm your software performs as expected for users that were not involved in the design and development. Often this test will return some feedback about functional bugs but it will also return feedback about the User eXperience (UX) and if the users were able to intuitively understand how to use your software.

 

Close or Open Beta? Which one should you perform?

  • Close Beta means you control the users who are involved.
  • Open Beta means you let anyone sign up to be part of your beta testing.
  • This largely depends on your end goals and target market for the software. Most enterprises want to keep their ideas private until they are ready to market them.

 

Beta testing can engage your users and improve your software

  • Document the user feedback and use it to prioritize how you will refine your software and create the best experience for your users.
  • Giving users feedback will also build a good reputation and boost the success of your software.

 

After you’re done Beta testing, you’ll want to incorporate the crucial feedback into the software before launching it. Multiple rounds of Beta testing are generally needed to confirm the adjusted/added features are to the users expectations. You really shouldn’t be done Beta testing until the users are happy using your software.

 

 

 

[* *]

 

Incorporate Feedback: Make final adjustments to UX.

Which Beta feedback do you need to incorporate now?

  • It depends on which features are necessary for user adoption. If the features you want to add will increase virality, marketability, and revenue, and if they avoid over complicating your app, it’s a good idea to add these in.
  • It’s also a good idea to get a time estimate from a developer for the rest of the features so that you can prioritize the smaller ones that add the most value to your software.

 

Plan out multiple versions to keep users actively interested in new features.

  • Instead of adding everything before you launch, introducing new features through different versions of your software will keep the users excited and demonstrate you are listening to them.
  • This will also make it easy to prioritize your features as the number of requests for them comes in.

 

Ensure the UX issues are addressed. Keep your software simple to get it going.

  • At this point, be careful not to over-complicate your user experience. Some user features can sound super cool but take you away from the main vision. Launching something that is hard to explain will only make user adoption harder.

 

After the UX feedback is incorporated in your software, it’s now ready to launch! It might seem easy but making a splash is one of the greatest challenges for new softwares.

 

 

 

Launch Software. It generally helps if you throw a party!

“Caannnoonn Baaaaallll!!!!” – It’s time to make a splash!

  • Product launches are an exciting time! If you plan correctly, you can create enough noise to make sales right away. The trick is choosing the correct way to launch, the budget to spend and deciding how to get the attention you want.

 

What’s your viral coefficient?

  • A Viral Coefficient is the measure of how viral your software is, which is measured by how many new customers or users your current ones are bringing in.
  • So, how do you increase your viral coefficient? It’s like word of mouth marketing. Build up your reputation for quality and service by responding to your customers’ feedback.

 

It’s time to party… and work.

  • Make sure you celebrate all the hard work you and your team has put in, you deserve it.
  • Remember, your launch will likely give you, even more, feedback about your product so ensure you are ready to do more work.

 

After launch, your baby is now alive. Remember you will need to continue to feed it with new features or hardware to support the growth.

 

 


LiveApp - 12 Code Commandments

What the book includes? The 12 Code Commandments are the steps to follow when building a new software. Not only does the book list the commandments, it also explains them and their importance. Why are we releasing it as an e-book? We are releasing these commandments to help educate non-software professionals on the software development process and to help launch successful software.

  • Author: Anil Mehta
  • Published: 2016-07-09 00:05:14
  • Words: 3033
LiveApp - 12 Code Commandments LiveApp - 12 Code Commandments