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.