Hola, chicos. Mi nombre es Camile. Soy un diseñador de Kipu. ¿Crees que todos saben de Kipu?
No, ok. Kipu es un software de accounting clave que trabaja en los problemas del mercado de la modernidad.
Uno de ellos es automatizar procesos de accounting para empresas y procesos administrativos,
porque ellos rarely bring any value, they just time consuming and so on.
And another one is to help people get paid faster.
And I'm here to, well, in Kipu to help people solve their main problems like this.
So, designed to code, before we start, how many of us here is front-end developers today?
Ok. Ok. How many of us is designers? Ok. How many of us never use design software?
Ok. Right. So, even if you're not a professional designer and never use design software before and just coding,
you can still release products, apps that do the job and are well designed if you follow a simple process about to lay out for you.
So, I'm going to show you a quick process of how I think you should be doing it and how I do it day to day.
The side note here is it's not a complete UX process, so don't expect that.
I'm showing you how to do well structured and informed approach to design.
And just to make it clear, I will be referring to you and myself as us,
because we often face same problems and walk the same shoes in our day-to-day jobs.
So, some more questions. How many of you have their own projects?
How many of you are thinking to release some side projects?
Ok. Cool. Has the products released already?
Ok. So, as some of you know already, in today's development of apps,
it's more important than ever to deliver them fast and well designed in order to acquire users before someone else does.
Right? And in order to do that, we have to make sure we do the three key things right.
And they are. Oh, yes, right.
Number one is planning. We have to plan our design and I'm going to show you how in a minute.
Number two is design and of course to code them.
So, how do we plan our own projects?
And by the way, I'm talking from the perspective of how to plan it good for the incoming coding ahead.
So, our design to code process is relatively easy and enjoyable, in fact.
So, number one is the goal.
Goal is something that you have to define before you start any work.
So, for example, at Kippu, the goal of our app that I'm going to show you later
is to provide fast access to data and allow for quick processing of expenses.
And in context, the main goal of it is to, when people have like five,
three minutes on the train or idle time and they want to use their time effectively,
they can go to our app, do the snaps of their expense receipts and send it to Kippu
also with some help from some technologies and then they can just go and verify their expenses.
Right.
So, above the goal, as I already said, is to provide fast access to companies financial overview
and fast tracking of expenses.
So, we need to know the best, basic demographics, who these people are,
what context they are going to be using our app in, and their devices.
And, yeah, that's pretty much it.
Then, after with more planning, we have to do the flow chart which will give you,
will lay out all the steps of what your users have to go through in order to accomplish
whatever problem you solve with their goal.
And this will allow you to, you know, make some tweaks to the flow
and define better ways of doing it instead of, you know, just hard coding it.
By not doing this step, we expose ourselves to the danger of changing everything
when you actually code.
And the next thing comes from flow chart which will be functional definition.
And functional definition is a simple document.
I actually have some examples so I can show you.
So, going back to flow chart a bit.
Are you recording your screen right away?
Yes, I am.
No problem.
So, this is a simple flow chart.
I'm not sure if we can read it.
Yeah, the resolution is sort of bad.
So, those windows are basically screens.
This is some UI kit to the flow charts.
And those are screens.
For example, here we have a splash screen when people land on our app.
Our app has to verify if they are authenticated,
if they have to log in or they don't.
So, let's say, yes, success.
So, here we have a logical condition.
What happens in both cases?
In here we have success so we go on or we go to log in registration
and other flows of forget the password and so on.
After that, here is do I have information in my account?
Those are questions.
If I don't have it, then I show dashboard.
So, if I don't have it, I show dashboard with onboarding of creating,
how to create the first invoice, how to do this, how to do that.
It's guiding people to do what you want them to do
and what they want to do using your app and so on.
And then from dashboard we have a menu that we can access anytime on the left
or on the bottom, that's up to you.
The point is that you define your roots here and all the steps.
What happens now?
We have a button after that button while completing any action.
And then we have our functional definition,
which, for example,
I'll start from module.
Can everybody read it?
So, I like to have a division between view and module.
And what's the difference?
Module, as we can see here, is something that contains information.
In this case, we store information about the series of the ticket.
This income ticket, by the way.
So, the series number of it, the number of tickets in order.
Issue date, client, as you can see all these things.
Then what partial information we allow to show for it,
but since it's very simple we don't do partial views for that.
And then more important here is list information.
And that is what goes to views.
So, essentially a view is a view that shows you multiple modules.
It shows information from collected modules or just one.
The point is views do not store information.
And that's how I like to divide it.
But what's more important,
you always have to write purpose for your screen.
Why is it in your application?
And to do this, you will have to work a bit on your flows.
And also another step from it is routes and actions that you can take.
And they also come from your flow charts.
Why is this useful?
It's useful because when you go further down to the development of your apps,
you know what routes to establish.
You don't have to be personal knowledge base for everyone in the team.
You just share this document with them and they can go there
and see everything they need to know about the project.
And then the views.
So, as I said before, we have the view, which is income list.
Again, the purpose for it.
And then what full information we show on the list.
And by this, I mean only what's in the single list item,
which is, I think for this one, it was the series,
the number, the client, and the total amount.
And then actions and routes.
I can go back to menu.
I can do a quick preview of the item.
Or I can add the invoice or the ticket.
And you make sure you do it for every screen in your app.
No matter how many you have there.
Some patterns will just be repeated screen by screen.
But it's okay.
So that is planning.
I might be talking a little bit fast.
So if you have any questions, make sure you ask them.
You can ask them now.
Do you have any questions?
Any issues?
All clear?
Okay, fantastic.
Number two is a design.
Something a bit better than planning and coding.
Right.
Very important thing when it comes to design
is to use established patterns.
We don't have to try to reinvent wheels.
It's already been done.
So whatever problem you're facing,
and you're not sure which pattern to use,
whether it's a pattern can be a bottom navigation bar.
It can be a hamburger menu.
It can be a search on the same screen
without rewriting the page.
It can be searched on another page.
Those patterns are done.
And you only have to think about what context
I'm going to use this pattern in.
To do so, we go to point number two,
which is ux.stackexchange.com.
And if you're not sure about a good UX,
make sure you go there because these problems
that we will be facing in our design process
are answered right there.
So take a photo of it.
Number three, since it's not a real full UX process,
I would say do wireframes and rapid prototypes
before your real designs,
just in case we were wrong about our flows
and we can quickly pass it around
and just test our app with real people.
That allows us to do so
without wasting so much time on designing
and coding after all.
Number four, it is my favorite.
It's designed as you would code it.
Let me open that.
And by that, I mean...
Let's see if this will be visible here.
One second.
So design as you would code it means
use containers and wrappers in your designs.
Do you guys know sketch?
How many of you have Mac?
Ah, okay.
I'll be talking about sketch design.
How many of you have Photoshop to do designs?
Okay.
Illustrator?
Anyone?
Okay, yeah.
Adobe Suite.
Right.
I find sketch to be the best tool,
at least for my preferences
and for what I do every day.
And I'll show you a few simple reasons
why later on.
But going back to design as you would code it
is very simple.
Let's go to layouts.
This is one of our one screen of our app.
It's a list of your income invoices or tickets.
And it's designed with using 8 pixels grid.
Okay, let's go here.
Let's switch down.
Yeah, let's keep that grid.
What's important here,
I put all the elements in a wrapper
which has the exact dimension
it's going to have on the screen
and exact properties.
Next thing is,
I always put containers and wrappers
around icons to make them bigger,
like a clickable area.
And also, I'm always trying to use
some naming conventions for the items.
This is guide, so you won't see it here.
But I always name my files.
They should always be well-named
so that you and your colleagues,
when you collaborate,
know what it is.
And again, the screen title,
the background,
oh, I didn't name it,
and the shadow word.
So what it also means,
and I think it's better shown
in another piece of software,
which is this one.
Any of you guys know Zeppelin?
How many?
Oh, no many, okay.
So Zeppelin is a smart tool
that takes your sketch
or Photoshop designs
and gives you all the CSS,
most of CSS you will ever need
in order to code your products,
your websites or apps.
And it's really cool
when you see it like this,
because it always gives us dimensions.
And when you design it
as you would code it,
you always have...
Okay.
When you design as you would code it
on the screen,
with all the containers,
you already know,
you designed your divs,
you designed your containers
in your HTML.
And by doing it this way,
you make sure you don't have
to spend some more time thinking
about how will I lay out
the elements on the page.
The rest that's required of you
is to just put the CSS in.
Is that here, by the way?
Do I have to explain a bit more?
Any questions?
No?
Yes, first?
Do you decide the classes
like shape there?
Is it decided in sketch?
Right.
Can you reuse it in different components?
So, unfortunately,
it's not that smart
to give you the class names.
For now,
it's our job to...
when we code our components,
it's our job to use namings
and component structure
and make sure to paste
the correct CSS from Zeppelin
to the component files.
We cannot reuse...
Okay, some of the code
we can reuse,
and I'll show you later.
But not always.
And it usually comes down to
copying and pasting from here,
as opposed to calculating
and guessing the styles.
Does that answer your question?
Yeah, more or less.
I have to check how it's done.
Okay, yeah.
Feel free to come over later
and I can show you on my computer.
Yes?
So, it's giving the dimensions in pixels.
Well, I'm not an expert
on mobile development,
but I wonder if...
Would it be better to make it
relative dimensions?
So, it's more...
Yes.
Good question.
No, it doesn't give you
the relative dimensions.
At least not always.
If you want relative dimensions,
well, it does line height,
for example.
So, in here,
for example,
we have 40 pixels of line height.
And I code it this way
because I don't want
to apply extra paddings,
for example.
I design it this way, sorry.
Because when I code,
I don't want to apply extra paddings
to position it.
So, it's always line height.
But in this case,
it gives you the relative
to the base font size.
But dimensions are given in pixels.
But it's...
So, okay,
in mobile development,
we also have to use
relative dimensions.
It's not just fixed pixels.
This is for iPhone 6.
So, yeah,
I can play out things on the screen
with relative pixels.
But that's not a problem.
What's most important here
is that by using the 8 pixels grid...
Is that a limitation of sketch
or a limitation of the others?
Good question.
I actually don't know.
I think it's both
because it's hard to put relative dimensions
and make everything responsive
as you design, unfortunately.
But for website development,
responsive development,
this is also responsive
because it's for multiple devices.
But for website development,
we have to use grid systems.
We should.
And by knowing the number of columns
we have some element in,
we don't really need to use
the relative dimensions in many cases
because we have the width
by a percentage of the whole page.
And oftentimes,
it's up to us to code
other things in relative dimensions.
Answer a question.
It's for anything.
Well, it's for general UI design.
It can be web or mobile apps.
You had a question?
You can.
Good question.
To be honest,
I don't think Zeppelin
does any support for native apps.
Any more questions?
Okay.
So, next.
Anyone familiar with atomic design?
One, two people, three.
Okay, I'm going to just talk
quickly through it.
Atomic design is a design approach
that gives us really good principles.
To start your designs from atoms,
the smallest possible particles
of our design, of our UI elements.
To molecules that are formed
from multiple atoms.
Then to form organisms
with multiple molecules.
And then with multiple organisms,
we call it layouts.
So a page is essentially built
from multiple,
it's one layout built
of multiple organisms,
which are built of multiple molecules,
which are built of multiple molecules.
And I'm going to show you
what it means.
This is a simplified version
of atomic,
but for example,
font is an atom.
Here we have three different ones.
Color is another one.
Then we have shapes
and things like this.
And for example,
a button is a molecule.
It's a mixture of three molecules.
It's a shape of the button.
It's a text style on it.
And it's a color of it.
So that's a molecule.
To build a sign up form
for newsletter, for example,
to have put your email address here
and sign a button,
we have to use two molecules,
a sign up form,
the input field,
which has label,
which has input text style within,
and the container for it.
And then another molecule
will be our sign up button,
and this will form organism for us.
And more of them on the page
is a layout then.
For more information,
I encourage you to go to this link.
This one.
If you want to take a picture or something.
Why, again,
why is this important?
Because if at any point
we want to change something
in our designs,
we don't have to go on every screen.
And sketch works really well with symbols.
And symbols are reusable pieces of design
that you can just tweak and modify
from one place,
and they will be updated everywhere else.
I think in Photoshop
it's called LayerCom,
if I'm right.
Everyone noted the site?
Okay.
Where is it?
So,
for example,
here I have my list item for income.
And I have generic contact name,
which is a placeholder
for any list item
in the layout itself.
And let's go ahead
and change its...
Why do we know this one?
Let's change this one.
And in this one
we have another piece,
which is the container,
which is another atom.
It's hard for me to do
on different dimension screens like this.
And let's say we want to give this one
a background like this.
And this should allow us
to have it updated everywhere.
And this goes for text styles,
this goes for everything else.
So, that's why it's important
to design the molecules like this
because then you can apply
some principles in here.
For example,
what I've done,
and this is using 8 pixels grid,
I set up a set of rules
that this gap here,
for instance, is 16 pixels,
and this one is 8.
And we always have icon location here,
which is also another symbol
that I can update anytime from anywhere.
So, when you send your designs
or you call them yourself,
let's say we collaborate,
and I send my designs to other developers.
I don't have to go on every screen
and change something
because suddenly we have a shift
in focus in our project,
and I don't have to go and say,
okay, this is wrong,
I updated five screens for you,
please change it.
You can just go and export this one.
Come on.
Export this into Zeppelin,
I already did.
I'll show you how it's done later on.
Incomitant.
So, any change I make,
I just send this little element,
and that also allows me to give them
any special cases that we have
without necessity of doing another 550 screens.
Is that clear?
Do you have any questions?
Okay.
Yes, go ahead.
So, in my sketch files,
this is just a presentation one,
but in the work files
that we have here in Kupu,
and also why I love using sketch,
is because we have these pages
and pages contain artboards,
and I have my versioning setup right there
that allows me to track different versions.
Also, Zeppelin does
version control for your uploads there,
and we can change...
Actually, let me show you,
because I think I updated something there.
Yes, I just have one version,
but this is a version control,
and you can switch back at any time
and use the generated code from this one.
And then, how we manage,
I basically agree on version number 3 or 4,
or whichever version it is,
and go ahead with it.
The process is quite flexible,
if you do the atomic design,
and you're able to change many things
at any time in the process.
With one exception,
we do not change flows mid-project.
Everything else is quite flexible.
Is there a question?
Any more questions?
Okay, let's move on.
Now,
the third part of the presentation
is coding,
which I'm not going to be teaching you how to code,
because you guys are much better than me.
But I already mentioned Zeppelin here,
and I think in our process,
this was the single most
time-saving improvement that we implemented
into the workflow,
because we don't spend so much time
on our layouts.
Also, by designing as you would code it,
again,
we already designed our div structure,
in Zeppelin,
in Sketch,
we already have our tree structure
of the components of the project,
and we don't have to spend too much time on this.
So, for us here,
it's more important to prepare before we start coding,
in order to then translate our designs
much faster into code.
Right,
so any more questions about it?
Right,
I know we had some things about automation as well,
with the
announcement of the presentation,
and there's one important thing
why Sketch is good,
it's because it allows for many integrations,
and one of them,
which helps us the most
design,
is called
Kraft,
and it's also available for Photoshop.
Anyone heard of Kraft?
Two people?
Three? Okay.
So, in short,
Kraft is a little
swift plugin,
ah,
it's blue,
that allows me to get
dummy data from anywhere,
from external database,
or from some dummy source,
and how it works is just,
is very simple.
For example, I don't,
those names I didn't really
invent them.
Kraft did it for me, really.
So, I go here,
and I say I want some names,
male, female, both,
and I click on that,
and the names get updated.
If I want, I can do the same
with numbers and dates,
or custom element, for example.
Let's say,
ah, I have status,
let's change status.
Instead of the pending
due and paid status, let's say I want
to have,
I don't know,
three animals.
So, three animals,
and
Kat,
Giraffe,
Dog,
some more animals,
whale,
what else, cow?
We have five, I think it's enough.
We can preserve order,
or we don't have to,
without, because we want to
randomize our thing.
I want to click this one,
I get anything I want.
So, this allows us to go to any website,
get a list of countries,
some names, emails,
or even some more industry specific.
I was working with
mortgage brokers
in the United States,
and we had some specific terms
and specific values in our data tables.
And what I've done, I set up
all the custom sketch,
custom craft
data points,
and with just five clicks,
I've had a whole table of five columns
filled in with data without an effort.
And it's not only text,
it also goes for
pictures.
So, let's say
I want to go
and hide some parts
first letter.
I'm going to go ahead
and hide it.
Ok,
ok, let's just delete them.
And then we have the circles for
contacts. So, let's say I want to have
some nice profile pictures for these people.
We go here, we go to photos
and we have people.
That's it.
Well, it should be randomized.
I'm not sure why it's not.
Ok,
I think it's because it's an old version.
But yeah, it basically gives you photos.
You can do it one by one instead of going
to the website, getting it from Tumblr
and so on.
On my new version, it does it randomly.
I don't know why it doesn't now.
But you can do it with any picture.
And also what's cool,
you can just go to a browser, go to any page
and take content from a page as you design
in Sketch.
Or if you go hardcore, you can just do
JSON. You can just get your API
rolling into your designs.
Craft.
C-R-A-F-T.
Yes?
Yes, yes, it has multiple plugins like this.
No, no.
Craft is by InVision.
Do you guys know InVision?
Craft is by InVision and it's completely free.
No.
Sketch has 30 days trial
for free.
And why it's also good?
Because you only pay, I think, $99
or $129.
I can't remember exactly now.
But you pay once.
So,
yeah.
It has some advantages.
But it's only for Mac.
Unfortunately, yes.
No.
Why it's for Mac also?
It's because what you see here
they are all native
Mac OS X
components.
All UI of Sketch is based
on Mac native.
There's no custom UI to it.
It's so light and fast
because it's meant to be.
And I don't think there will be ever version for it
but I can't speak for the creators
of the program.
Yes?
Yes.
Do you know what?
You can ask me this question
about the alternative of the time.
There is one browser.
I just can't remember the name now.
There is one browser design tool
that almost like Sketch.
It does the same job
really well.
And it's also not slow
if you think about it.
It's quite fast as for a design tool
in the browser.
So, yeah, make sure you catch me later
and I'll, yes.
I'll have to Google that.
Do you have any more questions?
No?
Okay.
So,
time to code process.
I like to work this way.
And I encourage you to
today when you finish
when you finish the nice beers
we all have and some networking.
Go and do your flows
and make sure you plan your apps properly
before you start coding.
That will make it easier
and actually enjoyable.
I'm getting into development now
and without this I don't know if I will enjoy it so much.
Okay.
So, thanks very much for your time.
Yes, you have a question.
Yeah, how do you deal with,
say if you give a design to the developers
and they come back to you
and they say,
I guess this would maybe be at the flow stage
that this flow might not work
for technical reasons.
Yes.
It would be incredibly difficult for us
to implement it this way.
Good question.
This is something we work closely with
development team.
On this establishing of flows
there are all teams present.
It's not just me
doing some flowy things.
It's a whole team effort.
And we agree
on things that we know are possible
and frankly
the only difficulties we have
at the end is maybe we have
an animation that I went too crazy with.
And
they say, okay,
with the way our current app is structured
or with technologies we use
it's not possible to have it
with a performance we want to.
So then we find alternatives,
but it never happened that, oh,
we have a flow problem.
No.
Any more questions?
Sorry, no, you had something.
Slide.
Yes, I have slides.
Those slides.
They can be.
I can do it briefly after the presentation.
Yes.
Yeah, regarding that question.
I was thinking that sometimes I get a design
and it's a bit difficult
to adapt it to mobile
or whatever.
And I cannot be
all the time with the designer
to tell them don't do that
because it's very difficult.
Okay.
I suppose that
with time you get better
and you understand
what's difficult and what's not.
And maybe also by designing
with Sketch you already
design with atoms and
molecules and you already know that
some things are repeated
in different places.
But I don't know
how do you do that?
So your question is
when the designer is not understanding
if something will work or not
before he gives you designs.
Did I understand it correctly?
What I was wondering is
when you're designing
maybe you show the design
to the developers and they say
can you change that?
Oh yes, no, it's a conversational process.
It's not like
designer does a job
and then walks off.
It's constant working together.
So you show them
all the time
what you're doing?
Not all the time.
From time to time.
Yes.
A very important part is
to get your process sorted first
and get your
technological limitations
so that designer knows beforehand
what is useful.
That eliminates some of these problems.
Otherwise, as I said already,
it's a constant discussion
and constant communication
between us.
Usually it's on a daily basis
but it's not like
we have to sit next to each other
and talk.
Does that answer your question?
Go ahead.
Yeah, we do it before, yes.
Okay, good question.
It's not in here
because it wasn't a UX process
to validate your ideas
but when we have
DIY friends for real design
of course before we validate
the documentation
the flows and we think that it works
and those things
are important for me
y pensamos que funciona y haga algunas sketches,
incluso algunos prototypes de papel que dicen,
ok, tenemos una escena aquí, tenemos botones aquí y esto y esto y eso,
y podemos hablar con las personas, ¿es esto fácil o no?
¿Es limpio o algo?
Entonces, cuando llegamos a tener un diseño de wireframes,
usamos AXUR, ¿no hay AXUR prototyping tool?
Sí.
O Adobe XD, es un sketch.
Envisión o algo?
Sí.
Entonces, tenemos wireframes,
nos colocamos en un prototype,
o hacemos los wireframes en el prototyping tool ya.
Y yo, básicamente, construyo la toda la app en el prototype
antes de hacer nada más.
Yo lo llevo en mi teléfono también.
Hay algunos trick que puedes hacer,
tenerlo como una app, por ejemplo,
pero las redes sociales también funcionan.
Y eso es lo que hago,
hago entrevistas, invito a las personas,
recordo las escuelas, las voces,
y veo cómo las usan.
Les doy un task,
y les performo el task.
Y eso es lo que veo.
Hacía problemas antes de ir en el diseño.
Lo que pasa es que nos vuelve en el proceso,
porque algunas cosas fueron malas.
Así que es muy importante hacer un prototype antes.
¿Qué pregunta?
Sí, ¿qué?
¿Hacían recordaciones de escuelas para ellos?
¿Qué usan para ellos?
Sí, sí.
Yo estoy normalmente escribiendo una escritura
que dice...
Es básicamente una escritura.
Tiene el task,
todos los credentials que necesitas,
los detalles de task,
como el data,
lo que hay aquí,
lo que hay ahí,
organizaciones y cosas.
Y el escenario, básicamente,
el task es escrito en el brief,
y las personas no deberían hablar conmigo.
Yo solo les pregunté a hablar de la escritura,
como les performo el test,
y hablar de lo que piensan.
Por ejemplo,
tengo ese botón aquí,
no estoy seguro de lo que hace,
y voy a intentarlo aquí,
y, ok,
voy a clicar esto.
Oh, y sorpresa, por ejemplo.
Y sé qué no es muy bueno ahí.
Así que, sí,
les pregunté a hablar de la escritura,
y no les pregunté a las preguntas como van,
porque no voy a estar ahí,
cuando estaré usando la app, por supuesto.
Así que, sí,
les pregunté.
¿Algún más preguntas?
Ok, así que, sí,
gracias de nuevo por tu tiempo.
Espero que les ayuden con tu
desarrollo futuro,
y el diseño de tus apps.
Una cosa importante,
es que Kipo está grabando ahora mismo,
y si hay buenos desarrolladores
en la audiencia hoy,
y estoy seguro de que son,
puedes capturarme a la escritura,
o puedes enviarme,
enviarme en Twitter o LinkedIn,
y estaré en contacto con vosotros,
o, sí,
hablar conmigo y interrumpirme en detalles,
y enviarme tus series.
¡Gracias!