At Aras™ Digital Products we do exactly what you’d expect from a successful app production studio ↘

It all depends on the client and the idea. Rest assured we can pivot between various industries and different kinds of projects. It all depends on the client and the idea.

We do many great things in digital. And while doing them, we like to stick to some superb practices we've mastered over the years. Check all of that below.

Discovery

Research

Market research

What customer needs are we fulfilling and what’s already out there? A time to understand the market, map out potential competitors and learn from existing ones.

Business perspective and requirements

It’s imperative to meet the stakeholders and listen to their needs: analyze provided documents, talk to the team in earnest and try to get the big picture.

Workshops

Stakeholder interviews

They talk and we listen. This is crucial.

Potential client interviews

Out of market research findings and stakeholder interviews we create a set of questions that need answering. This needs to be done gently, participants must be able to speak their mind without giving out answers they think we might like.

Public surveys

When you need this kind of data, there is only one way to go. Surveys are necessary in order to validate ideas before developing anything.

Straightforward, collaborative design workshops

Sometimes just talking things through doesn’t cut it. Asking the right questions and providing visual stimuli will prevent superficial thinking. For simple exercises such as feature prioritization or visual design preferences we mostly use a super cool collaboration board FigJam by Figma.

Design thinking

With its five phases – empathize, define, ideate, prototype and test, design thinking is just about the perfect UX design method. A true foundation of UX design. It helps us understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test. There is no time frame here as it could last anywhere from a week to several months. We adjust this method in order to fit our client's needs and budget.

Design sprint

While design thinking is more suitable for answering broader, not-so-well-defined questions, design sprint is all about developing and testing specific ideas. A rapid, five-day process that includes research, design, prototyping and testing, it saves a ton of time and money.

Data analysis

User behavior (when client already has a live product)

People access, browse and interact with your product in various ways, and we want to know how they do it. This helps us map out any pain points but also identify happy paths. We don’t want to change parts of the project that perform.

Personas

Fictional characters that help us better understand user needs. They’re easier to empathize with once we give them faces and names. Each persona represents a type of user that will potentially interact with our product. Like Tesla, we believe 3 to be a balanced number; one neutral persona in the middle surrounded by a positive and a negative on each side. Yes, 3 personas should cover all your user types.

Problem detection

Problems can be detected in the actual product (if live) or in the client’s vision. Sometimes the stakeholders’ vision doesn’t match the users’ needs and without the users - there is no product. Sounds complicated but it’s actually pretty straightforward.

Hypothesis

Once we gather enough information, we will form a conclusion. Since this conclusion is not validated until developed and in use, we call it a hypothesis. Defining hypotheses is the goal of the discovery phase and lays groundwork of our future product – idea(s) upon which the product will be built.

Planing

Scope

Alright! With our research all wrapped up, we have a pretty clear picture of what needs to be done in order to build the product. It is time to align that with the client's budget. Sometimes we build full featured products, and then there are times we bow down to versioning. That means we’ll start with a limited set of features in a fully functioning product.

Team members involved

Experts from different fields work on different timetables which sometimes overlap. We have to make sure each person is booked and briefed for a proper time slot. There’s always a bit of juggling and it always works out.

Product Design

User Journeys

User journeys are paths users may take on their way to reaching their goal in an app or a website. Needless to say that the quicker and easier these paths are, the better our product. There are countless options but some paths are better than others. We are good at detecting these.

UX

Designing a digital product at a structural level is called Wireframing. A wireframe takes into account user needs and user journeys and is commonly used to layout content and functionality of a page. Before any visual design or content is applied, we must use wireframes in order to establish basic structure of a page.

Lo-Fi Prototypes

We need a way to translate high-level design concepts into tangible and testable artifacts. Enter lo-fi prototyping. It is used to check and test functionality rather than the visual appearance of the product. Commonly it focuses on a particular piece of functionality and not on overall app experience.

Moderated User Testing

