You can find the original article here.

2013 was an amazing year. The company took some serious steps to gear up for the future and the team was expanded with 4 new people in 2013. One key decision was to hire a full-time UI/UX designer. I joined the team in January 2013 and was asked to share some thoughts on mobile UI/UX.

Making an app is more than just a pretty design. Don’t get me wrong: visualization is important, but what’s even more important is the user experience. Mobile users are impatient, so the first glimpse is all you have. The competition is tough so here’s what we aim to accomplish at WebComrades

It all starts with a new project where we brainstorm with the full project team for max. an hour. Golden rule: don’t come unprepared to one of those meetings.

It’s important to benchmark and research before bringing your ideas to the table. For people who don’t know about “benchmarking”: it’s checking out the competitors, looking for best practices outside the domain or area and then forgetting whatever limit there is and start putting all these ideas and thoughts on paper or post-its. We try to find as much information related to the project as possible.

Next, we’ll make an inventory of the most important screens. What elements can not lack on the dashboard? Which other screens could also be important? As the designer of the company, I sketch or take notes of these elements. It doesn’t take a lot of time and instantly explains the concept we’re talking about.

After the brainstorming session, I start wireframing the different screens. Sometimes I just sketch different elements on a sheet of paper to see what fits best. Complex projects need a bit more attention and details. In that case I use my dot grid book where I can easily sketch a whole screen. That really depends on the project. Next, I turn to the computer and start digitalizing the wireframes. Whether I digitalize the wireframes or not depends on how much time I get (read: budget) or whether the internal or external client is expecting them. Not every project requires wireframes that look super slick, some rough wireframing might do the trick as well. We then discuss the UI and check if the user experience is at its best. So far the warm-up.

When the wireframes are done and we all agree, the designing part can start. Picking out the right color scheme is probably the most challenging part (at least for me it is). A client brandbook helps, but also makes it tougher sometimes. (New) Clients don’t always understand why we don’t want to follow their x-year old corporate brand identity in the app design. We are convinced that apps should have a natural feel and look beautiful. That also implies that we need to look at the design of the operating system and work out screens that fit nicely. Using a lot of color gradients, drop shadows and 3D on your iOS device just doesn’t feel right these days. Just making the logo bigger neither

Once the designs are finalized, they go to the client who can give his feedback or approve it. Obviously this is a learning process for both client and WebComrades as a team. We aim for the same thing as our client or even higher. We don’t just want another app in the store, but a successful app that scores on all areas: functionality, UI, UX, performance, simplicity, etc. Bad UX and you’re out. Bad programming and you’re gone too. Users will remove your app immediately when the feeling ain’t right. Game over.

Before the designs go to the developer, we have a specific meeting where we decide how the interactions will work. These are the detailed interactions between screens, for example animations which occur when a user clicks a button or a menu item. Because we mainly develop on iOS and Android, it’s important to make sure that they work identical or in a similar way for each platform. It’s usually better to discuss the interactions like flipping/swiping/scrolling/pinching/etc. in advance. The user interface concept is now complete and the developers can start doing their job.

It’s obvious that during the development sprints, some things can still change. Usually this means simplifying the app. We try to avoid getting tangled in the tiny details that could cause release bottlenecks and focus on the bigger picture. Still, all feedback is kept in a simple ticketing system so we don’t forget about these improvements. Some requests will still make the initial release, others are postponed to the follow-up release. In most cases there is no release without a follow-up release. Our apps are usually services, tiny problem solvers and/or business lead generators.

There’s a lot more to explain about the profound test phase, bug reporting, the app submission process, app store marketing and SEO, but that’s for next time.

Raquel Román Parrado
UI/UX Designer at WebComrades