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.

Lectures

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