A human operator facilitates a test and guides the participant, providing support and answering questions if the subject encounters challenges while completing tasks within the study. This is the kind of testing mostly used for lo-fi prototypes in an attempt of avoiding any ambiguities.

User Experience Design

Information Architecture

We map out crucial information that needs to be included into the product. That gives us a blueprint of the design structure to be aggregated into wireframes and sitemaps of the project.

Hi-Fi Prototypes

Coming soon

Sitemap

The result of our efforts is a UX sitemap - a hierarchical diagram of a website or an application where everything is neatly prioritized, linked, and labeled.

Text content (Copy)

Imagine we did everything right and blew it with wrong content. Communication needs to be smart, inviting and clean as a whistle in order to properly navigate users around the app. A little bit of fun doesn't hurt either. Too many apps and sites today sound as if it were the government who’s speaking. You don't want to do that.

User Interface Design

Research & Inspiration

It is important to keep up with trends and make sure a design won’t get outdated any time soon. Each industry has its own design specifics and users invariably and subconsciously expect us to follow these. With so many industries in the mix, self improvement needs to be constant. Unless you know what else is out there, how are you going to beat it?

Look & Feel Exploration

Exploring different UI design directions helps us feel out the ones that vibe better than the rest. The more design sketches you do, the more ideas you’ll get. Look & feel phase is really all about creativity and it is important not to confine that process by anything but the time frame.

Design system

Now this is the holy scripture of UI design, your source of ultimate truth. Design system ensures consistency on all screens, enables fast application of changes and improvements throughout the design and in all honesty, makes life easier for you and your current and future designers and developers.

Applying visual style on all screens

Did you know there can be up to twenty different states of a single input field? Yes, this is the part phase we have to cover them all.

Handoff

This is the point where designers meet developers. Designers have to make sure developers are familiar and comfortable with the design tool of choice (this was way trickier prior to Figma), that the file hierarchy makes sense, the design system is set up right with all styles covered and component usage is shared across the board, all followed by up-to-date docs. Communication between these two groups will remain open throughout the development phase.

Backend Development

Architecture

One of the core questions for the application. Get this one wrong and any later changes will come at a steep price. Depending on the project's specification we determine whether to use a monolithic or a microservice approach when drawing out the app’s architecture.

Language and framework

Choosing the right language and framework depends on project specification and its size. Selected technologies need to have a strong foothold and ample support in the industry.

Choosing the right database technology

Depending on the type of data that will be stored we determine which kind of database or sometimes how many databases should be used for a project.

Design patterns for common problems

Design patterns are determined by requirements of the code that needs to be written. In software engineering, design patterns are common solutions for common problems, meaning that correct choice of pattern will produce safer and more efficient code. On top of that, any programmer that joins the project at some point in the future should easily integrate new logic into a well known pattern.

Designing the database and writing APIs

Depending on requirements and database technology of choice, we create abstract models for every data model we have in the application. Once our database is up and running we can open communication with the client, based on an API specification in which users with correct permissions can create, read, update or delete any entry in the database. There you go.

Logging

Any running application is destined to produce various errors and strange behavior. This is usually triggered by the user's (or tester’s) interaction with the backend of the app. In order to produce solutions for these issues, we absolutely, positively, must have insight into events that took place before our error occurred. Having propper logging as part of the application significantly reduces time cost for any issue resolvement. And it saves the world. And our sanity.

App deployment

Once developed the application needs to be pushed to production. In order to do this, the app is uploaded to a server and deployment scripts are written. It will now be easy-peasy to push new features and fixes from future versions of the application.

iOS / Android Development

Native development for the Apple ecosystem

Apple keeps on releasing new stuff all the time, and our iOS team loves to try out every new piece of tech or equipment as soon as it becomes available. Our most used stack - XCode, Swift, UIKit, RxSwift and MVVM architecture, but this is slowly pivoting toward SwiftUI and Combine.

Native development for the Android ecosystem

