In this episode we are taking a step back from our UX and UI discussions to focus a bit more on the data that will drive our application. Now that we understand the typical end user better and have translated this knowledge into something more concrete from a development standpoint, one of the next steps is to tie these views and navigation paths to some concrete data that will serve as the backend of our application. After all, a great CRM needs to efficiently handle large volumes of data to maintain customer information as well as alert us of potential deals that are ready to close!
From UX to Business Needs
We spent the previous two posts talking about how we can understand our end user. From a design perspective this is a pivotal step in the development process as a better understanding should translate into a design that is tailored to what our end users need, not what we as developers want to do to ship code quicker. ;) This will result in less clicks to navigate around, easy access to the data we need the most, and a UI that is designed to foster productivity rather than having hundreds of options in our face at all times. That said, I’m using Word to draft this document, which is a case in which you do need all those options available for different use cases and scenarios, but our CRM demo is much more specific in terms of functionality, requirements, and scope. In other words, all these options being present all the time for something as broad as a word processing program makes sense, but for something opportunity-driven like a CRM we don’t want to muddy the water with extra options we don’t necessarily need.
This gets us to our business requirements, otherwise known as the data that we want and need to capture to keep track of companies, contacts, and opportunities. While our UX’ers have been figuring out our end user, our data architect (aka a senior developer) has been working on our data model. This is another one of those steps in which UX and UI can work separately from development, for a while at least, as the eventual UI will be aware of what data needs to be displayed and handle binding to that data while our development team ensures the data is being populated and utilized correctly by the application. Here’s a small look at what this involves from a model perspective:
Data Access Choice – OpenAccess ORM
As you may have noticed, the previous screenshot was an OpenAccess ORM Domain Model, so you can already tell what we are using for interacting with our database. Other than brand loyalty, there are a few reasons why we are using OA for our data layer:
While you can take a closer look at the data involved, like so:
… we’re not going to take your time going through every entity and what properties they do/don’t have. You’ll get to see this organically as we move through the actual development as well as in the code we ship at the end of this process.
The Next Episode
We are finally getting ready to dig into some code and see how our experience with UX, UI, and creating a data layer with OpenAccess are going to come together in the next few posts in this series. At this point we know a good deal about what we’re going for so we can dive into Visual Studio and Blend to start putting the pieces of this application together. Thankfully we’re not working with a real client, who might change some requirements at the 11th hour, but you never know what fun you are going to run into when working on an application of this scale and we’ll be sure to bring it all to you as the LOB Chronicles continue next week!
Evan Hutnick works as a Developer Evangelist for Telerik specializing in Silverlight and WPF in addition to being a Microsoft MVP for Silverlight. After years as a development enthusiast in .Net technologies, he has been able to excel in XAML development helping to provide samples and expertise in these cutting edge technologies. You can find him on Twitter @EvanHutnick.
Subscribe to be the first to get our expert-written articles and tutorials for developers!