I work in mobile app development. We’ve been trying the “lean” approach to projects, where everyone is more involved from the beginning which is great ’cause everyone is clear on where we are in the project. There’s also not as much documentation, which can slow everyone down. You can read up on it here and here, they can explain it better than I can. In a previous life, we were doing what people like to call “Waterfall,” where each person does their part and then just hands it off to the next with little involvement on the process. There’s obvious problems to this when things at the end of the falls go haywire and you have swim back up stream like a dying salmon and start the whole life cycle over. Then a pesky bear comes along and eats you and where does that leave you?

What we’re doing isn’t a new idea:

” 3 or 4 of us in a locked room somewhere on Apple campus, with a lot of whiteboards, talking about what iMovie should be (and should not be). It was as pure as pure gets, in terms of building software. Steve would draw a quick vision on the whiteboard, we’d go work on it for a while, bring it back, find out the ways in which it sucked, and we’d iterate, again and again and again. That’s how it always went. Iteration. It’s the key to design, really. Just keep improving it until you have to ship it.” (via)

This Lean-ish organic approach is something that we’ve been trying out on our most recent projects. My experience with it is, there are no real strict guidelines. It’s alot of flying-by-the-seat-of-the-pants and oh-hey-this-feels-right. Every project the company has done, since we started this approach, developed varied techniques that worked for them. So it’s really really hard to define, but that’s sort of the point. You can’t define it and because it’s going to change on every project and team of people you work with, so it’s best not to.

The hardest part of working with less documentation is big enterprise clients are use to and need all of that documentation. There’s ways around it. Meeting with the client on a weekly basis and having a solid deliverable, is one. We walk them through all the new things we’ve done, the reasoning behind them, and the things we’ve fixed and updated from last we spoke. Sometimes there needs to be a document, but it’s just for the client, not the team.

So what I’m going to try to explain is the way I’ve been working with my team. It’s been working for us, maybe you can gleam parts that might work for you too. Maybe it’s nothing new to you and you’ve found other ways that are even better (High five to you! Wanna share something?). This is how my latest project has been going:

We work in small teams consisting of a Project Manager, UX/Strategist, UI Designer/Art Director, QA, and hopefully at least two-three Developers, one being a Team Lead. Developers are always the hardest to acquire.

The morning starts off with a quick 15 min meeting everyday. We meet at the whiteboard with all of our names on it. This is where everyone on the team tells the Project Manager what they’re working on, and if we need anything from each other. The Project Manager wipes off your To Do from yesterday if it’s finished, or it gets a star if it’s not. These stars not happy gold stars! Sometimes they turn into crazy amoeba beasts if its really bad (they are whiteboards after all). The idea of the stars is to help point out if something is taking too long, or if someone needs help. The Project Manager asks if there are any road blocks, makes a list for themselves to do, where we can all see. Then, BREAK! The day starts. Everyone knows exactly what they are focusing on for the day.

There’s a “Show & Tell” at the end of the week on Friday so everyone can see the finished product what everyone worked on that week, and if we need to make any revisions. This is to prep us and give us a day (or weekend) to make changes before a weekly client meeting on Tuesday.

We have a dedicated UX/Strategist who creates the wireframes, but we’re been trying to stay away from large spec documents, as they get out of date really quickly and just take too much time to make and update.

Now they tend to be on whiteboards or sketches on paper, some of which have been created as a result of brainstorms with me (Art Director/UI Designer) and a Developer, after the Strategist has come up with their direction. We each are looking out for things in our varied disciplines, with the user being the main focus. Then we snap photos with our phones and start implementing them.

I must point out that there is a whole process that the Strategist goes through before even starting the wireframes, but this is just to give you the gist of the workday.

I start mocking up the screens based on the whiteboarded drawings, the developer puts my comp with some working parts in the app, making a prototype of sorts until we get approval from the client and then we start building the actual screen fully out. I make necessary tweaks to the design, slice it up and then, hand it to the developer. Sometimes I sit with them and tell them which fonts to use, where to place things, etc. Sometimes I make a visual blueprint of all the same information. I prefer to sit next to them cause it takes too long to make a blueprint spec. It also gets out of date really fast as we go through MANY iterations.

I must also point out that there is a whole process that the Developers goes through besides just putting in my screenshots. There’s usually lots of complicated animations, API feeds and structure that they are also working on.

If the design is really complicated and we don’t have enough time to put it in the build before a client meeting, I place my comps in a frame of an iPad or iPhone in illustrator so the client can still picture it in the right context. We will usually will start the implementation of these sections by the next round so the client can see it live in the app. It’s very very important to show the client the work in the app because the device is always a factor. Also the animations/transitions really sell the design more than just the design on paper.

In between all these runs, QA starts doing rounds of user testing to get fresh eyes on the app and show weak areas so we can catch them early and fix them. This part is sometimes so excruciating! The team is waiting on the edge of their seat, biting fingernails. “Are they going to find it?” “Is THAT what they think it means?!” And when it works, the whole team cheers! When it doesn’t, more whiteboarding time. Asking the right questions is so key in this area as it’s really easy to lead the testers to the answer you’re looking for, rather than allowing them to explore and find.

There is a company wide review on everyone’s projects weekly (each project get bi-monthly attention) where we present our app to the founder of the company to review. We generally want to show him specific things, but he notices EVERYTHING. So he’s giving us his opinions, and we’re also getting opinions from other people not on the project. This helps us get not only fresh eyes, but maybe figure out a solution to a current design or development problem.

I’ve started thinking that the whole project is a prototype until we ship. I can’t afford to get myself too attached to specific elements, as there’s always ways to make it better. The main problem is knowing when to stop iterating so you can make sure all the features get implemented in time to ship. There’s always hoping for version 1.2 ;)

This way of working has made us faster. I’m not saying that you can “make a baby in one month with nine women,” as the popular saying around the office goes. BUT you can come up with ideas and bring it to the team faster without having documentation bloat. The designers and developers can start on the project sooner with the bonus of showing a working beta to the client earlier as well. Which in turn, allows the team to single out problems faster, before they become too large and too late in the game to fix.

(originally published on thoughtbrain)