Your First Prototype – Or, the making of an app Part II

Building an application is like a marathon; building each feature is like a sprint. 

The goal of each sprint to pick one or more features (user stories) to work on. Ideally, the feature should be able to be an application on its own. For example, a user story for a budgeting app could be:

As a new user, I want to setup my budgeting profile 

If we develop only this feature, a user should be able to open this application and setup their profile (e.g starting cash, income, expenses etc.). At this point the application will do nothing else, but it will take a new user’s information down, make sure it’s valid input, and have that data ready for whatever feature you build next.

When you finish each sprint, it’s like having another Lego piece, until you complete enough sprints to build your MVP (minimum viable product).

Each Sprint comes in three stages: 1 — The Sprint planning 2 — The Sprint 3 — The Spring Retrospective. 


Sprint Planning

Before the sprint can start, double check that each user story you’ve chosen to work on fits the INVEST method from Part I

As discussed in Part I, the user flow diagram is a rough sketch that helps us create our user stories. During the sprint, we will turn the user flow we made into an actual wireframe, then polish it up to make it a prototype. But before we begin that process, we need to refine our estimate and create acceptance criteria.



Estimating

When you were creating your user stories, you loosely estimated how long you can build a prototype for each story. This is the time to refine that estimate. The first few sprints will be hard, if not impossible, to estimate accurately until you get adjusted to the work involved. However, your estimates become more precise after each sprint, until you get to a point where you can accurately estimate how long the rest of the application will take. 

Acceptance Criteria

A feature is done when all the stories you chose to work on are done. To know when a feature can be considered as done, acceptance criteria need to be created before the feature is built. 

Creating these criteria first is an important part of testing to avoid bugs. It also has the added benefit of guiding you or the developer you hire to stay on track to achieve the goal of that feature. 

Here is the acceptance criteria for the first screen in our user flow diagram. 



There are two ways to test the acceptance criteria: manually and automatically.

Manual is when you test the finished prototype after its built to make sure it works. Automatically is when you write code to do the checking before its even built. Regardless if you go with one or both methods, you need to create test inputs.

Test Inputs

To verify the above acceptance criteria pass, we need test inputs. With the user flow sketch above, we come up with anything the user could enter or press:


Test inputs are crucial as together, they should represent all the possible states your app can enter. The more comprehensive your test inputs, the less bugs you will face and the more likely the right thing will be built the first time around. For our feature , below are the test cases for the first page (adding your current bank balance) with a spot left for the actual result when we test at the end of the sprint.

Keep edge cases in mind when choosing test inputs. If all your tests pass, you can be pretty confident you will be getting valid data when you go to build other features like the database. Having this confidence is important because you might not come back to the code written in the first sprint until the 10th sprint or later. You should also be able re-run the tests at that time to make sure everything is still working as expected.


The Sprint  To get our first prototype, we create the skeleton of the app, then add the functionality and UI afterwards. 

It’s important to separate how things look from how they work. The skeleton allows you to focus on the layout, structure separately from the functionality and UI. There’s no hard rules on what makes up your skeleton; mine consist of a wireframe and assets. Together, these make up our prototype.

Wireframe

The wireframe is the backbone of your prototype. There are two main ways to create one: 

• Using Code • Using Design Software

You can code your wireframe right onto your shell, and add the functionality right away (e.g. navigation, error checking, etc). This has the added benefit of forcing you to separate your UI from your code. Since you know you will be changing your UI, you will have to create your functions, inputs and outputs to be independent. 

If you are not a developer, then you can design your wireframes using many design software. Most design software have a prototype mode that lets you use use your prototype as an app on a phone (or browser) without any coding (e.g. Invision, Marvel etc.) and come with templates and UI kits to help you get started.




This is also a good chance to get user feedback on both functionality and usability. It’s always best to test with your users as early and as often as possible. If the goal is a high quality app, then it helps to have a good understanding of the activities that make up user testing.

Separating Assets, functionality and UI is a prerequisite for quality. Otherwise, you may be providing a safe space for bugs, and it’s gonna be a nightmare trying to add, remove or change anything later.




Assets

