Hiring Review. Good and Bad decisions

Hiring Review. Good and Bad decisions

In Karumi, we have two fundamental principles that we always like to keep in mind. One is sharing our experience with the community, and the other is continuous improvement. Along with this blog post, we want to explain how we do our hiring process for a new Karumi member, how we approach it, what we have learned from previous cycles and what we need to improve for future hirings.

It all started four months ago. We decided to expand the team with one tech person more; the previous hiring was around two and a half years before. Adding a new member to the Karumi team is always a good idea because this introduces new ideas, and we need to review our tech knowledge bases and how we understand the code. The process was only our second open process because we always hired people who had worked with us in previous companies. In the last open process, most of the candidates were people recommended to us by friends.

One thing we learned from the last process is the complexity of writing a fair hiring offer because the candidates who apply are the result of the communication that you do. People are going to read the proposal and make a decision depending on the requirements that you set down. Something that it is not essential for you could be the inflexion point for someone applying to the offer. We like to be careful when writing the proposal to not discard any possible candidate.

We decided to create a small infographic to promote the offer, highlighting what interests us and what we offer. Written offers can be very long to read and do not always get across how important we consider the offer to be. We worked this idea with Ashler Design Studio; they understood what we needed quickly. Elena Ramirez did an excellent job, and soon we had something that we love. We also go into more details about the infographic on our webpage.

One thing we were clear about is that we didn’t want anyone to back away from the offer due to their job title or for any programming language issues. If there is one thing we have learned in both Karumi and previous companies, it is that job titles may not mean the same thing from one company to the next, and we know knowledge is more valuable than the time that you have spent in a company.  Of course, experience is something we look for, but sometimes a year in a company for a fast learner could be the equivalent of four years for another person who is working to maintain an old and unmodified codebase.  Another thing we learned is that knowledge cross-cuts into language, so we did not focus on the knowledge of a specific language and it was not evaluated during the hiring process. We are aware that knowing programming principles, architecture, testing or scalability is more important than knowing the Android API by heart or knowing how to make applications with node perfectly.

With that in mind we set about defining the selection process. Pedro was in charge of developing a code test based on what we do day-to-day. When he showed it to us I admit I had my doubts but it has proven to be a great code test because it allows us to evaluate how that person works and how aligned they are with our vision of what an engineer is. Also, in the code test description, we included a section called “Evaluation Criteria”; this contains all the things we are going to evaluate from the code test, and what is important to us which is something I recommend to all companies to include in their code tests. I think it is an exercise in transparency for the candidates and avoids misunderstandings. One of the doubts we had was if in giving those evaluation guidelines the tests were going to be similar, or that we were going to have room to manoeuver in the review. Evaluation Criteria has been the right decision, as we have found that even with the guidelines, there are people who don’t follow them, while others do perfect things with great care and attention to detail.

We redacted the offer, and first sent it to people working in HR in companies we have good relationships with who know what they are doing, for their feedback on wording, salary bands, description, and diversity. We wanted to know if we had missed anything important or if we needed to remove something from the offer.  Remember, to receive replies from people in accordance to your offer depends on how you communicate it.

When the offer was ready, before publishing it we sent it first to people who we would like to work with us to see if they were interested and we also passed it on to friends outside our direct area of influence to help us to spread the word. Karumi is a small company but well known within the world of mobile development and other small sectors. But one of the things we wanted was to be able to reach those groups of people who do not know us and thus be able to expand the spectrum of potential candidates. Thanks to this and the help of those friends we have managed to reach a lot of people who did not know us directly, improving the diversity in technologies and giving more quality to the company.

Those steps had completely unexpected repercussions for us; in four days, we received around one hundred CVs. We had to discard those from outside of Spain because with our company size it is complex to hire people from abroad. We reduced the number of applicants to 83 with 23% being female candidates which would have been unlikely without the help of our lady friends who reviewed the proposal and shared it on their networks. We also saw a high participation from people in technologies that are not within our knowledge area, especially people who have been developing in Javascript or C, in addition to people of all ages and many people who from the point of view of other companies would be considered ‘juniors’.

After a week, we had to close the CV application because it was going to be hard to review and manage more applications.