Google is working on making the Android OS a safer environment right as we speak, and we are constantly doing our best to keep up with the latest trends this platform has to offer. In our day-to-day development we use Android Studio, Kotlin, RxJava and/or Kotlin Coroutines coupled together using MVVM architecture. Lately we've been playing with Jetpack Compose, as it's the new thing Google wants everyone to use when creating a user interface.

Cross-platform development using Kotlin Multiplatform Mobile

Although we’ve played with Flutter & React Native, our cross platform experience is focused on KMM as it has given us best results so far. While certain projects are not the right fit for cross platform development, others can benefit from it massively.

Continuous Integration & Continuous Delivery

CI/CD processes are very useful in all our development phases and we’ve many tools in the past: Azure, Jenkins, Travis, TeamCity, Bitrise, just to name a few. Continuous Integration will warn us of any failing tests, code style misalignments and it makes sure only fully tested code is merged with the rest. Continuous delivery is responsible for automating new build delivery to everyone: QAs, clients and end users.

Front-end Web Development

Infrastructure setup

Every frontend application needs a server to run on. Setting up build files on a server, configuring pipelines and writing deployment scripts are necessary steps in order to make the project easy to work on.

Project setup and initial structure

With every project there are design patterns one should follow. This means that all future developers who join the project can easily find their bearings and start developing.

Writing code

Once a project has a repository, is on the server and the initial structure is set up, we can start developing. Code writing is done according to specifications, structured into tasks in the planning phase. Code needs to be written cleanly, has to be maintainable and easy to understand by following key principles, rules and concepts.

Writing frontend code can be separated into few segments

  • Writing components
  • Designing state management
  • Writing actions and connecting server requests with state management
  • Connecting actions with components

Wordpress Development

HTML/CSS

Coding a 100% accurate replica HTML theme from finished design. This includes responsiveness on all screen sizes, great performance, and simple, lightweight code prepared for search engine optimization.

Wordpress development

We offer all Wordpress services imaginable - Wordpress theme development (either from a delivered or custom coded HTML theme), WooCommerce development, page speed optimization, API integrations, Wordpress theme installations and setup.

Staging

Throughout the development process, you’ll always be up to date. While we create your future web solution, you will continuously have access to it through our staging environment.

Plugin implementation and development

We have ample experience with many of the top-notch plugins used in Wordpress development. If your website needs multilanguage, SEO improvements or anything else, we know what to use (and what to avoid like the plague). Also, we are here if you need custom plugin development.

Quality Assurance

Product and design implementation check

We don’t like to bother developers in their process. Not a lot, at least. But it is important to keep up with the progress and solve implementation bugs along the way. Costs less in the end.

Quality assurance

Quality assurance spans through both our QA and dev teams. First checkpoint -mutual dev peer review. Team members look at each other's code and make sure there are no technical errors and all obvious user flows work as advertised. Then our QA team steps in and thoroughly tests every user flow conceivable in an attempt to prevent future users from taking the app into an unwanted state. Finally, we make sure implemented functionality is aligned with our client's needs and what users would want. This also includes non-functional requirements like app performance, overall stability and backwards-compatibility.

Delivery

Product

It is (a)live! You can find it in the Apple store / Google Play / World Wide Web

Last versions of design files

We hand over copies of the original up-to-date design files to the client, hopeful they’ll handle them with care. We keep the originals safe in case they don’t.

Store assets (mobile apps)

Anything from app icons to screenshots of app usage. We make sure to comply with guidelines and fulfill all platform’s requests.

Wordpress website publish

Preparing the domain and the server and uploading the finalized Wordpress website onto it.

Client onboarding

Educating clients on how to use the Wordpress CMS

Web app launch

Once an application is fully developed and tested, the developer runs production scripts. These build minified compiled javascript files and other copied assets (like images, fonts etc.) and put them into the build folder. From there those files are copied, manually or via a pipeline, onto a server from which they are finally accessible to the web

App Store / Google Play deployment

We take care of new app creations, certificate handling and Apple and Google review resolutions. Need to make sure our apps reach the end users smoothly.