Assets are considered anything that gets loaded by your application for display. This includes (but not limited to):

  • Images

  • Fonts

  • Text

  • Icons


Images

Your images will come in various sizes and shapes, and will need to fit various screen sizes. You may have several versions of the same image for different sizes, so keeping them in a separate folder from the start helps you stay organized.

Text

All the text you use in your application should be separated from your code from the start. If you have your text coded right into your application, translating your app will be very difficult and expensive. On the other hand, separating your text allows you to translate your app into many languages extremely easily. 

If you are not writing your own code this is especially important to avoid back and forth during development, and costly minor text changes down the line.




Icons/Fonts

There are several paid and free websites that specialize in providing high quality icons — Font Awesome is probably the industry leader for Icons. Of course, you can design your own icons too. As for fonts, the ones you decide to use can have a big impact on usability, so fonts and general typography tips are topics worth researching. 


The UI UI design is a discipline in and of itself. It does not have to be done in the same sprint as the feature. In fact it may be better to have a few features in your prototype before you begin to improve your UI. This is because during the first few weeks there will be a lot of change as you refine your requirements and layout.

The first step to designing a good UI is getting inspired. For inspiration, I check out:

  • Sites like dribbble, behance, pinterest etc.

  • Apps I enjoy Using

  • Apps I will compete with

  • Apps I don’t like

  • Highly rated apps 

  • Low rated apps

Taking screenshots, add all your inspiration in one file called a moodboard




Once you’ve got an idea of what you think looks good, refine your wireframe. For example, with the inspiration from my moodboard, I refined my wireframe even further and came up with the final prototype for this feature below.






The layout of this prototype is standard, and the UI is basic, but you have a good idea of what the final product will eventually look like. 

For your application, this may be good enough; if you’re a pro, you can come up with a better design. In any other case, a UI designer is needed to go from prototype to finished product. We asked a designer on Upwork to provide a dark and light version of our prototype.




The cost of developing this ended up being about 4–6 hours. However, this could have easily taken 3 to 4 times that length if we had not:

  • created the requirements, 

  • drew the user flow diagram, 

  • created the wireframe, and 

  • produced a refined prototype for the designer.

Some back and forth is unavoidable; in this case, we asked the designer to:

  • add an info button,

  • make the dark color lighter, and 

  • make the screens match in color and theme

This is the final UI we settled with.





Sprint Retrospective

You’ve ran your tests, and have gotten them to all pass. You have a good idea how the feature will look when completed (if it’s not already). And you have your prototype (or maybe even the finished feature). You can now move the feature to the “Done” pile. To complete your sprint, look back on the sprint and ask yourself the following questions:





After two sprint retrospectives you might notice a lot of issues with the framework, library or designs you are using. Recognizing these issues and switching up your tools and/or processes early ultimately improves the quality of your application, and saves you time and money. You will also get better better at problem solving and finding creative solutions, especially if you’re working as part of a team. Or you might just realize you work better at nights. 

Regardless, take your findings and make actionable comments you can use in the following week.


Conclusion

You’ve just seen how to turn a user story into a working prototype then into the final design. As we’ve noted, the application doesn’t do anything meaningful yet, but it’s an important Lego piece in our final structure. Eventually, it will be presented to new users, and then connected to the database as well.

To recap the steps, the skeleton makes up your prototype, and adding functionality and UI refines the prototype until you have a completed feature. Do this over and over again until you have a completed application.





If you’re not a developer, leave the functionality column out in the first few sprints. Once you have a prototype with more features and a final UI, you can bring in a developer to start building the functionality using the skeleton and UI you provide. The final part of this guide is will be how to hire and work with contracted developers and designers, and best practices on keeping cost down and quality up. 

Next up, however, will be about taking advantage of APIs and Cloud services (trust me, they’re simpler than they sound) to reduce the work you need to do — without sacrificing quality. 


Further Reading Agile  Agile in a nutshell

Sprint Planning Sprint Planning

Wireframing Guide To Wireframing — Ebook

Testing 7 Tips for writing Acceptance Criteria Test Driven Development

UI design steps iOS — Human Interface Guidelines Android — Material Design Guidelines

User testing User Testing Field Guide — Ebook