When Design Decisions Matter

Welcome.

It's the Daily Sprint.

Today we're talking about the thinking that drives design decisions.

I'll walk through a new design tool not to review it, but to ask the question, what happens when you turn your design decisions over to AI?

I’mDarrell Estabrook, 30 years into UX product design.

Yes, I didn't have a cell phone when I started, but I did have dial up internet.

I'm also the founder of designing a platform for product designers who want to design with a why.

I coach designers to lead the design process through real-time, interactive product specific guidance.

Find out more and get on board with a free newsletter at designy.com.

That's designy.com.

So welcome, Glad you're here.

It's episode seven.

My favorite member.

Well, I recorded a video walkthrough to test a theory.

There's so many tools out there, especially AI enabled features, and there's a lot of marketing.

There's a lot of demos in short, but I really wanted to kind of test it out and really think about the thinking behind our design decisions.

So I'm going to play the audio to that video.

And you can watch the video if you go to designy.com and you look for the designy digest 003.

I have a link to the video there.

So I'll play the audio and then afterwards, I'll follow back up and give you an announcement about my new course I just released on academy.designey.com.

So here we go.

Thanks for joining.

I wanted to go over something that's been on my mind a lot. Seen AI generating screens, from prompts, and there's a lot of tools out there that help you do it.

But what I'm really interested in is what is the thinking required before designing?

Because it's not just sit down and create a screen.

It never has been, but AI really enables that to be possible now.

And the other question is, can AI do the thinking for you?

Is that something that it's really leveraged and beneficial?

And then if it really can do the thinking for you, Is it helpful?

Has it really furthered you down the process?

And there's a lot of details and things we can get into on design ops.

And I think there's an opportunity there.

But we're talking about the act of creating screens that people will use and will provide business value and will scale for engineering, 3 kinds of value.

So this is the pencil app.

I'm not really reviewing the app per se, but it's one that has become more popular.

And what it has is integrated with any model that you're interested in.

This is clawed code.

I've got it hooked up to.

And this is a demo file, and there's some other things in here they're demonstrating their prompting, but I want to show you this dashboard, create a dashboard demo.

And so we're going to have it kick this off.

We'll talk a little bit about the prompt itself in the demo.

But I also wanted to mention they have a design system in this file.

So this is not an external library and maybe this app does that.

I'm not sure, not too familiar with pencil.

But I am familiar with design systems.

I'm a big figma user, and I've been using it since 2020, like everyone else.

And I've created all sorts of design systems for enterprise, ecosystems, very large scale, design teams managing those and engineers, creating the components.

So a lot involved.

This is very straightforward and simple.

There's still buttons, badges, things you'd expect.

Uh, looks like a table structure, some kind of, you know, placeholder, uh, modals, uh, cards, uh, fields, things like that.

Okay.

So we'll assume that those are all there the way they need to be.

And we'll dive into this.

So, Here's the prompt.

The prompt says, design a dashboard in the step 3 frame.

So that's the one down here for rover management platform using the components in the design system.

Add a sidebar for navigation, very prescriptive, add rover stats and table with available rovers for rent in the content body, again prescriptive.

And that's fine.

So the funny thing with this prompt, this is definitely a marketing prompt.

This is not very practical for an app, you would just start out and create this and now you have your app.

You can do it and people are doing it.

But this is something really that a stakeholder would come to me and say, hey, I want you to work for me on this project.

And here's what it's about.

It's a rover management platform and we're going to look at available rovers. And things like that.

It's like, okay.

Now let's have a conversation about what you want to build and how it works.

So a lot more that goes into it.

Let's kick this off and see what happens.

Oh, let's open this up and click run.

So it's reading the prompt at like the feedback there.

It's kind of neat.

And Pencil does an interesting thing with their AI agents, they give them names, so this is soul.

Like the sun.

That's good.

So we'll see our AI agent come up once it processes that prompt.

And there may be fits and starts, so I will skip ahead, and you might think, see things just show up.

But we'll let it run for a little bit here.

So there's soul, look at that.

It's got the frame.

It was the frame, checking the guidelines.

Picked a style guide.

So that must exist reading objects.

And then here's the to do.

So examine the key components.

Okay, good.

Set placeholder.

Can we see it examining those?

Is it examining them?

I don't know.

It's processing.

And it's looking for the key components it needs. There you go.

So it identified, it identified like 5 different things that showed up.

Now, I don't know if these components have any further documentation behind them or metadata that would help the AI agent know, you know, more context.

So this isn't a critique really on the app or the AI agent per se.

It's more about the designer and the process of using this.

And what are the results?

And what's the value of these results?

Well, the prompt that we started with was very general, very generic, which means that everything that you see here is based on assumption, there's a lot of assumption.

Now, there may be a file somewhere.

I don't know where it's structured.

I didn't see it.

It's kind of hard to know if there's any other context to reference, but even so, even with the most detailed context, there's a lot of specific information here and design decisions made that we can't trace back.

And so just even looking at the sidebar navigation.

There's assumption that we have the dashboard, which is what we're looking at, but then fleet, rentals, missions, maintenance.

This demonstrates that you do have the ability to have sections.

What these sections are is going to be totally dependent on the business rules of this organization.

And then their business processes.

Those things are critical because that's what runs the business.

You don't have to have a lick of software to run a business.

You'd have to have a process all the time.

Something happens, something else happens, and all of that caters towards the customer or the user, what they need, because you're filling a need.

So what is that?

So we don't know what that is either.

We don't know what this person using the dashboard is interfacing with, the other person as the customer.

So we don't know about that settings, health center. Those are generic as well.

We don't know the prominence of it.

The metrics are interesting.

