4

The ioki Design Days

 3 years ago
source link: https://medium.com/@StefMa/the-ioki-design-days-580f040847b6
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Responses

Image for post
Image for post

As a mobile app developer or app designer, you may know the issue. Over the years, while both teams iterate over the app, you start noticing that the published app looks different than the designs. While the user experience is overall the same, there are mostly smaller differences. A text needs to be centered, an icon should be tinted to the main color, the font in dialogs is not the one you use everywhere else, the padding is not correct, and so on. Just to name a few of them.

We, at ioki, don’t ask why such smaller gaps happen. We just face that we have such issues. For whatever reasons. So we tried to find a solution to fix it.

In a scrum based team, the first and obvious solution is to create tickets to fix those things. And we even have such tickets in our backlog. But the problem with those is the priority. Our product owner wants features, we developers want a clean code base and our designers want a nice app. So at the end of the sprint planning, only one (even if) of those tickets made it to the sprint. That is not enough!

Another problem with this approach is that such tickets are super tiny. Changing the font in dialogs. Easy. Tint an icon. Done in 15 minutes (includes testing). Increasing padding. You really ask for an estimation?! Such tickets are going through grooming meetings and sprint plannings to finally reach the sprint. Not to forget that someone has to create the ticket. This is way too much overhead, I thought. So I came up with another solution.

The Design Day

The idea is to make the app nicer, one step after another. Each sprint we try to block a full day for one app developer and one designer. On that day they try to ignore all the noises around them and focus only on one thing:

Making the app prettier

Exchange an icon, change wording, tint a button, fix accessibility. All without having the overhead of creating a ticket, estimate it, plan it, and implement it. Which is in the end more time consuming than just fixing it.

Initially, we started in another format. Well, we basically haven’t had any format. We simply started the design days as “we want to fix UI differences”. But let it open to the participants what to do on those days. But it turned out early that we want to focus on smaller app implementation and design gaps.

While we all are happy with the output of the design days, we started to face another issue. The differences between our Android and iOS app. Obviously the app should have the same look and feel on each platform according to their best practices. But nevertheless, it makes sense to make the apps as similar as possible. There is no back button on Android, but on iOS. On iOS the imprint will be open in Safari while we use an in-app-browser on Android. Things like this.

To align both platforms we adjusted the design day slightly. Each second week we meet in a group of three people. One developer from each platform and one designer. Together they go through both apps and look where the differences are and on which platform we want to fix it.

Conclusion

We started the process in the middle of September 2020 and running it since then more or less on a regular basis.

The feedback we received from all teams who are involved are stunning. All are very happy with it and the teams present each review a few UI adjustments.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK