S2E30
· 57:22
Nicolay Gerold: I think most of us, you
listening and I live in the backend.
We build the systems that
make everything work.
And we spend most of our day thinking
about data models, creating pipelines,
query understanding, re ranking, search,
but we are often far away from the users.
And this is the gap we rarely
notice that users bring their own
mental models to our creations.
And these often clash with our pipelines,
with our logic, with our data structure,
and then we deliver bad results.
And today, we are talking to
Jorge Arango, who is an expert
in information architecture.
And we are talking about how We can
let information do its job, which is
helping people make better choices.
And we explore how to build systems
that match how your users think, not
just how our systems in the backend,
how computers process the data.
Let's do it.
Your podcast, it's like such a refreshing
difference because like most of my
podcasts are AI centered as well, and
it's so refreshing to get a very different
perspective on like the whole field.
Jorge Arango: Yeah it's a little
bit all over the place just
because the subject is a bit broad,
how people manage information.
So that that gives a lot of latitude.
Nicolay Gerold: yeah.
And also lots of different people.
I think I, I listen to at least 50,
Jorge Arango: Wow.
Nicolay Gerold: and it's it's
really interesting, like who you
got on, like from what field?
Like some really old
school, some really new.
That's really cool in my opinion.
Jorge Arango: Yeah, one of the, one
of the underlying principles, one of
the things that I hope comes across
is that a lot of the things that we
talk about are actually timeless.
The technology might be new,
but the ideas are not new,
Nicolay Gerold: what about the two
to three most interesting things
you've learned in the podcast?
Jorge Arango: Oh, wow.
It's really hard for me to mention any
three right off the top of my head.
I I had a conversation early
on in the show's history.
with somebody who managed
the record collection for the
Danish broadcasting company.
And this was a physical record
collection, like music collection,
but it was like physical records.
And and I remember that being a
really interesting conversation
that entailed making decisions about
how to organize music when it could
only be organized on one dimension
because physical space, right?
Like when you're dealing with software,
you can organize things based on lots of
different lots of different dimensions.
But when you're organizing things in
physical space, you have to make choices.
So I remember that one
being really interesting.
It's, I've always gotten
something out of every episode.
Some of the subjects I knew more
about than others going into it.
But, uh, the main thing about it for me
is really, is not so much the ideas as
it is the connection with the people.
And, a big part of that podcast
was recorded during the pandemic.
And for me, it was just a
lifesaver because I'm someone
who likes to meet people.
I like to go to conferences and
I like to, I like to talk with
people and see what they're up to.
And the podcast gave me a really good
excuse to reach out to folks during
the pandemic when we couldn't do that.
And say, Hey, can I talk with you for
an hour and share our conversation?
And that was great.
Nicolay Gerold: Yeah, for sure.
And do you think that, it
makes me really curious.
Do you think the constraints we have
in a physical world is, makes it a
little bit easier to organize stuff
because you don't have so many choices?
Jorge Arango: Yeah, that's, that is
there's something to that, right?
The whole paradox of choice thing.
That's where smart defaults come in.
For a lot of things you can get by with a
few smart defaults, and you don't need to.
That's something that it's taken
me a while to learn that, but but
eventually I did learn it that.
Even if a system offers you all sorts of
capabilities, doesn't mean that you have
to take advantage of all of them, right?
Like you can focus on the on a few basic
things and get many of the benefits that
you're going to get from the thing with
a relatively small amount of effort.
Nicolay Gerold: What are some of
the most interesting defaults you've
seen are also the weirdest ones?
Jorge Arango: Um, one that
immediately comes to mind is
whenever I buy a new laptop.
I upgrade my Mac.
I've been using Apple laptops for a
long time and whenever I get a new
one, I oftentimes start from scratch.
So you know how there are people who like
will migrate their old configuration to
the new one, you're shaking your head.
It's No.
Nicolay Gerold: I don't do that either.
Finally, the time to get rid of stuff.
Jorge Arango: That's exactly right.
It's an opportunity to get rid of some
things that might not be working for
you, so I like to take that opportunity
to do a little bit of housecleaning.
And with with so much stuff being on
the cloud these days, it's relatively
easy to get back up and running, right?
It's feasible to do that.
And it used to be that I
would spend a lot of time.
Whenever I did that, I would spend a
lot of time tailoring everything so that
it functioned exactly the way I wanted
it to and and and tweaking things.
And there eventually came a
time where I realized that
Doing that entails a lot of maintenance,
you have to, you have if you install
a lot of software, the more software
you install, the more software you
have to maintain, you have to upgrade.
And I've slowly learned to live more and
more with just kind of default stuff,
using Apple Mail instead of playing around
with different specialized mail clients.
That would be an example of that, right?
Um, I'm sure if you saw my
computer, you would go, Oh, my gosh,
he's got all this custom stuff.
Nicolay Gerold: Yeah, I think that's,
I think that's really interesting.
I think I'm the going to the opposite.
I have four different code editors,
which I'm using most of the time.
I'm switching around it.
Jorge Arango: Yeah, I say that and
I'm taking notes here using Emacs,
which is talk about something that
requires a lot of customization, right?
And I've been I have, I've been
using Emacs For we're coming on 25
years now and over that time you
pick up a lot of little tweaks,
Nicolay Gerold: yeah.
Nice.
What do you actually, what do
you think about, like, when you
hear the data model defines the
application, what comes to your head?
Jorge Arango: The first thing I have to
say is that I am not a developer, right?
And I have to say that upfront because
I suspect that for this podcast, i, I
would imagine that a high percentage
of the audience are folks who know a
lot more about development than I do.
I'm primarily a designer
of information systems.
And when I hear when you, the phrase
you used was data model, but that, but
what comes to my mind is all systems
have underlying conceptual structure
that either adequately reflects the
mental models that its users bring
to the interaction or they don't.
And the data model is where that
conceptual model often gets Made
normative, it becomes baked into the
infrastructure of the application, right?
And I mentioned working with
Emacs, which is a very old.
It's a very old software
application, right?
And when you work with a system
that old, It's idiosyncrasies and
anachronisms come through, right?
And in some ways that is
its underlying model shining
through to the user interface.
And the, I see the data model as a
place where these conceptual models
get reified and and become Part of the
infrastructure of the application and
often end up manifesting in the user
interface which is one of the things
that people like me try to help with so
that, my ideal, the thing that I aspire
to is to design systems where somebody can
sit in front of them and think, Oh, the
person who designed this really gets me.
They really get how I think, that
requires understanding the mental
models of the people who use the
system and what their expectations are.
And, And I realized that the data
model plays a different role.
And for people like myself,
oftentimes what we need to do, I
said that I function sometimes as a
translator that aims to make it work.
A system that is understandable and
usable to end users, but also is
possible to implement by developers.
So it's almost like a translation role.
Nicolay Gerold: Yeah, I think that's
something designers like to forget.
They sometimes get caught up in like the
really nitty gritty details, which are
often a real pain to implement in the end.
If you would flip it around, if you
would have to build like the worst
information system, how would you
start it and what would you do?
Jorge Arango: The worst
information system.
Nicolay Gerold: Yeah.
Jorge Arango: Oh, my gosh.
So it might be worthwhile to take a step
back and think about what information is.
It's one of those, information is one of
those terms that we use quite casually
without really pausing to understand, to
think about what it is that we mean by it.
And whenever I ask students, for
example, to say, it's like, what
do you understand by information?
I think that when you try to articulate
it, you'll find that it's challenging.
The way that I like to think
about information is that
information is anything that.
helps you make better choices so that
you can act more skillfully, right?
So the example that I use, for me
it's like the canonical example.
I used to live in a place in a kind of
typical American suburb that had houses
with front lawns and I would walk my
dog through the neighborhood and some
houses We'd have these little signs out
in the front lawn with, you may have seen
these, with a dog pooping and a don't
poop here sign, it's like with a little
circle with a line through it, right?
Meaning, some of these houses had made
an explicit choice to say to the other
people in the neighborhood, you should
not allow your dog to go here, right?
Those little signs are information.
They're helping me make a decision
when I'm walking my dog about whether
I let the dog go there or not.
And in so doing, they help me
possibly predict what might happen.
If I let the dog go in a yard that
has one of those signs and the owner
comes out, I may get punched in the
nose or screamed at or something.
So information is about
helping us make better choices.
And I would think that a system That
that is designed to, to do the opposite
of inform you would be a system that
you find completely irrelevant to you,
a system that doesn't offer you any
useful guidance to things that you care
about, things that you want to get done.
And it might be that it's a system that
is perfectly usable and interesting
and useful to somebody else.
It's just not for you, right?
Maybe that's something
that we could design an A.
I.
System that Detects what you're interested
in and what you want to do and then it
does completely the opposite, right?
Or it builds an interface that
is so obfuscated that it actually
makes it difficult for you to
glean the things you need to glean
to do the things you need to do.
That would be the opposite of an
information system that that is
designed to help people, I would think.
Nicolay Gerold: Do you think
the design should also clearly
communicate who it is not for?
Jorge Arango: I don't know that
it should be explicit about it.
I think that well designed systems.
It's really hard to categorize it like
that, but there are systems that you
interact with that you can see them.
When you see them, you immediately
know, oh, this is designed for somebody.
This is well designed, but
it's not for me, right?
And that tells you subtly that
it has been thought through.
It just has been thought through
for a different audience.
I'm sure that you've interacted
with systems where you're asked
to self select into an audience.
I think that's one way to do it.
It's just a bit of a blunt instrument.
One that immediately comes to mind
is Leica, the camera company, right?
Let me open the website to make sure
that this is still true so that I don't
sound like I'm disparaging them, right?
But when I remember
visiting that website leica.
com, and yeah, it's still like that.
And when you when you first opened leica.
com, you'll be greeted with a
homepage that It tells you up
front that Leica, the brand Leica,
actually refers to four different
companies that share the same name.
And there is very little indication
as to what these companies are.
There is a, there are photographs
of different products, right?
And then there are slide overs.
So when you slide over the product,
You get a little slide over
with a sentence that describes
what these things are, right?
So this would be an example of a
website that is asking the user to
self select into a particular audience.
And, um, I would imagine that
they have good reasons to do this.
If you are sharing your brand with
three other companies that do very
different things, you're going to get
a lot of emails from people going,
where are the microscopes or whatever,
if you're the camera company, right?
So they have to do this, but this is, this
would be like one end of the spectrum.
I would imagine that there are
ways to do this more subtly
in less extreme circumstances.
Nicolay Gerold: So do you think like
specificity of a website, like what are
you selling and why is the user actually
here is the most important thing.
Jorge Arango: I think clarity
is the most important thing.
And I, and what you're describing
is a manifestation of clarity.
Some information domains require
more explanation than others.
For example, if you visit, A website
that you've never seen before.
And and it's, it belongs to a brand
that you've never seen before.
So you have very little in the way
of a mental model, but you start
reading a navigation structure
that uses terms like, Savings,
checking, credit cards, loans, right?
You don't have to know a lot more
than that navigation menu to get a
mental picture that you are operating
within the context of some kind of
financial services organization.
Probably a bank, right?
And because you've interacted with those
types of organizations in the past,
you have expectations that you bring to
that interaction about what you might
likely encounter there, what kinds of
things you might or might not be able
to do there, what kind of what kind of
structure that experience will have.
For example, bank websites usually
have some kind of login box.
Where you can enter your username and
password and pass from the marketing
side of the house to the more private
your account side of the house.
So all those things are things that you
bring to that interaction implicitly.
The bank doesn't have to tell you those
things because banking is a known activity
and we've been doing banking online for
long enough where you know what to expect.
If it's a different kind of business or a
different kind of organization, one that
offers a novel service, for example, you
have a bit more explaining to do, and you
have to do a lot more context setting.
And we see that a lot with
new technologies, particularly
now where there's a lot of
stuff happening around AI.
People are coming to these
experiences without having.
Very solid mental models about what
the thing is and how they can use
it, how they can interact with it.
And you have some more explaining to do.
The degree to which you have to fill in
those gaps depends a lot on the particular
use case, the particular scenario.
Clarity is what you're aiming for,
and that requires that you understand
you're talking with, who your audience
is, and what the subject domain is
that they need to interact with.
Nicolay Gerold: Do you think this
is one of the biggest issues with.
boxes and chatbots that many companies
just throw it on there without thinking
about like how to tell the user how to use
it correctly and also to try to understand
how the user will and could use it
Jorge Arango: Yeah, search
boxes and prompts, right?
Like the chat boxes for
chatbots and stuff like that.
It's very interesting because
they're so useful, right?
There's no denying that search boxes
and chatbots are incredibly useful.
But they're useful in a
particular range of scenarios.
Particularly the ones where the user
comes to the interaction with with
some kind of mental model about what
they can expect to find there, right?
That is actually more true of
search boxes than it is of chatbots.
I think that with Gen AI, we do
have the opportunity to have these
things be more conversational and
try to help the user find their
way to what they're looking for.
But the interface doesn't
give you a lot of clues as to
what you might expect there.
The, I have this thing that I'd like
to say that That English, and I'm
just calling out English because
it's what we're speaking now, but
English is a human API, right?
It's it's it allows us to interact,
but it's very, and it's super powerful,
but it's also very open ended.
And and if you come to an interaction
and all is a blinking cursor, It's
almost like you have to take the
first step and you have to know what
you expect to find there in order to
interact skillfully with the system.
It's actually a throwback to the way
that computers used to work 40, 50
years ago when, before the GUI era, you
interacted using a command line prompt.
And that required that you know the
magic incantations that allowed the
computer to list your files and change
to a different directory or copy a file
from one directory to another, right?
The interface itself didn't give you clues
as to what you can, you could do there.
One of the great one of the great
innovations, one of the reasons
why GUIs took over the world.
is that when you expose the options
in an interface where people can
see what they can do there, you
are you are making the possibility
space visible in some ways, right?
Like you're not requiring that
the user may take this first step
of exploring the subject domain.
So I do think that search boxes
are very, They're powerful.
They're obviously an important component
of many systems, particularly the
ones with a lot of content in them.
But there, I don't think they're
going to replace replace interfaces
that allow people to browse
through through the options in a
system for that reason, primarily.
Nicolay Gerold: when we chat the
first time you mentioned something
very interesting, which is that
information architecture is more like
an education and that you're through
the choices you make in designing it.
You try to educate the
user about the field.
and direct him where he can go
and also how he could search.
Can you maybe go into what a great
information architecture in the terms
of education looks like and what tools
you can use to actually construct it?
Jorge Arango: Yeah let me tackle
the first part of that first.
To expand a little bit on that,
there is a misunderstanding about
user interface design.
I'll talk specifically about UI design.
There is a misunderstanding as to what
the goal of a user interface design is.
I think a lot of people think that the
goal is to make interfaces intuitive.
And you will often hear that word use,
it's like it's, it needs to be intuitive.
Very few things are intuitive.
There's a long running joke in the
industry that, and I don't know if this
is considered inappropriate, but but
the joke is that the only intuitive
interface for humans is the nipple.
Everything else is learned.
And There is a saying from Richard
Sol Warman, who who who is a
person who popularized information
architecture, and he says that people
only understand things relative
to things they already understand.
And I think that's a very powerful idea.
If you think back to how you learned
something like a new concept, something
that was new to you, the way that you
likely learned it is by relating that
concept to ideas that you already knew.
So there are very few things that
we encounter that are impossible
to relate to other ideas.
Whenever we learn something new,
we usually do it by scaffolding.
Our understanding of that new idea on
things that we already know how that
would play out in something like an
information architecture is imagine that
you're designing a system that is for a
novel financial services application, some
kind of new fangled new fangled financial
services product, something that is That
when users encounter it, they're going
to need to have some someone explain it
to them because it's like, it's just the
mental model is so different that they're
not going to know how to operate it.
It's likely that there is at least
some language that you have to use that
is going to be novel to those users.
And if you expose that language right off
the bat in things like your navigation
structures, people who get to that place
are likely not going to know how to
make choices about what they need to do.
They need to be inducted into the
language to make skillful decisions.
So one way to do that is by using
language that is familiar to them.
And then through that language,
expose them to the new ideas.
For example, it might be that your
navigation structures in the system
use terms that they are familiar with.
From financial services, and then
when they read the content of those
pages, then you explain the new
concept in the context of this thing
that they already understand, right?
So that would be an example of
trying to make a learnable interface.
I like to say that is what we
aspire to, especially with complex
systems that are complex That are
presenting a lot of novel ideas.
You, you should not try
to make those intuitive.
You should try to make them learnable and
that entails understanding what your users
are likely to know and then structuring
interfaces that give them enough clues so
that they can find their way to getting
things done, even though they might not
be familiar with the concepts that they
need to do in order to get them done.
Nicolay Gerold: So you
basically see it as a journey.
You have a lot of different users,
so you have a lot of different
starting points, but you have
to assign a system that actually
takes them to a joint destination.
How do you actually account for like
the different backgrounds, skill
levels that you can have in the users?
Jorge Arango: You have to do research.
First of all, you have to understand who
the users are, and different systems are
going to have different kinds of users.
They in some ways, the hardest systems
to design are the ones that have to
appeal to a lot of different audiences
with very different skill levels.
I'll give you an example of systems
in both ends of the spectrum.
I once helped with the design
of a an energy trading energy
futures trading marketplace.
So this was a place where energy
traders, note that it's a very
specialized audience, right?
Energy traders would go, they would use
this tool to buy and sell energy futures.
For different regions, that
is a very specialized type of
user and they in understanding
how these people do their work.
You when you sit down with them
and quickly you quickly come to
the realization that they have to
move to make decisions quickly.
They have to see a lot of information.
Interfaces have to be very dense and that
entails, they use a lot of very kind of
jargony terminology, a lot of acronyms
that to me, even as a designer, they
don't mean anything, but to these people,
it's like, these are the terms that
they use when they're doing their work.
And if you know that going into it, you
can design a system that that is going
to help them get their work done, right?
On the opposite end of the spectrum,
I once helped with a project for
a website whose target was anybody
residing in the state of California.
That is a much broader audience, right?
Like that audience needs to be, you
have to assume at that point that
you are dealing with people who
for whom, English might be a second
language, who might be at different
levels of education, of comprehension.
You cannot use jargon, you cannot use
a lot of obscure terminology, so you
have to really You know, you have to
really pare things down and you have to
do it with the knowledge that might be
frustrating for some users who like the
more specialized users might find the.
Kind of overly simple interface to
be talking down to them, or maybe on
making things unnecessarily complicated.
So there are techniques to overcome that.
One of them is called
progressive disclosure.
The idea that by default, the system
is structured in such a way that
it speaks universally to everybody.
But then you give the people who are
more knowledgeable or who have more
expertise, you give them clear signals
as to what part of the system they can
go to find all the shortcuts, right?
The I think of the prototypical
example in that in that in that space.
There was a tool in the 1980s that
Apple put out called HyperCard,
which was It was the first the first
hypermedia editor that I ever saw.
And this thing by default looked
like a drawing program where
you would move around buttons.
It was Visual Studio before
Visual Studio existed, right?
You would drop buttons and visual, you
would manipulate these user interfaces
visually to create a hypertext.
And if that's all you wanted
to do, you could do a lot
of stuff just at that level.
But behind the scenes, there
was a programming language.
And once you became a proficient
enough user the people who designed
that application had made it possible
for you to discover the fact that
there was this other layer behind it.
And once you understood that there
was a programming language behind the
scenes, all of a sudden, all sorts
of power was, it's like you unlocked
a new level, in the application.
So it's so the application could be used
by both types of users successfully.
And of course, there
were people who never.
They never crafted their own
interfaces or did any programming.
They were just end users of
work that other people had done.
So this thing was usable by people of
different levels of proficiency by design.
And that's something that that's
a strategy that we can use in
products to, to address that issue.
Nicolay Gerold: Yep.
What do you actually think is the
importance of setting a boundary
around the domain you're working in?
Jorge Arango: There are many benefits
to setting a boundary around the domain.
I think that the most important
one, for me at least, Is that
we all we're always
functioning in some context.
This conversation that you and I
are having, we're having it within
a particular context, right?
Your podcast, the topic of your
podcast sets a context the fact
that we're talking about technology.
Like I, I feel like I can trot out
these old examples of things like
HyperCard and it will be understood by
the audience because we share some, we
share some kind of common ground here
that we're talking about technology.
All interactions happen within a context.
The context influences how we
understand what we're doing,
how we understand each other.
Language is often meaningful in context.
Terms acquire different meanings
depending on where you experience them.
An example of that is the verb save.
So save is a common everyday word,
but save means different things.
If you use it in the context of
computing, like we're talking about
now, if you use it in the context of a
bank that it means a different thing.
If you use it in the context of a church,
it means a different thing, right?
So it's the same word, but
it means different things.
And it's very important when designing
a system where people are meant to carry
out certain tasks, it's very important
that they understand where they are so
that they know what is expected of them
and what they can expect to do there.
We talked earlier about the bank, right?
If you are visiting an online bank,
if you're using an online bank, you're
going to have expectations about
what you can and cannot do there.
And and you're going to have
expectations about what certain words
mean in that context, a bank that
used very different language or that
created a very different context.
Would make it challenging for
people to get things done, right?
Because they would not, they would,
you would lose all the benefits that we
have from experiences and interacting
with these services in others, in
other scenarios in the real world.
So yeah, setting the boundaries
of a domain helps us create
contexts and contexts have a
huge influence in how, okay.
Skillful we can be when
carrying out certain tasks.
So that's I would say that's one of the
most important reasons why you would
want to be clear about the domain.
Nicolay Gerold: Would this mean that the
clearer or narrower the boundaries, the
clearer the context, the easier it is
to design an information architecture?
Jorge Arango: I think that the clearer
you are on what it is that the system
is supposed to do and who it's supposed
to do it for, the easier it is to
design an information architecture.
The hardest systems to design are the
ones that are meant to do a lot of
things for a lot of different people.
Just because it's, the very nature
of the exercise makes it so that you
have to do all these layering things
that we were talking about earlier.
You have to give ways for people
with different skill levels and
different abilities to find their
way to what they need to do.
Whereas a system that is more narrowly
focused, it's easier for you to understand
the people who are going to be using it.
What they expect to do there, what they
need to do there what the company, if
it's a if it's a commercial thing, what
does the company need to get out of it?
The company also has Certain objectives
that it expects the system to do.
Maybe you want the system to
to allow people to buy more
stuff if it's a store, right?
Or maybe you want the system
to encourage conversions.
So when the narrower the domain,
the easier it is for you to
answer questions around it.
Who is using the thing, what do they
need to see when they get there, to
get their stuff done, and what is the
business context which is which has
brought this thing forth into being
like the company, the organization,
like what do they want out of it?
Those questions, the narrower the domain,
usually the easier it is to define
those, and then you're off and running.
Nicolay Gerold: Yeah.
And same goes like from a search
perspective, especially I talked
to An engineer from Reddit who is
doing their search relevance work.
And they have a lot of things
they have to work through because
the search on Reddit is so broad.
They have like hundreds of different
topics or like things that could happen.
And depending on the user, which
the community there, and it's
always something different.
And this makes it like really challenging,
but also really interesting in the end.
Jorge Arango: Yeah, I would imagine
that Reddit is an, yeah, that's
an example of a system that must
satisfy a lot of different use cases.
I would, something like
Google is another one, right?
It's like an open ended search
engine which has a lot of
other services baked into it.
These are examples of systems that
must be universally usable and must be
usable for lots of different use cases.
Those are much harder to deal with.
Nicolay Gerold: Yeah, and he's also
he's I'm not sure whether you know rack.
Of course, he's starting
a counter movement.
He's calling Gar.
So turn it to say I augmented retrieval.
How do you think other lamps can
help people navigate websites,
but also in search in general?
Jorge Arango: It's very clear that LLMs
are a major innovation and one that is
going to transform things significantly.
I don't know that we are sure yet
about how it's going to play out.
I do think that it's going to change
things like the search experience.
Where we already see it, right?
With systems like perplexity where rather
than rather than you entering a phrase or
a set of keywords and getting back a list
of a list of pointers to web pages, you're
getting back answers with references
to where you can follow up, right?
So there's this notion of parsing the.
Parsing the request more conversationally
and then providing you an answer that
is looking to be more of an answer and
less of a kind of list of references.
I think that's like the most obvious
the most obvious near term change.
But but I think that there's also
going to be, there's also clearly lots
of opportunities to use these tools.
To improve the way that regular old
fashioned search works one way could
be by helping parse out the intent.
Behind what you're searching for
so that you take the phrase that
you've entered or the keywords that
you've entered and maybe try to add
a little bit more context, perhaps
based on previous interactions, right?
And and issue a search based on that.
You've mentioned rag rag
is Is an attempt.
I think that I think of it as a way
to improve the quality of the results
that you get from interacting with an
LLM by fusing it with techniques that
come from the search world, right?
Like you're essentially the you're
basically injecting search results
into the context window that gets, for
the prompt that gets sent to the LLM.
So there's, I think that there's
opportunities both to explore
novel interfaces, but there's
opportunities to also improve the
things that we're already doing.
Like search, or in my case, I've
been using I've been using LLMs both
straight up and also using rag to do
my work as an information architect.
And this is just for structuring, like old
fashioned structuring web content, right?
I've used LLMs to help me retag
large content repositories.
I'm using it to help design new
navigation structures for websites.
Because if no, if nothing else, these
are incredibly powerful text processing
tools that let you analyze a lot more
information a lot faster than we were
able to before these things existed.
So I see them improving both, improving
the work that we do both through
novel experiences that we are able
to generate and also because they
empower us in designing the sort
of systems we were designing before
only faster, better, and cheaper,
basically, are you asking specifically
Nicolay Gerold: What I always like
to ask is, especially with LLM.
So Is overrated versus underrated.
What's an overrated technology and
what's an underappreciated technology
or technique that you see at the moment?
Jorge Arango: Or just in general?
Nicolay Gerold: very general.
Jorge Arango: In general,
overrated and underrated.
So I think that the for the underrated
one, I would say I would harken
back to where we started in today's
conversation talking about models.
You asked about the data model, right?
So there, there is an equivalent in the
design space, which are conceptual models.
And
I think a lot of designers.
I'm going to generalize,
but I think this is true.
I think a lot of designers, when they
start the design work, they do research.
Fortunately, that's already
become ingrained, the fact that
you do have to do research.
You have to understand the problem domain.
And then there's this idea that
once you have a grip on the problem
domain, then you start designing.
And what that means for a lot of
designers is they start sketching screens.
They start drawing like, they start doing
these little sketches to think through
what the interface is going to look like.
And I argue, not just me, but a lot
of people argue that there's a step
that comes before that where rather
than sketching the implications at
the UI level, you start thinking
through the conceptual model
that is going to inform the UI.
This is the equivalent of the data
model in, in in development, in that
you're thinking about the concepts
that need to be present in the system
for people to get stuff done and how
those concepts relate to each other.
I think it's underrated because, frankly,
a lot of people don't know about this.
They don't do it when
they're doing design work.
And and it's very important
because it leads to systems that
are more cohesive and coherent.
Particularly when dealing with
large systems, because they
allow you to see the big picture.
When it comes to overrated, I have
to say, I'm going to say one that
is specifically in the realm of
information architecture, which is
my area of focus, and it's sitemaps.
I, I think that a lot of people associate
information architecture with sitemaps.
I've seen a lot of a lot of portfolios
particularly for students, student
portfolios that have, they usually
have for a project, they'll have
a little part that says, here's
the information architecture,
and it's always a sitemap, right?
And sitemaps are a useful.
design artifact that you can
use to communicate intent, but
they are not the end all be all.
And they the issue that I have with
them is that they imply a kind of
hierarchical rigidity that isn't actually
true of most interactive systems.
Most interactive systems are not laid
out in this inverted tree, right?
Like there, there's more than one way to
get to a particular part of the system.
And the sitemaps do away with a lot
of the nuance and complexity that
that make interactive systems so rich.
So I would say that is a tool
that is greatly overrated.
I would do a lot more conceptual modeling
than site mapping if if if I was a
designer, if I didn't know what I know.
Nicolay Gerold: Yeah.
I love them, but just for an
entirely different reason that it's
very great for scraping websites
when you have a good sitemap.
Jorge Arango: It's very,
they're very useful.
They're very useful for
a variety of things.
They're, for example, they're very useful
to, for conveying intent around the
Overall structure of a website, right?
But you have to go into it,
understanding that most interactive
systems are not rigidly hierarchical.
And I think that's a very important
thing for people to remember because
you don't want, particularly for complex
systems, you don't want this rigid
top down thing you, you lose a lot of
opportunities to, to add nuance and to.
And to make a system that is really
responsive to user needs and user
interactions by if you start dictating
structure from the top down and
and I don't think that sitemaps
force you into that direction, but
certainly the form of the diagram.
Strongly suggests that you do that, right?
So you have to be, you have to be
careful with the tools you use.
Nicolay Gerold: If you could
enforce one practice in engineers.
What would it be like, especially
from the designers perspective,
Jorge Arango: I'm sorry,
you cut up a little bit.
Can you ask the question again?
Nicolay Gerold: if you could enforce one
practice in engineers, what would it be,
especially from the designers perspective.
So you have the chance to
fix one of your annoyances.
Jorge Arango: I think it would be
presumption presumptions of me to
try to enforce anything on engineers.
If anything, I would love to
learn from engineers rather
than enforce anything on them.
I would say, though, that one thing that
that let's use different terminology.
What would be good for engineers and
designers to talk about when they go
out to lunch or something like that.
I think that one of the things where
designers can contribute to the
conversation is in bringing The user's
perspective into the equation, right?
So what I was talking about earlier,
understanding that different people have
different levels of competency, different
levels of familiarity with the subject
domain, all of that stuff designers
can contribute to the conversation
through research, through modeling.
Through through things like what I
talked about earlier, progressive
disclosure like this notion that
you build layers in that accommodate
different levels of competency.
Those are all things where I
think designers can contribute.
I would also love to say, to flip the
conversation around and say, I think
that designers could benefit from a
lot more designers could benefit from
understanding how things are built.
How the systems that they
are designing are built.
There's this long running argument in
the design space about whether designers
should know how to code and there are
some people who vehemently feel like
that's asking too much of designers.
I feel differently about that.
I think that it's very important for
designers to understand the materials
that they're working with when when
I was an an architecture student.
We had a class called Materials
of Construction, where we had to
learn the math behind materials.
So like the, how do you calculate
the tensile strength of steel?
But we also had a studio, like
a lab course where we would
learn how to do arc welding.
And when you understand the, when
you understand the capabilities and
constraints of a material firsthand.
You become a much more skillful
designer, is how I feel.
So I don't expect that, I wasn't,
when I was in architecture school,
I don't think anyone intended
for us to become contractors.
And I don't expect that any designers are
going to become engineers or developers.
But it would be good to understand what
the software can and cannot do, right?
You asked about the data model.
You need to understand
how data is structured.
If you're going to be
creating information systems.
So I do feel that both engineers and
designers have a lot to teach each other.
Nicolay Gerold: Yeah.
What's next for you?
What are you excited about?
Jorge Arango: I'm
excited about everything.
Being involved in technology is a,
just an endless gift because this
is a field that keeps evolving.
And there's a saying, I don't
know if you've heard this,
it's from from Bill Gates.
He said something like
we always overestimate.
The change that will happen in the
next two years and underestimate.
The change that will happen
in the next 10 years, right?
And if you think back, and
I think that's true, right?
I've felt it myself, but if you think
back just over the last two years, there's
no way that we could have underestimated
the change that we've seen since ChatGPT
released in the fall of 2022, right?
And language LLMs and machine
learning have been around
for a lot longer than that.
But grafting this chat user interface
on top of it really blew it up, right?
Like it made it clear to a lot of people
just how powerful these systems are.
And and it's just very clear to me that.
We are going through yet another one of
these major technological shifts that
keep this work so fresh and so interesting
and it and frankly is bringing a lot of
benefit to a lot of people in the world.
So I'm I'm super going home for that.
I'll also say something else that I'm
excited about, although it's, I think,
less tangible and less Ironically,
less tangible and less less popular
right now, which is spatial computing.
And I don't mean spatial computing
in the sense of extended reality
or virtual reality like with
with Vision Pro and these things.
Just pervasive computing
in physical environments.
There's this project called Dynamic Land
that Brett Victor and a bunch of other
folks have been doing for several years.
About they're basically building
a computer that is a physical
space, a collaborative physical
space where you can interact with
information using things that you're
familiar with, paper, pen marbles,
little things that you move around.
That kind of thing is
hugely exciting to me.
I guess it's on my mind because,
just released a new website for
dynamic land just yesterday.
And that stuff has so much potential.
We've been interacting.
With computers through these small
glass rectangles that we carry
around in our pockets and and in
our backpacks, but computers can
be so much more than that, right?
And we can bring our whole
bodies to these interactions, and
there's just so much potential
when you think about that, right?
So I've seen nothing but
possibilities on the road ahead,
and I'm very excited about it all.
Nicolay Gerold: Yeah.
And if people want to get in touch
with you, where can they do that?
Jorge Arango: The best
place is my website.
J.
Arango dot com.
So that's jarango.com
and you can follow me there.
There's pointers to my social media.
I have a newsletter, and I write a lot
about information architecture, how to
leverage artificial intelligence for
doing this kind of work, and I'm very
active, both there and on social channels,
particularly LinkedIn these days.
Nicolay Gerold: And also a great podcast.
I think if you're listening to
this, you might like it as well.
And we will link to all
of that in the show notes.
Jorge Arango: I appreciate that.
Thank you, Nicolay
So what can we take away when we
are building our applications?
So first of all, before you write
any code, you want to really
map the conceptual model or the
understanding you have and your users
have of the problem you're solving
or the solution you're building.
And it's often really interesting to
Listen to how users talk about the
problem space and just to put yourself
in the frame of reference they have
of how a problem has to be solved.
And the same goes into testing.
Like when you build your
system, like testing.
Naming and your application with real
users really pays off in the long term.
And for more complex applications,
something like progressive disclosure,
where you have a simple entry point
and really good defaults, which allow
the user to get started quickly, but
depth, like for example, keyboard
shortcuts for power users is something
I think most applications are missing.
Um, something that we as
developers are used to.
Because most of us.
Start with a really easy code editor to
use like VS Code and over time, configure
it more and more or switch to other code
editors like Neovim, which is completely
tailored and customized to how we work
and So many applications are missing
stuff like that, like the people who spend
time thinking about the defaults that are
being sets and also what configurations
I want to expose to the user.
And I think like the last
reminder, a reminder, if the user
can find it, it doesn't exist.
So, and this holds for like search
results, but also for settings,
configurations, features, and this
is a general practice, I think
we should pick up more and more.
If something isn't used, just delete it.
And this goes for like repos, features,
codes, uncommon, or like comments.
Um, especially stuff that is
commented out and just left
in there, um, just delete it.
Uh, most of the time you're better
off not having it and at some point
you still can restore it if you have
version control set up, but you rather
want to remove it and release the
cognitive burden for future engineers,
which might stumble over the code.
And yeah, um, that's it for the episode.
This is actually our last episode.
In search, I think it's the 30th one.
So we've spent 30 weeks in search.
Um, which is really interesting.
We will be moving off of search
and going into MLOps soon.
Um, actually I will be
launching two new series.
One is on MLOps, which continues like
the one we are having right now, which
is more like I'm doing interviews with
experts to learn more about a space.
Where I'm not a deep expert
in, um, where I know a bunch of
stuff, but I haven't worked like.
I have, don't have years of experience
in, and this will be pretty similar,
like basically practical deep dives
onto a specific topic with experts.
And we will be covering a lot in MLOps,
like how to build MLOps platforms, what
tools to pick, how to do inference.
And we will be talking to a bunch
of different people from different
companies, like modal, pattern.
And a bunch of people you likely
know and at the same time, I will be
starting a slightly different episode,
um, which is in, like, mostly my area
of expertise, which is generative AI.
Um, and I will mostly be talking
with people I know who put it into
production and who know their shit
around generative AI, because I think
there is so much noise in a space.
And.
And we will be covering like a lot, but
it will be a little bit less structured.
So the interviews will be a little bit
more vibe based and we will be just
chatting what we have seen work, what
we are building right now, things like
that, and also like current trends, which
are going on and our opinion on these.
Like I just recorded an episode with
Dexter from human layer on MCP and I
will be getting Viva from bumble on soon.
And we will be talking about
a bunch of different things.
What works, what doesn't.
And what is really behind the hype.
And how you can build better
solutions with generative AI.
Because I think like, that's where
most people are building at the moment.
Because that's where all the hype is.
So, subscribe, if you want
to catch the episodes.
Otherwise, I will catch you soon.
So see you probably in a few weeks.
Because I will be taking at
least two weeks time off.
See ya!
Listen to How AI Is Built using one of many popular podcasting apps or directories.