Change requests are natural. When your client begins to ask for change requests, they are beginning to understand the application. Until they can picture the end result of the application, they won't know to ask for the change request. The longer they wait to ask for that change request, the more it's going to cost you.

Here is an example to prove this point. When your client says: "I want to allow my user to enter multiple addresses, they might have a home or an office, hmmm maybe two offices.".

Which is easier?

a) (later in the process) Modifying a database schema (you stored the address data in the same table as the user data), changing the SQL select, insert, update, delete statements, adding new ones for the new tables, then changing the Lasso code to reflect these changes in the database, then changing the HTML to support multiple addresses instead of one address

b) (earlier in the process) Changing the HTML to show the change in the front end for single vs multiple addresses

If you can encourage your client to ask for those changes early on, you'll save yourself time, money and headaches. To help your client picture the end result of the application, FLiP recommends that you build a prototype. A prototype in FLiP is the front end of the application. You do not need a database, you do not need if statements or loops. All you need is the front end. In web applications, we build prototypes in pure html.

A FLiP prototype is a clickable html application. It should mirror your wireframe. At least at the beginning. You may have left out major areas of the wireframe, because you and/or your client couldn't see what the end result would be. The prototype should help open your eyes and your client's eyes to make a decision whether the application ultimately solves the persona's goals.

If the final application will display data on a page, just hardcode the data into the HTML. We're not worried about the database design or anything else that is purely technical. At this point, we want to continue to build and modify our prototype until our client says "That's it! THAT is what i want!" When they say that (or something similiar), it's time to begin the application architecture.


Coming Soon
To help develop new Lasso Fusebox tools please contact us.

Copyright ©2019 LassoFusebox, All Rights Reserved.

Download from GitHub

Contact Us