Things I Have Learned From Developing An App, Part 1
This is the first in what I imagine will be a multi-part series. Because, you know, making stuff takes a while.
In my final post of first semester, “Learning to Take the ‘Me’ Out of My Design”, I briefly discussed a concept for a task management app that I developed as part of an assignment for my UX class. The resulting concept was called Dayful. It’s an app that I purposely did not develop for myself as a user, which made the creation process and final product all the more interesting. I was happy with what Dayful became and showed some of the wireframes to my significant other, an iOS engineer. He made an off-hand comment that maybe we should try to make it.
Fast forward to the end of my semester: I learn he was serious when he sets up a Slack channel, requests I make icons for the app in various sizes, and asks me for updated and annotated wireframes.
So, I guess we’re doing this.
Being Pixel-Perfect
When developing a concept for a class project last semester, I would make wireframes or animations to show features of the UI, flow, and functionality. The purpose was to show off the result of my process of design thinking and essentially, for proof of concept. I might test my prototype, but none of my comps have become anything truly functional — yet.
When you actually have to do the thing, though, you have to create things that will actually end up somewhere and have requirements. One of my first tasks was making an icon that looked good small, and even smaller than that, and then even smaller than that. Oh, and then blowing those four icons up x2 and x3. And having them be pixel perfect. No big deal, right?
Well, sure, except Illustrator can be kind of a jerk when it comes to exporting pixel-perfect assets. WHY did it keep adding a random pixel on to all of my artboards when they were exported? WHY?!? Scouring the internet found me a fix, but the problem would still randomly, and annoyingly, occur. This is not the most glamorous work. I JUST WANT TO MAKE ICONS, ILLUSTRATOR. Give me a break, would ya?
Having to Answer the HOWs and WHAT IFs
UXers do the research and talk to the people in an effort to make a beginning-to-end pleasant and effective experience for the user. We create the blueprint. Programmers are the builders. They make it all happen.
And part of that building is being good at asking questions. You might think that your wireframes are completely thought through and that your functionality and flow are set in stone, but then the builder comes and says, “Hey, what happens if this string says something like ‘Manchester-by-the-Sea’ instead of ‘Denver’?”
“What does this look like when this table is completely collapsed?”
“How does this look when you click this arrow out beyond the next month?”
“What if the user wants to do this one thing, what happens then?”
Ummmm, I haven’t thought about that…
Working with others to create something brings great benefits: others bring new ideas into the mix and allow you to expand your thinking. Most of the work I have done in school have been with other designers. Working with someone in a different discipline, however, pushes my thinking about my own work, but in a far different way. How do I want my app to work in every and any case? What about when my user does something I don’t expect? This has made me look at my designs in an entirely new and more analytical way.
Being a Coder’s Friend
My role in this project is not just as designer of an app, it’s being a designer for the code. My role is not only to make things look super fly. It’s to make things that are completely thought through, and precise, and buildable. The guy writing the Swift shouldn’t have to guess or run into unnecessary problems with layout. That’s my bag, after all.
As I mentioned above, this is hopefully the first in what will be a multi-part series on what I have learned from building an app. So, here’s to more learning in the new year.
