I started in 1996 as a webdesigner and I call myself a UI/UX designer.
In these +20 year I have done lots of thing.
I worked on many projects, probably more than I remember
But mainly on enterprise applications in many fields.
I’m going to give you a personal view on...
On Create, Read update and delete
Aka CRUD
I’ll talk about the importance of crud and its importance in regards to
the almighty…Enterprise Application
Enterprise Application
A couple of years ago I was hired as the sole designer in an engineering firm to design the application they were going to build.
There was however nothing.
No analysis,
No style guide
No corporate identity
No rules how to build applications
Each team just build something and then they were surprised that their applications were not “visually” aligned.
Imagine that no …
I had to design it all..
So wow, I could define everything. But I had to design something that was not defined.
I knew nothing. Just a vague idea. It was going to be a huge back-office.
Customers, subscriptions, pricing schemes, routing, timetables, payments,
whatever you could think about, it was going to be in there.
I did work for many years as sole designer in developers centered companies.
Had to find my way.
Need to become pragmatic.
NO BS
The only thing I knew, the common ground all enterprise applications have is CRUD.
In my opinion
CRUD is the base of every Enterprise Application.
There is no EA without lots of CRUD.
So what does CRUD do?
Crud is all about data.
Capturing data.
Manipulating data.
Now how do we actually manipulate data in an interface?
How do we get to DATA?
Anybody?
We search
We search
And to search we use a
FORM
a search form.
What is the result of a search ???
It’s a ….
LIST
And in general clicking a row in a list brings us to
…
anybody …
It brings us back to a FORM,
it could be a detail,
it could be to edit.
But probably a form with new data
So when we think about it. What do we need to build an EA?
FORMS and LISTS
Just F&L don’t make The Enterprise Application.
If an Enterprise A is just forms and list.
You just have that, a bunch of screens.
A glorified access database, a pumped-up EXCEL-sheet.
A bunch of fields with a SAVE button.
Then what is it?
Wikipedia describes an Enterprise A like this ...
It satisfies the needs of an organization ...
… rather than the needs of
the individual users ...
WOW
It goes without saying, but we, designers have the user in the center, it’s what we do…
We have a major conflict of interest here.
So as a designer we MUST work in close cooperation with the owners of the Enterprise A, the stakeholders, the project owners, the experts
We need to work with the BUSINESS
We need to work with the BUSINESS
I cannot emphasize enough on the importance of having a good relationship with the business experts.
They know the enterprise...
...and it’s imperative that you get a helicopter view of the business if you want to create a great UX for the EA
An Enterprise is above all a complex system.
We build models to capture complexity.
The model is needed to capture the mechanics that the software needs to replicate.
Any enterprise that builds an application to cover their business will have a model in one form or another. The bigger the enterprise the bigger the model.
The model goes by many names, but I’ll use one I encountered many times …
It’s the BOM
The business Object model
Your job is to build screens based on the input of the business and the bom.
The model will give you an idea of the maturity of the enterprise.
A bad model, will give to much room for interpretation.
The more mature the model, the easier your job is. A mature model will give common ground, a common language between the business and you.
The model will give you the foundation you need to get that helicopter view.
Who has never seen this kind of drawings?
Who has?
What name does your company give these models?
…..
You need to learn to read these models
Read the model will give you clues on the amount of screens that are needed.
It will give you the FORMS LISTS and how the connect
It is the blueprint of the of the Enterprise application
You’ll find the FORMS and their fields
Some relations between the objects will show the LISTS.
But more important, when the relations between the objects have a description, it will show you the glue between the screens.
How the screens connect to each other
Back to our Enterprise application
An EA is a bunch of Forms and lists
An EA is all about DATA
An EA is NOT sexy
You can even say that it’s boring
An EA is BORING
But hey boring isn’t bad
Actually
Boring makes an application predictable
Boring makes it consistent.
Boring is a good thing.
Making things consistent
Making things predictable
Is all about standardization
To make it boring you need to standardize
EVERYTHING.
The more you standardize, the easier it’s going to be for your user to find his/her way through the application, no matter what the application does.
How do I standize my applications,
I follow a set of rules.
First when setting up a screen representing data,
I Divide and conquer.
When showing data there are only 3 important thing:
Structure
Structure
Structure
Structure your data visually and clearly.
Divide the data so it makes sense.
What belongs to what.
There are many ways to divide a screen in logical blocks.
I for one, loves to use Use basic typography rules to structure my data
I love whitespace. It makes a form breath.
Not everyone is a fan, especially the business.
All afraid of scrolling.
I need sometimes some persuasion to get them to love whitespace
So divide and conquer
Next there is “the context” of your data. Data is never alone.
So make sure you always put your data in its context.
Losing context confuses the user.
It makes the application more error prone.
So make sure you keep track of your context
An example.
This is a part of a client at the VDAB. Vlaamse dienst voor ….
The Flemish Public employment service
When going to the detail of a service
We keep the context. We still know who it is.
Context.
So make sure you keep track of your context
Where there’s Hierarchy in data there is also hierarchy in functions. The things we can do
on a screen.
Give context to the functionalities.
Add functions at the level where it makes sense.
Where it’s logical
Give context to the functionalities. Put it where it belongs.
An example.
Sheet of a client at the VDAB. Vlaamse dienst voor ….
The Flemish Public employment service
Many functionalities
Put functionalities in there proper context!
And then there’s another type of data that are very common
The MASTER-SLAVE screens
These MASTER SLAVE screens are very common in a Enterprise application
They group related data.
Watch out when handling these data sets.
Use the previous rules in this case.
It’s where everything comes together.
We have the Divide and conquer, group the sub-data visual
When going to detail of a “SLAVE”, make sure you still have context.
And Keep the functionalities where they belong
Don’t be a “jack of all trades”. Don’t edit it all at once
Split functionalities to their counterparts.
Like in this example
I used the divide and conquer
And kept the functionalities where they belong
This is what we have until now.
When using these rules your well on your way to build a nice boring application
But I have some more things
BUTTONS
The functionalities I showed until now were not really buttons, they are more navigation objects.
When I talk about buttons I refer to those items that persists data.
Remember CRUD,
Buttons are the elements behind the
create, update, delete of CRUD
With these buttons I use the rule
THERE CAN ONLY BE ONE
I’ll show you an example
I always define
The MAIN button
A secondary button
And a link button
There can only be one and only one main button
But there can be more secondary and link buttons
But never ever ever ever do this.
But never ever ever ever do this.
So buttons, but buttons and navigation have language
I’m not a linguist, far from it but I learned one and 2 things and as a UX designer you should
Be clear as clear as possible and...
Say what you do
And
Do what you say
Do this to not confuse your user
Be clear
In general when you say you are to do on another screen use a verb
When it’s persisting something use imperative
I must say that for English it is less of an issue, but in Dutch there is.
At the VDAB we tend to be sensitive for it
“Afwerken” - “Werk af”
“Wijzigen” - “wijzig”
Back to lists
Now this is a tricky one.
This will always create battles with business.
You need to stand your ground here,
they will always ask for more data in a list,
never for less
EXCEL is always behind the corner
But a list is a starting point and not an end point
Never ever ever do this
LISTS have to be as simple as possible.
So beware here, slim them down as much as possible.
There will be many battles.
The stronger your system is the better you can keep your ground.
Be firm
Be firm
But don’t be rigid,
Know when to yuild. You won’t win them all. Give them one or two battles ;-)
Now let’s finish with where I began, the company where I had to build everything.
The company was prodata and the project was mobiguider. The back-office for “de lijn”
I designed a full style guide describing every part of an application that was not there.
The style guide was more than 80 pages
Now more important than that, being afraid that nobody would read the document, let alone implement the way I wanted
I also build my own model language,
It was based on UML state machines
I called it a navigation model with every aspect of my style guide in there. Be it abstract
The model could be exported to XML and then with a small app I wrote it transformed the model in Balsamiq files
I left the company 4 years ago and I checked, they still use it
yeah
To finish of I want to end with what is for me most important
I always try to look at everything I do and ask myself