UX Lab: Changing the way you handle CRUD workflow

I often see a lot of consistent patterns in the way applications are being built when it comes to generic create, read, update and delete (CRUD) workflows .

The usual pattern is that a screen starts off with a add/remove action followed by a very large datagrid and probably some paging. A user would then refine the datagrid’s result set, make a selection either inline on the datagrid or opens a modal via an action like double click which then presents the end user with a more detailed view of that record. This is probably so generic in the way it’s being approached that I’d probably dare say nobody’s really sat down and thought about its actual practicality – as it seems to be the unofficial standard for screen design (well the bloody apps I see day in day out anyway).

This pattern for me isn’t something I’m a fan of, maybe because it’s so common now that I simply crave for an alternative approach? I crave this alternative because I feel at times the workflow in itself seems oddly backwards?

The part that catches me out, is the overall approach taken. For instance, the end user has come to the said screen to get a detailed view of a record – maybe a summary, but doubtful. They wade around in the various amounts of turn-keys (filter settings) until they settle on a pattern of data that they can then scan (hunt/browse) for and proceed to get the modal open for a detailed view. It appears that majority of the practical usage is saved towards the end of the process pipeline? in that getting a detailed snapshot of the record seems to be an extension to the UI instead of probably being the focal point of the UI?

Armed with this style of thinking, today, I set out to try an alternative approach to the way this workflow could work. I decided to simply inverse the workflow, in that take a typical Security (add/remove users etc) workflow and try a different approach (see below).


The idea is that when you click on “Find Users” the screen opens up to your summary view, in that since I’m logged in it reflects back my entire account profile found within the system. There are then a number of actions one can take in and around deciding on what to do next but the main key piece here for me, is well I've shown you the end point up front – I've seeded a contract with the end user around what screens will look like once they’ve found a user of their choosing.

How do I change the user from me to someone else?


The change button in this screen kicks off what is traditionally the first screen, in that if the end user clicks on [Change..] a modal will open over the top, presenting the end user with search criteria. The user then fires up some search results and can specify filters for their search. Once the end user has found the right user of their choosing, the modal closes and the original security profile (you) switches to the person in question.


Ok, I’m kind of with you, but what benefits does this give then?

I personally think it shifts the user into a more focused approach to how they handle the workflow. It’s quite easy to snap in a datagrid + tree control and hit F5/Ship. This approach in my opinion approaches the workflow differently, in that it asks the user to be specific in what they are really after. If you’re in the User Administration area of this application, then what is it you want to do? Manage users is probably the typical response here. So, let’s let them manage a User in a more focused fashion by exposing other areas of interest in a screen that’s more content specific and less cramped / buried in a floating modal.

The typical “list all users” with paging approach is quite unnecessary real estate to reserve for prime time, as well it’s merely a stepping stone to the end point. It’s almost throw away in the task process should the user want to change “John Doe” password or check when that user last logged in etc.

You could even approach the way I’ve done it differently, by simply providing a search box at the top with a label “Find User..”. Once the user types in “Scott Bar..” (auto complete) like experience fires, but instead of a pulldown it could then go off and grab all twitter feeds, flickr photos, facebook profiles, linked profiles etc and just start showing them on screen. This kind of approach is more helpful when you’re trying to figure out who that “Scott” fellow was last night, as now you’re meet with multiple forms of media to help guide your search detective skills down to a more informed end point.

The point is, it’s taking the equation of CRUD and flipping it into a more interactive experience. Why invest all this time and energy into some of the new UX platform’s out there only to use generic patterns like the original one mentioned in this post? How can you evolve this pattern further and where can the users gain in terms of data + contextual view beyond what they’ve typically been given.

It’s a new world people, try and break a few things as when you break something you in turn are rewarded with knowledge on where risk/failure can occur. Much more informative approach than “well everyone else is doing so i assume it works” policies :0

To be tested..

Related Posts:

  • pauliom

    @MossyBlog nice post, grid 2 view is just db view of data, ie no ux at all. More task based ui needed

  • jmarbutt

    @MossyBlog Great post on Changing the way you handle CRUD workflow

  • steve

    I have been doing this since 1998 vb5, in fact I did this in cobol in 1992. Amazing how things come around. I agree this is a good approach and I hate how one of the big shrink wrapped accounting packages always puts you into add mode whenever you select the menu option.
    Only hard part is deciding your startup record. eg if you have a payroll and open the employees page. Do you pick the first employee based on alphabetic order, payroll number order, DOB. We went with the payroll number. Then with invoices we actually found that you should always display a find dialog with the option to Add a new one as 50% of the time the user will want to add a new one. Other times when Add is clearly the most common function we expand this with a sperate add invoice menu option, we don’t like to add to many menu options so we avoid doing this all the time.
    PS that UI looks great…

  • Interesting viewpoint… awaiting the test results 🙂

  • Nice post Scott. I like the mileage you are getting out of your Metro design 🙂

    A couple nits to pick:

    First, the command word Change has certain semantics to the user. Would Search or another command be more appropriate? To me, Change implies I am making a change to the record that is displayed, not changing which record is selected.

    Second, as Steve pointed out, the hard part is deciding what the initial view should be. How often will the user be going to this view to change their own record? Are you imposing an extra action by showing them irrelevant data and then asking them to search for the data they really want to edit? IMO, that is why many CRUD forms start with a filter/search pattern. Does the benefit of seeing the edit form right away outweigh the cost of taking another action, or the risk of editing the wrong record?

    Thanks for the post.

  • codputer

    @MossyBlog UX Lab – You ozzies always wanting to do things upside down 🙂 Interesting but don’t users understand navigation before detail?

  • While I applaud and encourage your thinking outside the box, I do disagree with your approach.

    Anyone who frequently uses this workflow would not be editing their own permissions so frequently that it should be the default view. I see you are trying to implement an intuitive default context, but I think it won’t be as useful as, say, a pre-fetch of all the users created within the last 7 days.

    In this workflow, the first thing the user wants to do is locate the entity of interest, and you’ve made that an extra click away. Want to actually select the record after search? That’s another click. Select a record to finally view details? The third click. Why not use a master detail approach instead, with a filter/search toolbar? You can literally take your interface down to 1 click, and even less if you auto-show the details when the search returns only 1 result. A screen that combines all of these elements doesn’t have to be complicated or overwhelming, especially if you have an intimate knowledge of which elements your user cares about most. For instance, if the user doesn’t often filter by column fields, then those filter checkboxes can be hidden in an advanced panel that can be toggled.

    Sometimes the UI patterns are there for a good reason, and this case is no different. However, the patterns only take you so far. One can do so much more to enhance the user’s experience than just the initial ‘snap in a datagrid + tree;’ it just takes more knowledge about what/how the user will use the system.


  • I’ve found that changing the mental model of the user is a real trouble with no apparent benefits.

    IMO is better to have a grid, easily searchable (think: start typing and the list get filtered to the results) along the top 5 records recently used.