Mock-up preparations
Gather all the information that might optionally go into the mock-up. To this end, carry out a survey including the wishes of future users. Send the materials to the team realising the mock-up. Find a few applications that you know or use, and figure out which solutions are helpful, and which ones are not.
This stage does not end. Anytime you can add another requirements as long as the mock-up has not been closed yet.
Detailed description of a scope of work
Write down what you need to do. For example, it might be creating 15 modules of specified names. They may be:
-
customer - private individuals or companies which have bought the products or are considering buying them;
-
supplier - a company that sells products for reselling them;
-
user - a team member with the access to a web application;
-
offers - a document in PDF format sent to the customer with a purchase offer
What needs to be done in each module?
-
Filtering
-
Main table
-
Profiles
-
Intermodular link-ups
-
PDF documents creation
-
Sending text messages and autoresponders, etc.
The process of creating an offer, pricing, and acceptance of financial condition might be complicated. In such cases it is useful to enrich the mock-up with a modelled process of creating an offer including all scenarios. It is also advisable to write out all the processes that are necessary to do so.
Mock-up of CRM or ERP software
A producer of dedicated web applications should provide you with one (in fact, a few) access to particular panels so that you could see in practice what your application will look like. Any programming company should not hide behind the contracts with clients, NDA, or nothing else. Creating an application with two or three simple modules is a matter of one working day for a software developer, so they should already have a prepared application for presentation.
Mock-up layout
Discuss main panel elements, such as:
-
a navigation menu
-
filters
-
tables
-
profiles
-
settings
-
exports
-
statistics
-
home
If there are a lot of panels for many different types of users, they can have different layouts set up due to intuitiveness. If this is the case, discuss what those users should see in their panels. All the panels need to be included in a mock-up.
The mock-up layout should be comparable to the application. Ask the software producer for a mock-up of a sample module, and the access to the application/module that was made on the basis of that documentation. This will allow you to have a better picture of what will develop from the mock-up.
CRM or ERP panel appearance
In the first place, determine the look of CRM or ERP module application. Below you will find an optimal panel developed by us. On the left there is a narrow bar with modules’ icons. Once you point the cursor on it, it will drop down.
On the top there is a name of a module in which we currently are. Then on the top there are filters that you can unroll and roll by just one click.
MENU button allows to preview the profile records on the right and left side. You can switch easily between the records. Filtering option is available all the time. The table on the left can be also hidden and shown.
The record profile is divided into a profile and then into thematic tabs which amount of you can determine yourselves. There could be fields or tables with filters in the tabs.
The edit mode is in a different colour than the read mode for easier distinguishing. Buttons: add, save, edit are on the top right.
Send us an email and we will send you back the access data to a sample application.
Tables in a mock-up
Make a plan of what the table should look like in your dedicate web system. Determine the details of below points:
-
table ribbing
-
how many records should be displayed in the table
-
pagination (paging)
-
sorting
-
filtering
-
date formats
-
export to the external files - formats, coding
-
queries
-
icons in tables
While creating the mock-up discuss how fast the table will be loaded. There are plenty of technical solutions for it, and each of them has its pros and cons. Make sure that the table will operate quickly and efficiently with the big amount of records.
Profiles in a mock-up
A profile is a database of information which could be saves in a particular record in a module. For example, in the module the clients will be given the following fields: name, surname, client’s status, email address, phone number, etc.
Fields where only one piece of information could be put - for example name, surname - should be distinguished very clearly from the fields where users could put more records in. They might include: addresses, bank accounts, branch offices, employees, suppliers, etc. In those cases you need to create a table in a mock-up, which you could insert any number of records in.
Kinds of fields in a web application
-
Text field - use with a name, surname…
-
Long text fields – for notes, additional remarks
-
Select boxes - for statuses, sources of customer’s acquisition
-
Multiple-choice select boxes - for lists of regions where a recruitment company’s candidate wants to be employed
-
Checkboxes - whether a carer is able to drive
-
Radio Box – for sex, types of intermediary commissions
-
Link to follow - a link to the customer’s website
-
Date - next contact with the customer
-
Date and time - appointment date in a calendar, a planned arrival of a bus with a carer to the customer
-
Progress bar - import of the files or the recruitment/production process advancement
-
File (one or more) - references, CV, contracts
-
Avatar - a field for a photo with a miniature in the application
Filtering on a mock-up
Define an order of all the filters in each module. Make sure that the filter is named exactly the same as the field in software. Using the example explain what values will be displayed in each field. For instance, in a field NAME we will put JAN. The filter may operate based on following conditions:
-
starts with - it will show all the people named JAN, JANUSZ, JANINA;
-
contains - it will display the above as well as OSJANA, BRAJAN;
-
equals - it will show only people named JAN;
-
does not contain - it will not display any of the above.
Filtering dates should be done with defined options: today, yesterday, tomorrow, this month, last month, last 30 days, and any date range.
Processes in the application
A CRM or ERP web application will be used to maintain complicated processes. In such cases it is necessary to draw the possible scenarios within each process. To accomplish that, a BPMN notation will be useful. You might as well use a different one.
Integration of a dedicated web application with other systems
Web applications might be integrated with external systems. What is more, it is worthy to do it. The process is predictable and easy to conduct. The achieved results may bring great benefits. On a mock-up stage every integration should be written up separately.
Describe when and what information should be sent to another system, and what actions they should cause. Computer programmers are needed to be involved in that process in order to define the way how the integration will be implemented. Your dedicated CRM or ERP software may send and/or receive data from the external systems.
Dependents in the web application
It is the most difficult element to develop in a mock-up. All dependents should be described in details. Write up one dependent in a place to make changes in that one place while editing.
Dependents are not a problem for an experienced team of programmers. The greatest difficulty lies in:
-
choosing an appropriate level of dependents which future users will be able to implement;
-
analysing the current situation, process optimisation;
-
creating yourself a picture of how it may work in an application;
-
understanding of a mock-up and a deliberate acceptance by the team.
Privileges in the application
Define who will be able to log in to the application. In a module Users you will find all your team members. These people will be assigned to roles. For example:
-
admin
-
sales
-
service
-
recruitment
-
administration, etc.
People with their roles specified must have defined privileges:
-
read access
-
adding option
-
editing option
-
deleting option
-
data export option
A web application might consist of a lot of panels. Above we describe the admin panel. Others may be given their panels as well. For example:
-
in a recruitment company a candidate gets their panel
-
in a language school both a student and a teacher have theirs
-
in a production company a customer and a logistic company might have their own panels.
In the same way you need to settle what kind of accesses people are given in all the panels.
Final result of mock-up work
The final effect is a PDF document containing the needs clearly indicated by customers. While creating a mock-up nothing is obvious and that is why everything should be described in details. Team creating the application will not be in touch with the team that has created a mock-up, so everything which is required by the customer should be included in the mock-up. Of course, if programmers find any inconsistencies, they will reach the customer’s team with a question. However, as long as there is no information on including sort option, programmers will not execute this functionality.
The customer needs to be aware that programmer will do exactly what they see in a mock-up. Nothing more. In case of a fixed-price contract, any changes to the mock-up will be extra paid and done at a later date. In case of a time and material contract any modifications will be executed in the next rounds/sprints. Thus, it is really important to make sure about the mock-up completeness.
Start of programming work
After the mock-up is approved, design work on it in a specified area is going to be stopped. Team designing a mock-up is able to start developing next elements of a web application. In a meantime, programmers create software and test if it meets mock-up’s requirements.