Front-End Design
Start course

This course takes you through a case study of a real-world scenario in a financial setting. We'll go through how data gets processed, stored, and presented for an insurance dashboard. This dashboard displays all different types of insurance and is powered by an underlying database. So over this course, you'll both see some specifics for the industry vertical of insurance and some specifics on how to process data.

This course is a little less technical than some of our other database-related content, so if you don't have Python or SQL skills, that's fine. This course is really ideal for those who want to learn a little bit more about how all of the pieces go together to understand more of where to dive in deeper.

If you have any feedback relating to this course, please let us know at

Learning Objectives

  • Learn how to put together a data processing solution for an insurance company
  • Plan the project
  • Build the front-end interface, the back-end database, and the middleware that connects the two
  • Put the whole dashboard solution together

Intended Audience

  • Data engineers and database administrators
  • Anyone who wants to gain insights into how a data-handling solution is built in a real-world environment.


To get the most out of this course, you should have some basic experience with databases and building IT solutions.


So now that we've chosen our database technology and designed our database schema and we've populated it with data through our pipeline, we're going to switch gears and start talking about the front end and how we're going to design the UI. First, we need to do technology selection just like we did with the database. It's often a good choice to use a Web interface. And what's nice about designing your UI as a Web interface is that your users aren't required to download anything or install any special software. They can just point their Web browser to a URL, whether that's internal or external, and they don't need to do anything beyond that. It also allows for continuous integration, continuous delivery, or CI/CD, which means that you can make changes and push them out silently. Users don't need to go and download a new version and install something every time you've made an improvement to the product. It's just there for them the next time they log in. There's also many good open-source visualization libraries available for Web frameworks such as JavaScript libraries like React and d3. 

The next stage of the front-end design is dashboard design. A good design should consider the user experience at all stages. So basically, you should always be thinking about, if I were the user, what would I want this to do? How would I want it to work? You shouldn't be thinking like a technologist or an engineer. You should be thinking like a business user. But don't take it too personally if users disagree with you about how something should work. Because sometimes they have a different perspective from the business side of things. And sometimes there's just a difference in personal preference. So ultimately, the users make these decisions. So don't stress too much about that. 

As you're designing the UI, you will almost certainly find that this process will be iterative because you're going to design something, you're gonna give it to the users, they're gonna play with it and they're gonna come back with suggestions. And then you're gonna make changes based on that feedback that's totally normal and natural, and it should be a collaborative process. When you're thinking about designing the UI, remember that the end user is the one who has to live with this every day. So you want to make sure that what you're building is exactly what they want or if not exactly what they want, as close as you can get so that the user is happy, because if you build a product for them that they don't like, they're not gonna use it. And then you've done all that work for nothing. 

So now let's go back to our Acme claims dashboard example. At this stage, you're going to call a meeting with your Web designers and your UI/UX designers, and you're going to talk to them about what your team is building. You're going to explain the use case to them, and you're going to tell them what the claims department wants. Maybe we'll share development documentation with them. The roadmap that we've built out that we agreed upon with the claims department, and we can actually share with them some mock-ups that the claims department has provided. So very helpfully in our planning session, the claims department gave us some hand-drawn mock-ups of what they envisioned the dashboard to look like. And this is really useful because these mock-ups are almost going to be directly translated into our wireframes because we want our dashboard that we build to look as close as possible to what the user wants.


Introduction - Case Study Scenario - Planning - Building the Database - Middleware Design - Claims Dashboard: Putting it Together

About the Author
Learning Paths

Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity.  With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing  decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.