CRUD for Designers
https://commons.wikimedia.org/wiki/File:Joos_de_Momper_Icarus.JPG

CRUD for Designers

“I’ve never been certain whether the moral of the Icarus story should only be—as is generally accepted—‘Don’t try to fly too high,’ or whether it might also be thought of as ‘Forget the wax and feathers, and do a better job on the wings.’ ” - Stanley Kubrick

I love this quote from Kubrick because it often applies to the work we do in software. If we do a better job on the fundamentals, it can often mean that we’re able to do bigger and better things and ship software to our users faster, which in turn, offers more value to our users. CRUD is part of the fundamentals for me and in this article I'm going to dive deeper on CRUD and how it can benefit designers.

CRUD stands for Create, Read, Update, Delete.

These four actions are among the most common actions built into software applications. Not all applications are CRUD applications, but many of the product I’ve built for clients at VMware Tanzu Labs have been CRUD and it’s likely something all of us who work in software will encounter.

I’ve had quite a few conversations with designers lately that centered on how to conceptualize design work, where it fits within the overall team, and how to think in a leaner way. I’ve also had a lot of conversations with designers and developers about how to foster better communication.

CRUD is a way for designers to work better with developers, conceptualize the features we design, and think through user actions.

Thinking about CRUD actions while I’m designing has helped me to be leaner and more intentional about what I’m designing. So I hope this article will help you learn what CRUD is, how to think about your work as a designer in a new way, and hopefully that new way is a bit leaner, too. I also hope that this article will help designers talk to developers.?

It’s important that designers and developers come together and finding a common language and vocabulary is always helpful.

I have to start with the disclaimer that I’m not a developer. If you’re a developer, and you happen to read this article, I’d love some feedback on what I did well and what I did not.

I learned a lot about CRUD from my fellow developers at VMware. Quick shoutout to Emily Davis, Jack Huang, Bill Schofield, Noah Denton, and many others developers who helped me better understand a bit about how apps are built. I’ve also learned a lot from watching great product managers organize and think through these CRUD actions as they’re writing stories. I’d love to get some feedback on PMs to hear how you’re thinking about CRUD and how it translates to the stories you write.

So what you’re about to read is a designer’s perspective on a developer’s world.

If you're a designer and something here piqued your interest, talk to the devs on your team. Ask questions. It's the fastest way to learn.

CRUD is an acronym for for Create, Read, Update, Delete.

These four actions are a way to conceptualize what’s going on in an application from two perspectives (probably more, but let’s scope it to two):

  1. What is rendered for the user that they can see in an application and take action on? For example, if I sign up for a new account and enter a username.
  2. What happens to the data in the database? For example, I want to change my username.

I think as designers we are always thinking through what happens to data, but probably not in as detailed a way as developers, so CRUD is a way for us to conceptualize what’s happening to data.

CREATE - Am I adding data to a database??Can the user see that they’re generating something new?

READ - Am I displaying data for the user??Can the user view or read something?

EDIT - Am I editing the data??Can the user change something?

DELETE - Am I removing data from the database??Can the user remove something? -

So let’s now take a look at each of these actions and talk about them in a little more depth using an example.


CREATE

Sometimes this can also be called Post or Insert. "Create" functionality is about adding something new to a database. Here’s a little app I put together called Quote Poster where users can add quotes to a feed.

No alt text provided for this image

Quote Poster is something akin to social media. Let’s make the assumption that the user is already logged in to an account. The user can click the green button there and then add a quote. As shown here there are no quotes displayed to the user.

Adding a quote is a “CREATE” action because the user will add something new to the database.

The green button itself isn’t actually the “CREATE” though. When the user clicked the green button, got this little window here, and typed in a quote.


No alt text provided for this image

When the user clicks “Add to Feed” the information they inputted (the text of the quote) will be saved to the database. If it helps to think of the database as a big spreadsheet then we’d have a column for username and a column for the text that user inputted.

Before the user clicks “Add to Feed” we’d have a blank space where the inputted text could belong. After they click “Add to Feed” that space would be populated with this text. So we’re adding something new to the database.

That’s a “CREATE” action.


READ

Read actions are sometimes called Get or Select. This one’s the most straightforward, I think, for designers. Here we’re talking about things the user can see displayed on their screen. The feed now contains information that was added to the database. Now the information is viewable and readable on the screen.

I’m trying not to define read as read, but you get the picture.

Additionally we might have a version that includes the author’s name or other information about the author in our database and we could display that information as well. Sometimes information that comes from an API is a read action as well. If, for some reason, we wanted to display weather in an application or maybe movie times and we had an API that pulled that information in, that would also be a “Read” action since we didn’t add anything new to the database. We’re just displaying information, albeit from another database (that of the weather/movie app).

No alt text provided for this image


Here you can also see the edit icon and some of you may have noticed that the quote wasn’t attributed.?If the user wanted to go back and add attribution they’d click that edit icon.


EDIT

Editing is an “Update”. Sometimes also called put, replace, or modify. We are taking the existing information in the database and making a change to it. The user forgot to add attribution to the quote, which is a big no-no on Quote Poster (according to me, anyway, since I created this fake application). So the user can click the edit button, open this screen, and add attribution.

No alt text provided for this image

Once the user has made a change they can hit “SAVE”.

Saving would modify?information in the database and that’s why it’s an “Update”, the information has been updated or changed in the database.

Meanwhile, if the user hit cancel then no change to the database took place so that wouldn’t be an update.


DELETE

Delete is probably the most complicated of the CRUD actions for designers.

It sounds easy, but it’s a bit less straightforward than the other actions. Delete technically means that a record in the database is destroyed and unrecoverable. If you’ve ever encountered a “Delete Your Account” option in an application, that might be an example of delete. More often, however, the record in the database still exists but just isn’t viewable or accessible by the user.

No alt text provided for this image

That would be more in line with “Archive” which is technically a modification of the database rather than the record being destroyed. So in this example you see the trash icon and if the user clicked it they could expect to not see the content anymore.

Would that be delete? ….maybe?

From a design perspective delete is delete. It’s gone and it’s not coming back. The user can’t re-access the data. From a development perspective this action is a bit more nuanced. For designers I’d encourage you to consider what actually happens to the data and discuss it with your team.


CONCLUSION

Thinking through CRUD actions has helped me to be a better designer. It's a fundamental piece of how software is often constructed and thinking through what I'm actually asking a designer to commit to building has helped me find constraints. In turn, this helped me to communicate with developers better and ship software faster. I hope you find the same value!

It's also my hope this short article will spark some conversation, especially between designers and developers, and I’d love to hear your thoughts, comments, ideas, praise, concerns, and any and all other feedback you might have about CRUD.


If you loved this article, share it with your friends.

If you didn’t, tell me why so I can do better next time.

Thanks!

要查看或添加评论,请登录

Andrew Zusman的更多文章

社区洞察

其他会员也浏览了