iOS UI/UX Design or App First?

[logicpro7]

Currently studying iOS Dev and UI/UX Design and wondered what to start first for my first project?

Design the UI first in Sketch? Then build the App after?

Which is the correct way?

Thanks.

 

[Dookieman]

If it's your first app, I would suggest getting the code down first then applying it to the UI. Once you get more comfortable with Xcode/Objective-C, it's common to sketch out your idea on paper or whiteboard so you can get a general layout of how the app will work. What I mean sketching is not designing the UI, but how the app will function, and maybe major presentation decisions like UITableView or UICollectionView controllers to display your data. UI can change on a dime depending on your opinion at that moment or if you try something and it turns out to be a poor idea.

 

[1458279]

One trick I do is to setup a directory just for playing around. Because it's pretty easy to change things, you have less need to do an exact layout. All you have to do is save the project, change the name...

If the project is very large, then things change, but you should compare the advantage of a sketch vs using Xcode/IB to lay things out.

RAD (Rapid Application Development) is pretty advanced, moving buttons, grouping items, etc...

Add to this saving several copies so you can go in one direction then back up with a few clicks, it's pretty easy to handle most apps.

 

[firewood]

Design the UI first in Sketch? Then build the App after?

Which is the correct way?

Iterate, and plan on several iterations. One needs a base design to start, but learns what one can design by building apps, what's good/bad about the UI and design by trying them out, and then might update or completely change the design based on what one has learned. Rinse and repeat.

 

[Sean7512]

This past WWDC there was a great talk on prototyping called "Fake it until you make it." You should DEFINITELY watch that session, as it is very valuable.

I would go against writing any code just now until you get some real world feedback from your users and then continue iterating. Agile not Waterfall

 

[Pootan]

This past WWDC there was a great talk on prototyping called "Fake it until you make it." You should DEFINITELY watch that session, as it is very valuable.

I would go against writing any code just now until you get some real world feedback from your users and then continue iterating. Agile not Waterfall

I come from a visual design background so for my first app I ended up making the UI first, and implementing the functionality of the ui elements. Of course I had a rough idea of the app in mind, so it can be argued "the app was designed first". Then the code was implemented, and then iteratively cycled the process.

I think either is fine since in the end there will be multiple iterations before completion of the product, and "which started first" ends up not being a big deal.

 

[firewood]

I come from a visual design background so for my first app I ended up making the UI first...

I come from an engineering background, so I'll often just start coding first, throwing random interesting features together, with UI buttons(etc.) in random places. Then after getting this mess sort-of functional, figure by using it which UI goes with which, and what stuff in unused and thus unneeded. Then go and design (or have designed) a nicer looking UI, prioritizing the UI that was actually used when testing the app.

Then I add more cruft, and repeat the above. Until after the first few iterations, no use centering buttons, etc. because I know I'm going to throw the first few designs away. In fact, I often purposely start out with an extra ugly non-design, so that I'm not tempted to ship the app just because it started actually working.

 

[Dookieman]

I come from an engineering background, so I'll often just start coding first, throwing random interesting features together, with UI buttons(etc.) in random places. Then after getting this mess sort-of functional, figure by using it which UI goes with which, and what stuff in unused and thus unneeded. Then go and design (or have designed) a nicer looking UI, prioritizing the UI that was actually used when testing the app.

Then I add more cruft, and repeat the above. Until after the first few iterations, no use centering buttons, etc. because I know I'm going to throw the first few designs away. In fact, I often purposely start out with an extra ugly non-design, so that I'm not tempted to ship the app just because it started actually working.

This is how I dealt with it as well. Build something so it works, using a simple UI. Then add more functional things and build the UI around that. After a couple of months, scrap the current UI and change it to something more user friendly from other users input.

It's not to have the functionality working so the UI can be changed on dime.

 

[f77coder]

I'm doing the UX first. too many times the data drives the gui and its functional but that's it.

i prefer form over function, start with an intuitive and well designed UX then force the data to conform with xml/json etc