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.
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.
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.
They talk and we listen. This is crucial.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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 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.
It is (a)live! You can find it in the Apple store / Google Play / World Wide Web
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.
Anything from app icons to screenshots of app usage. We make sure to comply with guidelines and fulfill all platform’s requests.
Preparing the domain and the server and uploading the finalized Wordpress website onto it.
Educating clients on how to use the Wordpress CMS
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.