I've been asking a surprisingly useful question while we're building a new product:
Where does that field show up?
It came out of a change we made in the way we were designing the product.
We'd already built an early proof of concept.
It worked.
It wasn't particularly ugly.
But the more I looked at it, the more it felt like something programmers had built.
That's not necessarily a compliment, even though I've been one for more than 40 years.
We were building it from the programmer's end
We'd started with a pretty good idea of what the product needed to do.
From there, we'd started doing what programmers naturally do.
What information will we need?
What screens will we need?
What options should we support?
What other things might somebody want to do?
AI is very good at helping with that kind of development because it can turn every reasonable-sounding idea into working software almost immediately.
That's exactly why it can get away from you.
Nothing has to be a terrible idea.
You just need enough ideas that sound reasonable.
Eventually you have a product containing an awful lot of things that made perfect sense at the moment somebody added them.
I was beginning to see that happening.
So we stopped and turned the process around.
We designed the thing people would actually get
Instead of designing another application screen, we designed the finished result.
Not a placeholder.
Not a programmer mockup showing approximately where the information might go.
We worked through what we actually wanted the customer-facing product to look like.
What information belongs there?
What doesn't?
What is the visual hierarchy?
What needs to be obvious?
What can disappear?
Once we had that, we moved through the other ways the customer would experience the finished result.
What should somebody see?
What should the smaller-screen experience look like?
What should the desktop experience look like?
Again, we concentrated on what the person using the finished product would actually see.
Only after those pieces were taking shape did we come back to the creator experience.
That's when the question appeared.
We already knew which blanks needed filling
Once the finished result exists, designing the input becomes a very different exercise.
We don't need to ask:
What information might somebody want to store about this?
We can ask:
What information do we need to produce the thing we just designed?
There's a blank here.
We need the information that fills it.
There's another element there.
We need whatever produces that.
Suddenly the input process becomes much simpler.
We're not collecting information because it seems like something a complete database ought to know.
We're collecting information because the product uses it.
And that's when I started thinking:
Where does that field show up?
That's an uncomfortable question for a programmer
Programmers love fields.
I say that as a programmer.
If we're creating a record for something, it feels responsible to think of every piece of information somebody might possibly want to associate with it.
AI will encourage you.
Ask an AI to design a data model for almost any application and watch what happens.
You'll usually get a very thorough answer.
Probably an impressively thorough answer.
There will be fields you hadn't thought of.
There may be statuses, categories, optional descriptions, alternate contacts, preferences, flags, metadata, notes, timestamps, and things included for future flexibility.
Almost every one of them will sound reasonable.
That's the problem.
Very few unnecessary software features begin with somebody saying:
Here's something completely ridiculous that nobody will ever need.
They usually begin with:
While we're here, it might be useful if...
A field is never just a field
Suppose we add one.
Now somebody has to enter it.
So it needs a place on a screen.
It needs a label.
Maybe it needs help text.
Maybe it needs validation.
Maybe it needs a default.
Maybe it needs to be optional.
Maybe it needs to be searchable.
Maybe it belongs in an export.
Maybe another screen needs to display it.
Maybe somebody eventually asks why they can't sort on it.
Maybe the API needs to carry it.
Maybe old records need a value for it.
Maybe documentation needs to explain it.
The field that AI added in a few seconds has acquired children.
Those children don't disappear because the original implementation was cheap.
That's something I think AI-assisted development is going to force us to think about more carefully.
The cost of creating software is dropping dramatically.
The cost of complexity isn't.
So where does it show up?
That's why I've come to like the question.
Somebody says:
We should probably have a field for this.
Fine.
Where does it show up?
If it appears in the finished result, we know why we need it.
If it changes part of the customer's experience, we know why we need it.
If it controls something necessary behind the scenes, that's a reason too.
It doesn't literally have to be visible.
There are plenty of legitimate internal fields.
But they still need to do something.
They need to control state.
They need to establish ownership.
They need to make a workflow possible.
They need to preserve something we promised.
They need to exist for a reason.
If the answer is:
Well, nowhere right now, but we might want it someday...
now we've learned something.
Maybe someday is the right time to add it.
We don't need to anticipate every future product
There's a temptation in software development to believe that a good architecture anticipates everything.
If we can imagine a future requirement, maybe we should prepare for it now.
Sometimes that's wise.
Sometimes it's just another way of building imaginary products.
This project is making me more comfortable with a different approach.
Build what the product currently promises.
Build it cleanly.
Give the architecture enough room to evolve.
Then evolve it when you have an actual reason.
We don't have to put every possible future feature into version 1.0 merely to prove that we've thought ahead.
Thinking ahead and building ahead aren't the same thing.
The same test works on features
The question isn't limited to database fields.
Someone proposes another option.
What changes because of it?
Someone proposes another mode.
Which part of the defined experience needs it?
Someone proposes another choice on a screen.
What happens if we don't provide it?
Someone proposes a whole new feature.
Which part of the product's promise does it fulfill?
Sometimes there will be an excellent answer.
Great.
Build it.
The point isn't to make software deliberately weak.
The point is to make complexity justify itself.
"AI can build it pretty easily" isn't enough.
Neither is:
Somebody might want it.
Somebody might want almost anything.
The finished product is keeping us honest
That's probably the part of this development process I'm enjoying most.
The finished output keeps us honest.
We can look at it.
We know what we're trying to produce.
When we're working on the creator experience, we aren't inventing an abstract data-management system.
We're giving the user the shortest reasonable path to produce that result.
When we get farther down into storage and business rules, the same thing will still be true.
The machinery has a job.
It exists to support something we've already decided matters.
That makes the development process feel very different.
Instead of building a big program and gradually discovering which pieces need to be removed, we're adding the pieces that prove they belong.
Less is easier when less comes first
People have been saying "less is more" for a very long time.
Software developers aren't always very good at practicing it.
It's hard to simplify something after you've built your assumptions into the data model, the interface, the workflow, the documentation, and the user's expectations.
It's much easier when the unnecessary complexity never gets there.
That's what designing this product from the outside in has shown me.
We're not trimming the fat.
We're trying not to add it.
And one very simple question is helping:
Where does that field show up?
If we have a good answer, we probably know why it belongs.
If nobody can answer, maybe that's the answer.
Related guide
For the broader development framework behind this approach, read Design From the Outside In.