Total rovers available to rent active rentals, revenue, those are good.

I really like the secondary information because it gives you a trend or delta or some other context.

It's not just static.

Uh, 6, you know, total Rover is 48, so 6 this month.

So we had 42 last month.

So this is a context of a month.

That could probably get clarified.

This is a 3rd of our two-thirds of our fleet are available for renting, and then here are the ones that are rented, and there's 3 pending.

And then revenue.

We don't know revenue plus 18%.

Assuming the month.

Uh, the available rovers to rent the table.

So as a dashboard, is this user interested in the details and what details are they interested in?

If they know this information through this dashboard, what action will they take?

Because the only reason to put anything on the screen is to prompt the user so that they know what to do, they can take action.

We always like to see things in successful mode, but we also want to know what's broken.

That's the hidden error rate, something that we can go and fix and get things back moving.

That's always a big, big consideration, most apps.

So it's kind of funny.

Available rovers to rent.

And we have a status, we would assume these are all available.

It's reserved in service.

These are good to demonstrate the design of a chip or a status badge.

That would be good, but it wouldn't be appropriate here.

It would never show up here.

And actions, rent, view.

It's not a button or it's not using the same button.

You know, design.

I'm not sure why but that's it.

And there's just a button.

That's good.

Just have a button.

The ad rover is interesting because this is the dashboard you would expect this would be a comprehensive view of all of these so that I could dive into any one of them.

But adding a rover, if it's here, we would assume it's a very common action that anyone would need to do all the time.

So instead of having to dive into fleet, which is probably where it would go and then click add Rover.

We're going to put it up here.

But you have to know that, right?

And I don't know, anything else. 6 of 32 rovers.

We got all of that, the total rovers.

So he missed a placeholder.

I don't know.

Some of that is just part of the the nuances of what AI is.

One thing I'm noticing, I think, is this badge.

Sorry, this card.

And I don't see, like, here's a card.

We got it's outlined in a box.

The title is called out.

We've got the metric, and then we've got that delta down below, but this is not using that.

It's it's uh, it's like what we see in real life when designers invent new elements into the design system that aren't there instead of using what's there.

And that's okay.

I think that you need to explore those things when you have new use cases.

You absolutely should explore them, but that needs to be a conversation that you have with the design system team or owner or yourself.

You need to make sure, am I designing something that is necessary because it's a new use case or do I need to extend the component that's in the design system with these new options?

And then be consistent in it.

Otherwise, there's no sense in having a design system.

So that's interesting.

It did all that analysis and then it came up with this.

I'd prefer the compactness of this, but that's for another day.

Think about this.

If you generated this screen and had to present it to a stakeholder, or anyone, could you explain why every element on the screen is on the screen, that's one of the key accountability positions the designer is in, and it's awesome to be in that position.

Because no one else is thinking about it.

There should be a reason why every element is on the screen, in the viewable area, and then screen by screen, like why we're doing that.

That is purpose driven design.

If we can't explain it, then should it be there?

And it doesn't have to be a metric oriented explanation or some sort of deep scientific rationale.

It could be something very appropriate.

Like, why are there icons here in the menu?

Or why are these buttons rounded and not square?

And you can have a brand reason why those exist.

You could have a, um, it's a visibility issue.

It's we're able to identify items more clearly, more consistently because they have these certain features to them.

But every aspect of every element should be explainable.

And so AI doesn't give you that explanation, you have to trust that it made the right decision.

And that's tricky because it's really important.

But as a designer, the real value of having that ability is as you are putting things on the screen, you should be critiquing your own designs in real time and only put those elements that are appropriate.

Now, the other thing that this didn't have, which actually pencil has this feature where you can have parallel agents doing the same prompt at the same time, which is kind of neat.

But I like to think of that in a designer thinking mode where if I'm in the middle of putting this screen together, I'm going to have a new idea midway through many times, midway through.

I'm going to say, what if?

And I'm gonna duplicate this entire screen, or that section, I'm gonna go off on a little scratch area, and I'm gonna try all the variations, and satisfy my curiosity, because in my head, I think it'll work awesome to add an icon here or add an affordance, or try the different positions of this content in the table rows.

And I'll go work on that and then I'll come back and put it in context.

Like that sort of exploration, not only gives you the ability to go to stakeholders and users and say, hey, look, we tried everything or we tried these variations, or we tried these variations, and these are 3 different options that are really effective in their own right.

They have trade-offs and we need to discuss what the trade-offs are.

Fascinating approach to it.

You're not getting that here, and it's very hidden, even if it is.

So, take a thought of that as you see these screens generated, take a thought of this as you design your own screens.

So there you have it.

Yeah, fascinating thought to consider that every design decision should be explainable.

So that's what we're going for.

So yet you can watch the video again at designy.com.

Go look for the Designy Digest 003 and there'll be a link in there.

If you're interested in exploring this further.

Then I've got a new course on designing academy.

And it's called how to make vague requirements clear.

So if you're getting requirements from stakeholders that sound like prompts and less like requirements, then you need to dig a little bit deeper, right?

Designing like an AI agent is no good.

We can do better.

And so I'll give you a three-step process to identify the type of request, understand the situation, and then define the purpose.

So it's a quick course.

You can do it during your lunch break and then even try some of the techniques in a meeting or 2 in the afternoon.

So go to academy.designey.com and look for the course of how to make vague requirements clear.

In other ways, you can get involved, of course, follow, subscribe to the daily sprint right on the platform you're listening to right now.

And you can always go to designy.com/ask.

If you have any questions or show content, you'd like to hear about.

And while you there, just sign up for the free newsletter.

Thanks for listening today.

Remember, today is a great day to design with a why.

See you later.