Regardless of what language or tool you use to develop mobile apps, there is always a constant that can’t be ignored — the client, whether it’s a direct client, agency, or a stakeholder within a bigger organisation.
Most clients who I work with don’t care much about the technologies that I use. They rarely know about the differences among specific development platforms and frameworks. They just want an app that meets specific requirements.
Of course, some clients have specific requirements for how they want an app to be built, but most of the time, they’re focused on the basics. They want a native app, for example, or they definitely don’t want a web or hybrid app.
Understand the Problem—Without Creating New Problems
Imagine a friend calls you into a room and says they want to hang a picture on a wall:
What goes through your mind?
Do you check the back of the picture to see how it’s hung, measure its weight, or check the wall to see if it’ll take nails?
Do you try a small nail in the wall? Maybe it breaks because the wall is too hard, so you suggest drilling a hole to fit a better, stronger mount?
Before you start drilling, do you check the wall for any electrical cables or other things that could be damaged or interfere with a nail?
Do you check with your friend multiple times about the exact position? Because once the picture is hung, there will be a hole, and it’s not a simple job to move it.
By this point, you’ve gone through an extensive process — from the initial problem (“I need to hang a picture”) to considering facts about the wall, obstructions, wiring, drilling and possible re-positioning and repairs.
But, did you consider any other alternatives? What about an adhesive-based solution? “Command Strips” are a common product here in the U.K.—that can be stuck to a wall and removed without damaging it. They can do the same job in a fraction of the time with minimal risk.
We’ve all been there. You can get bogged down with tunnel vision trying to make a particular, popular solution work.
Several years ago, a client who hired me to build a website requested a pop-up on the homepage.
“Why?” I asked.
Client: “Because we need it.”
Client: “We’re not getting enough people signing up for our newsletter.”
Me: “So, the problem is you’re not getting people signing up. Why is that?”
Client: “They can’t see the sign-up form, so we need to pop-up to show it.”
Me: “Why can’t they see the sign-up form?”
Client: “It’s below the screen, so they have to scroll to see it.”
Me: “So, what if we move the newsletter signup higher on the page and centralize it in the middle of the screen? That might solve the problem.”
Client: “Oh, yeah that could work, let’s try that.”
Once we understood the actual problem, we solved it an easier way that provided a better user experience, rather than using a hammer and nail.
Understand the Requirements
The first thing to establish when tackling a new project are the requirements. It’s important to talk through exactly what the clients needs—and why.
Budget is an obvious first question. There’s nothing worse than spending time on meetings and calls, only to find out that the budget is unrealistic.
I find Google Docs to be an invaluable tool at this stage. I create a doc with my understanding of the requirements as discussed with the client, then share it with them for review. I like this method, because it allows me to highlight sections and add comments/questions. Clients can reply or add their own comments in the doc. It’s a great way to clarify the project requirements.
From there, we can update the document to establish a simple set of requirements, goals and outcomes for the project. We can add issues and risks, any dependencies on third-party libraries or services, and establish a basic plan and schedule.
A key part of this initial piece of work is to fully understand the requirements and what that means in terms of how I will go about developing the project. I ask myself several questions, including: can I deliver the project using the standard Titanium API, or do I need additional modules or third party libraries? Are the modules and libraries I will need to use up-to-date? Will they do the job I need them to do?
Nothing is worse than accepting a project because you did a quick Google search for a module and found one, only to find in the middle of the project the module isn’t up-to-date and doesn’t have the necessary methods and properties.
This is a *really* important part of the process, since it reduces the risks associated with future issues.
A few years ago, we worked on a WhatsApp app (Android and iOS) for a client, which had features like chats, photos, videos, location updates and contacts. During development, we hit a problem. Photos were fine, but videos recorded on an iPhone couldn’t play on Android. This could have been a big showstopper, and we should have spotted the issue from the start. Luckily, it was solvable via a native module to convert the videos to a format that Android could view, and it only took a couple of days and was within budget. Needless to say, I learned a very valuable lesson!
Educating Clients on UI Differences Between iOS and Android
One key issue that can come up — especially if a client is providing wireframes or designs — is ensuring that the client understands the differences between operating systems. Too often, I see designs come through for iPhone and nothing for Android, assuming that the designs are interchangeable.
This is OK in some cases, but where you have large UI differences between platforms, it can create real issues later during the development process.
For example, Tab Groups display tabs on the bottom on iOS and top on Android — that’s the default experience with the `TabGroup` element. That can be changed to use native Android components to display a navigation bar at the bottom, or you could write a custom tab group for Android to emulate the iOS feature. I find in these situations that performance is never as good as a native, built-in component, and it can cause the app to feel sluggish.
So, when there are differences, it’s worth analyzing the operating systems’ different UI patterns to achieve the result and strive to use *native* components to achieve a fluid experience. The solution could be having a Tab Group on iOS, and a slide menu on Android, or it could involve using a native Android component to provide a tabbed interface.
Pickers, lists, and even buttons and fields can look different between operating systems. While you can do styling and adapt them to look different, it’s always best to keep as close to native as possible to achieve the best look and performance.
I once had to implement a user interface with a ruler-style slider to pick weight and height. A designer had sent over the screen designs, so I went with it. Plus, I quite liked it and thought it would be cool. After implementing a widget that worked, I was happy with the solution, but realized that it wasn’t ideal. Initialization was sluggish, and the performance wasn’t great. What made it worse was that one screen had two such controls — double the trouble.
The client and I discussed the issue. When I said I’d had to create a custom control to do it, and the norm was to use a picker or similar, he simply said, “OK, let’s do that.” The result? Days of work wasted, because I didn’t discuss the issue upfront!
It’s very important to make sure the client knows any challenges with the user interface design from the start: any controls that should be changed, how things will look on each platform — and, more importantly, the reasons why.
Wireframe the Basic App Design
One thing I do now, even if a client has provided their own sketches or layouts, is to do a wireframe for the app navigation and a few screens. Why? To ensure it’s clear how the app will work.
I keep it simple, and use a service called proto.io, which lets you design interactive demo wireframes in a browser (there’s no no native iPad app yet, unfortunately). The tool allows developers to illustrate the navigation patterns for iOS and Android and ensure the client understands how key components will look, function, etc.
From there, it’s much easier to work through several screens and establish the patterns for forms, lists and detail views, among other details. Once some basic wireframes are agreed, it’s much easier to continue development knowing that you have a basic understanding with the client on how the app will look, how navigation will work, and basic structure.
I’ve found this to be a really useful way to manage expectations. When we start coding and deliver test builds for the client to install, there are no surprises or misunderstandings about how the app looks on iOS and Android.
More importantly, by ensuring we can deliver the functionality we’ve agreed, and making sure that up-to-date modules and libraries exist (and even testing them to ensure they work as expected), we make sure that we don’t have any nasty surprises during development!
So, how do you start projects? Do you wireframe or produce simple or detailed specification documents? What kind of documentation do you get from the client? Do you have clients who are very specific about what they need, even down to the tools being used?
Let us know in the comments below!