In our overview of How to Build a Mobile App in 7 Days we explained our high-level process:
2) Architect
3) Build v0.8 and get client feedback
5) Deliver the final app and Celebrate!
This article discusses Step 2: Architect in detail.
The purpose of the Architecture step is to translate our very precise designs into a clear but technical language upon which our developers can more easily and quickly build an app. During this step we continue to make a lot of decisions. However, if we’ve done the design step well, most of the decisions will be technical in nature and very few will be about what users see or how they navigate from screen to screen.
The inputs into the Architecture Step are the decisions made from the Define & Design Step and the output will be a clear list of development tasks and a final architectural map.
The Define & Design step has produced wireframes, mockups, a “User-can” feature list, and a clear vision of what the client wants. At this stage we say goodbye to the client while we translate the precise vision that we have all agreed upon into the technical language of our development team.
We use a lot of different tools in this step of our 7 Day development process, but our most important tools are simple pen and paper. With wireframes in hand we start by drawing crude architectural maps and – for the first time – labeling things like views, view controllers, models and our data managers. We iterate on these drawings, making them higher and higher resolution until we have made the bulk of the technical decisions and have a clear idea of how we will actually build the client’s app. We turn any serious questions into technical tests so that we can get a quick answer. This is also the stage where, if necessary, we design and architect the back-end of our app.
(Source: MetaNeer Labs, Inc.)
Translate & Decide
Using interactive, pixel perfect, or wireframe mock-ups, the architect can translate all the design decisions into technical language for the development team.
Like the Define & Design step before, Architecture is an iterative process. With each pass comes a deeper level of understanding and a new opportunity to identify any problem-areas in a project. We believe that it is worth the extra 10% effort to get the Designs and Architecture right before we start writing code.
The iterations we do are on different sized pieces of paper. To kickstart the architecture process, we use a fat marker on a small sheet of paper to crudely capture the high-level architecture. Then we redraw the architecture again and again using smaller-tip markers and eventually fine-tip pens to capture more and more detail and precision.
Just like the Define & Designs steps, the Architecture also flips between visual representations of the app and written lists representing characteristics of each of the app’s components. This gives the architect two different viewpoints and forces them to express the specifications of the app in two very different forms – visual and written. By following our process we slowly and intentionally make more and more of the technical decisions:
- What are all the View Controllers? What are their names?
- Does this screen have one or two View Controllers?
- How does data move from here to there?
- Does this information get saved when the user dismissed the keyboard or only when they tap save?
- How much can we compress this photo before we upload it to the server?
- What are the basic data models for the app?
- What does the interface with the back-end server need to look like?
- etc..
Technical Tests
As we are iterating into more and more architectural detail we almost always encounter complex questions that we do not have answers to yet. As questions could mean that an important feature might not be possible, we then spin up a technical test to get a quick answer. These often mean building a very quick app that proves that we can perform a task a certain way. For example, we recently built an app where one kind of user can tip another kind of user for helping them with their knowledge of their local town. While we had implemented credit card transactions before, we’d never split proceeds between two parties before. So, we did a quick technical test. There is a considerable amount of value to be gained from well-defined and short technical tests that are not trying to build anything, but simply answer a question.
(Source: MetaNeer Labs, Inc.)
Back-end
Back-end design and architecture is it’s own art and science that we will focus on in more detail in another post. We’ve seen a lot of companies waste a lot of time and money building complex back-ends that do not satisfy the needs of their client websites, native apps, and SDKs. Keep it simple here and avoid having too many moving parts in a Minimum Viable Product. Use tools like Parse (a free Back-end as a Service) to help you rapidly and inexpensively iterate towards the right back-end for your app.
After we have iterated on the architecture a few times, performed the critical technical tests, and designed the information architecture of the back-end, we need to translate everything into actionable steps for the developers. We want our developers to make as few design and architectural decisions are possible. We want to be in dumb-brain mode. So each development task gets its own task in Asana (our project management software). More on smart-brain versus dumb-brain here. Usually we end up with 3-500 tasks for a project. This is also an iterative process. We go through the feature lists, the original drawings, the design maps, and the architecture maps several times to make sure we’ve captured as much as possible in our task management software.
We briefly set goals around when we want to deliver which must-have features and get everyone on the same page about priorities.
At this point we’re ready to set-up the Xcode project and begin development… but more on that next week.
Bottom Line: Every step in our process is iterative. Because of the speed at which we move, we have no choice but to spend spend the extra time and effort – up front – to try to identify and side-step all of the development pitfalls that we might fall into later and de-rail our project.
Developers, leave a note in the comments: how do you architect your apps?
Remember, this article is part of a series. Read the overview of How to Build a Mobile App in 7 Days and we’ll see you next week!