Hiring Review. Good and Bad decisions

Our basic idea has always been never to not reject people based on their CV. We like to let people prove their worth. With 83 candidates, this is not viable, and we needed to apply some filtering. We did it based on the Cover letters we had received, giving candidates who had sent a poor one, to be able to send a second, more complete version. It was not a huge filter either, but it served to filter out people who weren’t really interested in working with us or whose written skills didn’t match the level we were looking for. Karumi is a remote-working company, and good writing communication is something vital in our daily work.

The next step was the code test. We gave ten days to complete it, but we told them not to worry if they had to delay delivery, those ten days were approximate and would not be taken into account if they were late getting it to us. The time was really to set us a hiring deadline. But at that moment, one of our team got injured and had to stop working for a month, and other people were starting their summer holidays, with left only a few people available to review the code tests. Reviewing so many code tests took a long time, more than we expected, and we still needed to continue working on our daily tasks.

On the other hand, talking with the candidates, we detected the code test was taking longer than we expected. In the future, we will change this step. From our side, the revision takes a long while, and we need to keep in mind the candidate is using their free time to do the test for us, and we need to respect their time.

I would like to point out that we placed a lot of emphasis on people sending us the code test even if it was incomplete or if they did want to send it. In the worst-case scenario, the candidate received feedback about the test. Never be afraid to submit a code test, no one will ever think anything bad of you. You will get feedback or information about what that company is looking for, for future reference.

For people who passed the code test review, we conducted two interviews, a technique where we evaluated their knowledge of development, asking about testing, architecture, object-oriented programming, functional programming, backend principles, but always agnostic questions on language and using code testing as a basis for explanations or questions.

To finish the process, there was a behavioral interview. In that interview we evaluated the skills to work as a team, to talk to clients, how they estimate work and their communication skills. In addition, part of this interview was done in English, as several of our clients are from outside Spain. And part of the interview was via slack because being a remote team we are interested in assessing how those people communicate in written form. These interviews have been very important to us and is something we value highly. In the end, the day-to-day life of the company is knowing how to communicate with both colleagues and customers. Technical excellence must go hand in hand with social skills in a company. I think there is a lot of emphasis on the technical side but and not so much on this part. and we discover many candidates who do not train this area of knowledge. For example, candidates who don’t know how to handle conflict, or who directly say they have never experienced it, which is surprising in people who have been working for 4 or 5 years. But this is an extensive topic and one for a complete post.

In both interviews, we give time to the candidates to ask us questions and we answer them as transparently as possible. In the end, we need appreciate that the candidates make significant effort to join our company and this is a hard decision for them.

We received a lot of applications from candidates we could consider to be junior. They had good development knowledge, or they did an excellent code test. With this situation in mind, we decided to open a new offer for those candidates, with the idea of hiring someone who had good skills and attitude, but were missing  experience in day-to-day development or in knowledge of some specific concepts.

The biggest problem of the process has been time, I think it is a mistake on our part not to have managed it well. The whole process lasted about 2 and a half months, which I find disrespectful to the candidates. We have tried to communicate the state of the process from time to time, but it has clearly been insufficient, and I would like to apologize to all candidates. I know it’s very annoying to be in a process for so long. For the future we will try to stick to a stricter internal calendar, reduce the number of candidates in our review funnel interviews and have better communication with candidates.

Many thanks to everybody who took part in the process. From people who helped us to write the offer, people who wrote to us, candidates who have been part of the process and to the Karumi members who have been reviewing and doing the interviews. The level during the process was high, and the final decision was difficult, but we are sure that Bea and Elena are two excellent developers, good people and I am happy they are part of our team.

We would like to thank everyone for their patience and effort.

Continue Reading Hiring Review. Good and Bad decisions

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

How to achieve an ​App with great design? The steps before a design system

If you are a software developer:

Have you ever felt that the design team does not hear you and it’s changing tiny stupid details every single day? How many times did you say that moving that button in your app is way harder than moving it in Sketch? How often do you find that there is only one mobile design not matter if the platform is iOS or Android?

If you are a designer:

Are you tired of hearing the engineers complaining about your work? Is familiar to you the feeling of having the techie team not considering your hard work? At a rate from 1 to 10, how creative are the excuses made up by the development team to avoid implementing the interactions you’ve designed?

Does not matter if you work designing software of developing it, although all those questions may look like an easy joke, designers and developers fighting each other, trying to convince the project responsible how wrong is the other team about almost everything.

What we’ve learned working in more than 25 projects without having our own design team?

Karumi is a small studio that provides software development consultancy, but we have no designers in-house, so usually when a company requires our services, there are two options, we have to work with that company’s design team or there is another company providing design services. In both cases, we all (developers and designers) have to adapt to work with each other for the project’ success.

On top of that you can add that every company has a different culture, size and, probably, time zone, so let’s review the list of things we’ve learned.

Feedback is vital.

Feedback let us control what to expect at any given moment, so let me paraphrase the famous quote of Move fast, break things to Communicate fast, share things, the more information you share, better decisions all the team can take. Do not fear to over-communicate, use Slack, Jira, email, whatever fits the team, but let everybody know what you are doing and what problems are you facing.

Delivery, delivery, delivery.

When we are helping a client with a mobile app, we like to share weekly betas so everybody interested can evaluate that week’s work and plan ahead. Doing this you will be able to gather tons of feedback on several fronts:

  • Is it working as expected?
  • Does the design fit every device out there?
  • Is the UX right?
  • Does the app feel sluggish?
  • Is it crashing?

Avoid beauty syndrome.

Karumi loves screenshot testing. Being able to ensure that the final user will experience what’s intended to is superb. And, we are using those tests to verify the design (not criticize which is a different thing) and we are doing that because most of the time, we find apps being designed for huge devices with a lot of room like the iPhone 8 Plus that usually are being used by Jonh Doe or Julia Smith but nobody uses Spanish names like Francisco Javier Fernandez Toro. So, we do tests for those corner cases where the design could not be defined and share that feedback with the design team.

Does not only affect names, it does affect placeholders, pictures, money amounts, addresses… in fact, every data that could depend on what the user introduces could be unexpected, so if the design is beautiful, apply the title of the famous western: “The good, the bad and the ugly.” (“The given design, the corner cases, the error”)

Better done than perfect.

We all know that we always have to pick two out of this list: Good – Fast – Cheap.
So, sometimes, although it’s not nice, it’s not your call, and you are not the one taking the decision, so based on the feedback you have (see? it’s essential) offer choices of want can you do in order to meet a point where product – design – engineering can work together.

That does not mean to find a place where everybody is partially comfortable, it’s applying what’s needed when needed, so, to be able to decide what to do: offer a ratio of cost-benefit and let the leader choose.

Be honest.

Physics laws cannot be changed, and space-time is one of those, so if something cannot be achieved in the expected time-frame, say it out loud, explain why, offer options and be constructive. In the worst case scenario, that would not change anything, but it could also lead to more realistic expectation.

Size matters.

Consider always the smallest and less performant device the user could use to experience your product. It’s easier to expand a design into a bigger screen than shrink it. Use your tests for that, especially think about scrolling.

Consider the most used devices out there, for instance based on data from deviceatlas.com, in Spain this 2019, half of the iOS devices are conformed by: iPhone 7, iPhone 6, iPhone 6S and iPhone SE.

So keeping those numbers in mind, in our last iOS project, we are doing screenshot testing for the iPhone SE, iPhone 8 and iPhone X.

Design systems.

As an engineer I can only say: pretty please!

Call it design systems, guidelines, stylesheets or whatever you like, but if we can define a set of visual components, colors, and fonts, and give meaning for each of those; the development will be a bit faster, and we could react to changes efficiently. You can find a more descriptive document in our collaboration guidelines, and here some extra information about design tokens.

To sum up.

There are many places where you can improve your app development process, but if you are able to implement these points in your next project we can ensure that the design and development teams interaction will be quite smooth and they will work as the were just one single team.

We’d like to thank our friend Daniel Mota (@icebeat) for all the feedback he shared with us, we thought it wouldn’t be fair to publish this blog post without having a designer sharing his thoughts and concerns about it.

Continue Reading How to achieve an ​App with great design? The steps before a design system

End of content

No more pages to load