Product definition is a key part of the project and having everyone – the client, project managers, designers and engineers – on the same page remains the best way to move fast and deliver properly. To be efficient, in a nutshell. Our product definition methodology is mostly supported by human and live interactions, nevertheless some tools usually help the project team to share a vision and clear tougher parts of the project ahead.
Text 2 Mindmap helps us a lot while doing live sorting and ranking of the project features. In the same pattern, we use OmniGraffle to quickly mock up features blocks and do realtime interface zoning, prior to giving our interaction designers the lead to iterate on more detailed app storyboard.
Talking about design, we usually invite our clients to a design presentation, and since we’re all used to interactive screens, we usually build for them an animated prototype with Flinto. It helps – a lot – to visualize what the final product will be like.
In this post, we won’t talk about IDEs nor performance tools since you probably already know them. However, we’re used to building highly connected services, usually plugged into core business IT infrastructures. Therefore we have to pay a lot of attention when designing, prototyping, testing, and documenting network interactions. Since most of those are based on RESTFul web services, Apiary.io has been a very valuable tool for this job.
Another key part of an app project, often neglected, is testing. Since we are designing embedded software, we have to monitor and test behaviors in various contexts: low battery, incoming calls, bad network connectivity… and so on. For this purpose, Apple’s Network Link Conditioner and HTTP Scoop are useful tools to test and monitor apps and servers interactions. We also noticed that while these tools are great, they cannot prevent us from testing on a targeted pool of real devices. We usually select the market’s best sellers to provide an optimal experience to as many users as possible.
Last but not least, making private beta releases available is really beneficial while preparing an official launch. It’s also a convenient way to give a sneak peak of your product to opinion leaders. Beta versions also help you gather very useful feedback such as crash logs and qualitative and constructive evaluations by people outside the project team. Hockey app does fantastic job on this topic.
Designing mobile services put us at the crossroads of very different domains such as IT, design, marketing, sales and CRM. The people within each of those departments may have specific cultural backgrounds and sometimes not fully aligned objectives. Therefore, we, at Applidium, decide to put the stress on enforcing communication by selecting the right channel for the right purpose: no chatrooms, no archaeologic email threads and no megaphones.
To communicate with our clients, we rely on Basecamp and use OmniPlan to provide everyone with understandable schedules. We keep emails for formal internal communications, and use Adium for everything else. Communication between project managers and engineers is sanctuarized on a Redmine tracker. Furthermore, as we manipulate large assets, we share a global repository within the project team with all the project resources.
We hope these tips will help understand how we work at Applidium. We’re also very curious to learn from you, feel free to join the conversation on Twitter.Contact @Applidium