Designing Before Developing

header Image Credit: Filament Games

So you've got a great new idea for an app? Want to jump right in and start building it so you can get it into friend's or customer's hands as quickly as possible? Hold off just a little longer and get your thoughts all straightened out. You'll be better off in the end!

The first step for Luke and I is always to get a design nailed down when we start thinking through a new project. After all - if it doesn't work right, look nice or flow intuitively, no one is going to want to use it. Putting together design documentation is a great way to think through these issues and arrive at a product you can actually build.

As your building your own design documentation, remember that it isn't just documentation for the UI/UX of the app!

How is it going to work?

Thinking through structure and feasibility of your project is the first place you want to start at and arguably the most important.

For Android apps, structure is pretty easy since a lot of decisions are already made for you - just stick to Java, Kotlin and SQLite and you can't go wrong (although you can always think about integrating tools like the new Android architecture components, Dagger, Robolectric and RxJava).

Decisions like which framework you want to use and how API endpoints are structured are things that will follow you throughout the lifespan of the project!

For a project that also involves a server component, this part of the planning is absolutely crucial. Decisions like which framework you want to use and how API endpoints are structured are things that will potentially follow you throughout the lifespan of the project, so take the time to really decide what you want! You can even go so far as to documenting which endpoints you want to make and what their request and response structure will look like.

pulse's server documentation

I'm a big proponent of both Ruby on Rails and Node.JS and would recommend any Android developer looking to get into server code to take a look at them. Firebase's new Cloud Functions are also a great option when you don't need as much flexibility as writing your own server, you can make API endpoints with them or just host a cloud database on their infrastructure.

However, this is a discussion for another time and another blog post!

Scalability is another thing you want to consider when thinking about structure for servers. When you're working with Firebase Cloud Functions or AWS Lambda, this isn't much of a concern as their infrastructure is already scalable and can accommodate as many users as you can throw at it. If you're writing your own server though, make sure you build for horizontal scalability because you never know how popular you're going to get.

pulse's database documentation

Database design is key in making your app fast and efficient, so spend some time creating a schema and documenting it. This means both on-device databases and databases in the cloud that store data for all of your users.

Lastly, it is important to document the feasibility of what you're trying to achieve. Take a look at other projects that are out there trying to do something similar to what you want or build a rough prototype app to experiment with APIs you're unfamiliar with. Sometimes this step can be the most difficult if you haven't worked on any similar projects in the past, but it can also be the most interesting if you are open to learning new things!

It's important to note that everything above can (and should) be done without writing any code that will be used for the project! Making a prototype to test feasibility is a great thing to do, but you should start fresh when you actually start writing your production code so that you can build with stability and testability in mind.

Focus on UI

sketch logo

UI is the first thing people generally think of when you talk about design. How does the user interface look? Are there fancy things you can do to make it better than competitors? Users will download your app more if your app looks nice!

We love using Sketch for UI design in our apps. It's the perfect tool for quickly putting together mockups that look great and are accurate to what your app will actually look like. If you've never checked it out before, I highly recommend it. I'm by no means an expert, but the learning curve is low and even when I haven't used it for a while I don't have any problem jumping in and building something.

pulse designs

When I was working on the initial design documentation for Pulse, I built the entire UI in Sketch and sent it to a few friends for feedback. This allowed me to quickly put all of the main screens together in basically no time (< 1 day) and get quick responses of what people thought of it.

When you're designing, focus on keeping it simple at first - you don't have to add fancy views to make your app pop. Use what the Android SDK and support libraries provide for you and build on top of that to make something cool. I see way too many apps that try and go overboard with their own designs and those are the first ones that I end up uninstalling because they don't feel like they fit with the rest of the apps I use. I'd encourage any developer to make the app unique in some way still so that users remember it, but, when in doubt, stick to the material design specs and you'll be safe.

Focus on keeping it simple at first!

Focus on UX

ui vs ux Image Credit: The Next Web

UX is something that a lot of people don't think about until later, if at all, when making a new app. This is how well your app fits together, how the features compliment each other, how easy it is to use, etc. All of that fits under the category of user experience.

It's normally around this point that I try and put together a list of every feature that I want to include for the initial release of my app. Then, I decide which are most important and rank them so that I can focus on the top of the list first. That ranking also serves as a way to direct users through your app: you want to have the top, most used features as accessible as possible and then can put lesser used features deeper down so that they don't distract from the main features and clutter the UI.

Once again, focusing on simple interactions at first is the best way to move forward. Stick to well established patterns and you can't go wrong!

I've seen design docs that are forty or fifty pages long and go over every aspect of a project. I've also seen some that are only a few pages long and don't include everything that I've listed above. How you want to write yours is completely up to you and what your project is (either way can be successful!), but the most important thing is to think through these points and make sure you make the right decisions early on. If you don't, it can be very expensive to fix mistakes or omissions once the product is built!

Anything you also like to make sure you've documented before starting a project? I'd love to hear about it, shout out in the comments or hit me up on Twitter @klinker41!