• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Practices & Products
  • Learning & Growth
  • Culture & Careers
  • Blog
  • Contact Us

best practices

Jan 24 2023

The Importance Of UX Implementation In Financial Institutions

No alt text provided for this image

Overview

As a UX Designer, one will experience a multitude of industries across their career. Two of the most historically challenging areas, across the board, to assert major design change have been Healthcare and Financial.

When approaching an expansive operational change pitch, its important to succinctly addresses the major pain points from a creative/UX view when working with corporate stakeholders that have a seemingly opposite set of skills and expertise (ex. math vs. art).

The challenge becomes: how do we shift traditional “path of least resistance” thinking to a mindset visualizing the importance of forward progress?

The following ten strategy points are key to informing a current and/or future financial services client of the progressive mindset behind updating their UX infrastructures:

1. View Design As A Methodology, Not a Package

No alt text provided for this image

Banks and financial institutions perceive design as a package while fintechs see design as a consumer-centered approach, but let’s call it what it is; a lack of understanding.

Design has been viewed by many clients as “paint” and not “structure,” and that is specifically why it’s so important to educate stakeholders on Design Thinking and Methodologies. It is so much more than making a logo, picking colors, and playing with fonts.

Design-based decision-making should not be led by Product Owners, Project Managers, Developers, Engineers, or even Stakeholders. They can provide unique perspectives, present opinions on research, provide reasonable requirements, all while engaging with in-depth data and applicable feedback. But the rest should be in the hands of the Designer. 

2. Increase The Scope Of UX Design Influence

No alt text provided for this image

UX experts are trained to be user-centric while curating and crafting experiences that ensure user satisfaction and delight. Thinking that “anyone can do this” is pure hubris. Yes, everyone can be creative. No, not everyone is good at it.

Hire the right talent and give them the freedom to explore.

Financial apps must be about ease-of-use and intuitiveness before tackling how pretty it looks or stuffing as many features in as possible. UX, as a design method, ensures that the user is fairly represented against the requirements of the need. Stakeholders typically have strong opinions on design, but they aren’t likely to be the ones using it everyday. It’s acceptable to push back, but you should have the research to support it.

3. Challenge The Banking Legacy

No alt text provided for this image

We should remember that it takes two – Product Owners and UX Leads should be solidified as the cornerstone of every good project from the very beginning. You need both of them to always be present: the client advocate and the user advocate.

Traditional corporations rely on structured hierarchy to get things done. However, inserting the pragmatism of Design allows for individual agency and decision-making to happen on a more detailed level and that is where the trust is needed. Your UX folks are smart. Let them do their thing.

The core takeaway is that UX people are needed before the project kicks off and should remain attached during the entire duration to capture data, extrapolate findings, align with visuals, and prepare to iterate on the next version. They help tie it all together. Let the User Experience team understand how users experience your product.

4. Switch From Fragmentation To Ecosystem

No alt text provided for this image

“Fintech”, as a label, is shifting to include any new products and/or brands that are promoting digital as the main primer for change within their organization and offerings. Banks are resistant to this type of change simply due to how their control of wealth is dependent on small static changes over long periods of time: Take money, sit on it, make interest, share dividends.

Fintech is breaking down walls that banks cannot adapt to, like cryptocurrency, DeFi, and other new concepts. Not all banks have invested in fintech, but all fintech have some form of banking service. 

Many traditional banks failed due to the inability to accept rapid evolutions as they typically desire stability and slow, predictable movement. That’s what happened in the mid-2000s when small banks couldn’t invest in online banking in a reasonable timeframe and/or provided a poor user experience. They “stayed the course” right into getting absorbed by larger entities to survive.

We know that embracing flexibility and new ideas can be risky, but a good risk assessment will show massive gains for a healthy investment in UX Research and Design.

5. Put UX Research First

No alt text provided for this image

Fintech excels in Product Design which culminates research and data into a cohesive and consistently built system from the very beginning of the brand’s inception.

Naturally, creating multiple services on one product can be hard. The FDIC says you need this, InfoSec says you need that, Engineering wants to save time and use a 3rd-party API/iFrame, and so on. We are challenged to be in compliance and have a beautiful application for users to intuitively engage with. But that’s the reason why it’s so important to invest in your UX teams!

Make sure that you have the data to support a unified system of products and services while maintaining a Design Language to keep everything looking and operating the same on every page for every user. Consistency matters!

6. Provide A Unique Value Proposition

No alt text provided for this image

Even if you’re “copycatting” products from other systems, your users are different and finding out what their needs are will increase engagement much more than assumptive design ever could. If you don’t know what people think of your product, you’ll never be able to pivot in the right direction. When they move, you move, just like that. There’s a big difference between qualitative and quantitative feedback.

Everyone wants to try to cram their entire product offering into a single app. It’s wonderful to have, but sometimes it’s just plain impossible to accomplish with the time and resources you’ve been given. We can’t always “make it fit” for everyone. The honest truth is that it won’t ever work for everyone and the individuality of your target demographics and focused segmentation should be the most valuable asset in your research arsenal.

Yes, you need a unique value prop, but only if it directly benefits your audience in a positive and engaging way. You want people to tell others about your product in a satisfied way. Bad reviews always lead to abandonment.

Take some time to compare what fintech and your direct competition is doing well and filter out how you can emulate those good ideas while staying on-brand and on-message. A good designer can help translate this information into a fully realized and custom experience.

7. Drop The Obsession With Banking Functionality

No alt text provided for this image

We should try to fit in as much functionality as possible, but not at the expense of the product or its users.

Every customer should have a journey that offers a simple “happy path” to completion. In finance, complexity can often be a source of pride and exclusivity. That may not be the case with all of your customers.

8. Measure Results By Quality, Not Quantity

No alt text provided for this image

Quality vs. Quantity is not a thing anymore. It’s instead the marrying of the two ideals of Quality and Quantity in a cohesive and engaging way.

The qualitative research that needs to be done should be exponentially impacted by the quantitative surveys and analytics gathered during initial research. For examples, we may lose quality when speed is priority, however this is why rapid user testing and prototyping is so important.

Test, review, rinse, repeat.

9. Focus On Emotions Instead Of Information

No alt text provided for this image

Empathy will always be key. People have emotional connections to their finances and the institutions they invest that buying power into. Banks tend to overwhelm people with unfamiliar paperwork, nomenclature, acronyms, and fine print.

The future of finance is making informed decisions based on simplified communication and customer loyalty. Keeping the complex curtains up will keep curious people away.

10. Invest More In Customer Experience Than In Marketing

No alt text provided for this image

The customers you have are worth more than the ones you lack. Marketing tends to focus on garnering new business while maintaining existing relationships are not as much of a priority. And that’s OK! But maintaining long financial relationships with contented customers far outweighs the risk of that unknown potential.

Let your product speak for itself through accessibility, effective UI, and an intuitive landscape. You want people to recommend your product to others. Curiosity and satisfaction go hand-in-hand; if you’re interested in something, would you rather find out about it from a banner ad, or several different family members and friends who all gave it glowing reviews?

Closing Thoughts

No alt text provided for this image

UX, UI, Design, and Creative are not as highly valued or involved at an early enough stage of the project to make an impact. Financial companies tend to relegate those team members to Production Art and QA Maintenance asks due to a lack of understanding of how effective and powerful adding UX Designers can be. Keeping them out of the project loop will not only dull their edges, but have them looking for new roles elsewhere.

Fintech teaches us that looking at finance in a customer-centric way is effective, profitable, and mirrorable at the corporate scale for banking.

Written by Kaela Coppinger · Categorized: Design UX/UI, Financial Services, Learning and Development, Product Development · Tagged: best practices, design, Design Programs, INRHYTHMU, learning and growth, ux, uxui

Jan 10 2023

Why You Should Migrate Away From AngularJS

Overview

With the legacy experience of the Angular Javascript framework, web developers have grown to lean on the framework as a go-to tool. Today, we wanted to go through a few of the reasons why you should look to migrate your existing AngularJS projects (any Angular release version under 2) to a more modern and actively supported framework (or library).

Even though AngularJS is a fantastic piece of technology that surely was top of its class when it came out (October 2010) and despite the fact that we’ve enjoyed working with its successor Angular.io (also known as Angular 2+), AngularJS has become outdated (EOL December 2021), and a risk to your company in a variety of different ways.

No alt text provided for this image
@2017, Scott Adams, Inc.

The framework has reached end of support (Version Support Status). This means that it has become read-only mode, therefore it will not be updated further. The framework has not been developed for over a year now (Release 1.8.2 happened in October 2020), and even though extended support was supposed to end mid-2021, it was extended to December 2021 due to the global pandemic. Here’s a blog post by the Angular team regarding discontinued long term support.

To add some support to the point, Angular was created and mainly maintained by Google. Google recognized the shortcomings of AngularJS, and completely rewrote it to release Angular.io. AngularJS only made it to version 1.8.3, however Angular.io has already made it to major version 13 (current at time of writing), with many more versions to come.

What Could Be Making You Hold On To Your Existing AngularJS Apps

No alt text provided for this image
@2016, Scott Adams, Inc.

Trust us, we’ve been there. You have a perfectly functioning application which needs little maintenance, and you have engineers who know it in and out already. Why invest a part of your budget in fixing something that’s not broken? Why bring in new people that don’t know the product? Why push your engineers to do something new/different to what they’ve been doing?

The Reasons

No alt text provided for this image
  • Technology: As stated earlier, AngularJS is outdated. This means that in its feature-set, performance, and just keeping up with latest developments in Javascript and the web browsers, AngularJS has clearly lagged behind, mainly due to the fact that it has been in maintenance mode and not actively developed on for years. If you stay on this framework, you won’t take advantage of the rapidly evolving web world, and the evolving smart devices, and their new features.
  • Support: As the framework is no longer maintained, any new issues or limitations you encounter will not only lack an answer/help from the AngularJS team (again, not supported anymore), you most probably also won’t have a huge community online to help you with it, like you would have with any modern framework. This could mean a longer time to fix issues that come up in your application, and a rough experience for your engineers and users.
  • Security: Perhaps the biggest reason why you should move away from AngularJS. Like any unsupported package out there, you won’t be protected when any new security exploits are identified, be it within the framework itself, or any of its thousands of dependencies and indirect dependencies (yes, your app can be exploited by vulnerabilities in the dependencies of the dependencies of AngularJS which is your app’s dependency… you get the point). Usually when something like this happens in an actively supported package, a fix will be published quite swiftly in response to it, or any dependency that includes the vulnerability will be updated with a newer version.
  • Talent: Not only do you want to provide the best possible experience for your users, but also for your app engineers. When you are trying to retain or expand your software team, AngularJS will weigh on any engineer’s decision. Engineers will want to work with quality, cutting edge technology. It is hard for engineers to get or even stay excited about working on a framework that has reached end of life. It will be much easier for you to retain and hire engineers if your apps run on modern technologies and following best practices and industry trends. I cannot stress how much easier it will be to fill open positions when your tech stack is attractive for the engineers. You can also think about what will happen once you actually find someone willing to do the job on your legacy system, they will play hard to get and you’ll end up paying more for an engineer that is probably not up to date on industry standards.
  • Business: For current technologies, the help you will get from the online community is massive, which speeds up the time it takes to fix and implement new features, and to resolve critical situations that may arise. Not only your engineers will be happier and more engaged in what they are doing, it also impacts your branding. Are you a company that invests in and works with the latest and greatest? Or a company that settles with whatever is there?

Closing Thoughts

No alt text provided for this image

With confidence, we have seen the impact that migrating legacy applications has had for many of our customers, and it is massive. Not only do applications come alive and look and feel more modern, but engineers come to work in a better mood and eager to get things done, and a true engineering culture is fostered.

Written by Kaela Coppinger · Categorized: Code Lounge, Product Development, Software Engineering, Web Engineering · Tagged: angularjs, best practices, INRHYTHMU, JavaScript, ux, Web Development, web engineering

Dec 20 2022

A Comprehensive Introduction To Swift Package Manager

Introduction

The Swift Package Manager (SwiftPM) is Apple’s tool for managing package dependencies for Swift application development. SwiftPM has been an integrated part of Swift since v3.0.

So, what are Packages? Packages contain reusable code or other resources stored in repositories that your application needs to provide a feature or function. Some examples include, but are not limited to, the fonts and color scheme for your app, a library that provides access to a web resource, a file with images required by your application. Other examples are the APIs and Frameworks that add functionality to your app and simplify your coding tasks.

Let’s work together and breakdown a high-level overview of basic SwiftPM usage and its associated features.

What Do Package Managers Bring To The Table?

Package Managers give developers a way to control which packages and which versions of those packages that the project will consume.

Other features include:

  • Allows easy use of light-weight, reusable libraries
  • Reduces code duplication
  • Supports development best practices by simplifying and supporting modular coding (easy module/package creation)

While it is possible to manually manage dependencies in a project, it isn’t practical for anything but the smallest of applications. Best practices fall on the side of using a package manager to handle this function automatically.

SwiftPM supports Swift 3+ and XCode 8+. Since Swift 5 and Xcode 11, SwiftPM has had cross-platform support for iOS, macOS, and tvOS.

Are There SwiftPM Alternatives?

There are two mainstream alternatives, CocoaPods and Carthage. Both are third-party tools requiring installation and much configuration before use.

CocoaPods

No alt text provided for this image

CocoaPods (2011) – Supports Swift 5+ and Xcode 3.11+ – Mature and stable. A centralized, easy-to-use command-line tool for package dependency management and integration into the application. CocoaPods is written in Ruby.

However, Cocoapods lacks direct control over project configuration and is basically a blackbox. CocoaPods also experiences random build failures that can’t be explained. Resolving these often involves removing and reinstalling CocoaPod dependencies from the project, clearing caches, and completely rebuilding the entire project. These steps can add a significant amount of time to the development process, especially on large projects.

Each CocoaPod dependency must have a “Podspec” file to define the metadata for that dependency. These files are typically uploaded to a different repository from the dependency itself. A “Podfile” within the app project will include a reference to this repository, and CocoaPods will use the information in this Podfile to fetch and install all of the dependencies for the app project. 

Carthage

No alt text provided for this image

Carthage (2014) – A decentralized command-line tool for dependency management. Developers have full project control and must manually provide all package and dependency information. Carthage pulls the packages the developer specifies.Configuration requires much more manual work than CocoaPods and is somewhat complicated.

Using SwiftPM

SwiftPM has many advantages over Carthage and CocoaPods. Foremost, SwiftPM is a native Apple tool integrated into Swift. Other advantages include a quick and simple configuration, easier control over packages and their sub-dependencies, and a GUI built into Xcode for managing package configurations. Each package’s metadata is defined in a “Package.swift” file, which  resides in the same repository as the package source files. 

Package Resolution

With the Package dependencies configured in the SwiftPM GUI, Xcode will download the packages and resolve dependencies at build time with no further developer interaction.

When setting dependencies, you have the following options:

  • By Version: Next Version, Up to next minor, Range, or a specific commit
  • Branch (Specify)
  • Commit(Specify)

Adding A Package To Your Project

  1. Swift Packages> Add Package Dependency 
  2. On the “Choose Package Repository” dialog, enter the desired Repository.
  3. Click Next. 
  4. On the “Choose Package Options” dialog, set the dependency rules (Versions, Branches, Commits). 
  5. Click Next. Xcode now fetches the dependency.
  6. On the “Add Package to YourPrjName dialog,” ensure that the relevant packages are checked and the proper Target is selected in the Add to Target cell.
  7. Click Finish.

Your package now appears in the Navigator under Swift Package Dependencies. Note that SwiftPM can reference both local and remote packages.

Create A Module And Add A Local Package With SwiftPM

SwiftPM simplifies the process of modularizing your code and adding it as a package to a local or external repository. This section will briefly describe the process of creating a module and adding it to a local repository.

  1. Identify a self-contained portion of code or another resource that is suitable for use in a module.
  2. Create a new file: Files > New Package. Name the package accordingly and add it to your application using the same dialog.
  3. Copy the code or resource to the new file.
  4. Delete the existing code or resource from the app
  5. Add the new package to the Application Target. In “Application Project Settings,” add the new package under Frameworks and Libraries.
  6. In the Package code, define the platforms and versions where this Package works.
  7. In the Application’s code files, import the new package into every file where its code or where its resources are used. 

If desired, you could upload the new Package to an external repository for use by developers outside your organization.

Additionally, SwiftPM will allow you to create and use binary packages. Binary packages permit developers to distribute libraries and frameworks without also distributing their source code.

Package Distribution

You can use SwiftPM to distribute resources, in addition to frameworks and libraries. SwiftPM also has built-in support for Apple’s  DocC Documentation format, which makes it easy to build robust interactive documentation files and tutorials. 

The Future

SwiftPM is a mature product still under active development to improve and add new features. Usage stats currently show it being about equal in popularity with CocoaPods. However, since SwiftPM is a native tool that requires no additional work to begin using, its future is more sure than that of CocoaPods or Carthage.

Happy coding!

To learn more about Swift Package Manager as well as its influence in mobile development and to experience Andrew Balmer’s full Lightning Talk session, watch here.

Written by Kaela Coppinger · Categorized: Code Lounge, InRhythmU, Learning and Development, Software Engineering · Tagged: best practices, INRHYTHMU, ios, iOS Ecosystem, learning and growth, Package Management, software engineering, SwiftPM, SwiftUI

Dec 20 2022

State Management: Redux vs. MobX

No alt text provided for this image

Redux was developed in 2015 by Abramhov and Clark based on concepts used in Facebook’s Flux architecture. MobX also began in 2015 and was originally called Mooservable by the dev team. It became MobX with the 2.0 release on 26 Feb 2016.

There are three parts to state management:

  • The State, which is the source of truth for your application’s State.
  • The View, which is a rendering of the current State.
  • The Action, which is something that triggers a State change.

Bare Javascript passes State via property trees. A function needing State obtains the information via property drilling. Depending on a function’s layer depth, property drilling can introduce significant overhead.

Using State Management introduces a structured workflow in the application and makes obtaining the application State trivial.

Redux

No alt text provided for this image

Overview

Redux manages application state in a centralized repository. There is a single state in the application and it is immutable. It can’t be modified by the application. This is similar to how State is managed in Flux. Redux is designed to be a predictable container for application state.

Redux combines Flux and Functional Programming and uses an immutable State as a single, predictable, source of truth in the application stored in a Javascript object.

Implementation

Using Redux requires a considerable amount of ramp-up work. There is a great deal of boilerplate code, configuration, and to take advantage of some capabilities, developers must follow explicit coding patterns. 

Workflow

There are three main workflow components:

  • The UI: The UI passes the user’s activity, or their Action, to the Event Handler. 
  • The Event or Action Handler/Dispatcher: The Event Handler’s Dispatcher then notifies the Store of the Action. 
  • The Store with Reducers and the State: The Store clones a copy of the current State for the Reducers to act on based on the user’s Action. On completion, the Store passes the new state to the UI. The updated State will trigger a refresh of any component accessing that State.

The State’s Reducers are responsible for updating the State of the Store. They are pure functions that analyze the Store’s recursive data structure. They do not mutate the current state, nor do they make external API calls. Using a combining function, they recombine the results.of their recursive processing into their constituent parts, thereby building a return value.

MobX

No alt text provided for this image

Overview

MobX was created in ES5 Javascript and follows Functional Reactive Programming patterns and prevents an inconsistent State by automatically performing all derivations. MobX’s main difference from Javascript and Redux are that State is not immutable and your application can automatically store different observable data types into different MobX Stores.

MobX uses abstraction to hide much of the background operation and reduce the boilerplate code requirement. MobX directly modifies its current state(s) without cloning beforehand.

Implementation

MobX is implicit by nature, and requires little boilerplate code. After implementing State storage in the desired data structure (plain, arrays, objects, etc.), set those properties that will change over time to observable for MobX tracking.

Workflow

There are four main workflow components:

  • Actions
  • Observable State
  • Derivations (Computed Values) 
  • Reactions (or Side Effects)

Events invoke Actions. Those actions can originate with the user or the application, and are the only thing that can modify the Observable State. MobX propagates any changes to the Observable State to all Derivations and Reactions. 

Deciding On A State Manager

No alt text provided for this image

Types of Derivations could be computation, serialization,  rendering, etc. and example Rendering side-effects are I/O activity, DOM updating, network activity. etc.

  • Application Architecture – Is the architecture Flux/Functional Reactive Programming (Redux) or more OOP (MobX)?
  • Ramp-up – Time until productive
  • Boilerplate – Redux requires extensive boilerplate setup, MobX has very little boilerplate
  • Learning Curve – Steeper: Redux requires developers to follow explicit coding patterns to access capabilities. Flatter: MobX is more implicit and doesn’t require extra tooling. Setup is adding a class and setting Observers, Actions, and Compute Values.
  • State Stores – Redux usually maintains a single immutable State even though it is possible to set up multiple Stores in Redux. It is a cumbersome process. MobX makes it much simpler to have multiple Stores and it uses changeable States.
  • Purity – Redux uses pure functions and does not allow State modification. MobX allows mutable States. 
  • Scalability – Redux’s pure functions make code scaling much simpler and predictable.  MobX’s workflow does not include many pure functions, making testing not as straightforward, and as the application grows it becomes more difficult to determine what exactly should an output be, given an input.
  • Performance – Redux can suffer performance degradation from very frequent updates to its single State Store. MobX, on the other hand, with support for multiple Stores can better support frequent State updates, such as real-time updates on market pricing for a trading platform.
  • Community Support and Tools – Redux has a much larger community and more widely tested tools. MobX has a smaller community and fewer tools.
  • Debugging – Redux has a single source of truth and uses a pure Store making its output predictable and repeatable. Redux has better debugging tools, including ReduxDevTools and the Time Traveling Debugger (provides State history). MobX with its implicit nature, multiple States, and code abstraction can be very difficult to troubleshoot and determine the proper output from a given input. All State updates happen behind the scenes and do not offer any history. MobX also suffers from fewer robust tools

To learn more about State Management and to experience Eric Marcatoma’s full Lightning Talk session, watch here.

Written by Kaela Coppinger · Categorized: Code Lounge, InRhythmU, Learning and Development, Software Engineering · Tagged: best practices, INRHYTHMU, learning and growth, MobX, Redux, State management

Dec 20 2022

Top 5 Best Practices For Building Forms

Various forms like sign-ups, logins, or checkout pages are seen everywhere in applications and websites, but what attracts a user to fill one out? What exactly makes one click the sign-up or call-to-action button on the page? Forms exist to be filled out, but there are a surprising number of forms which—through poor design, excessive fields, or other factors—push users to abandon them, unfilled. Make your forms simple and easy to navigate, and watch the data come flowing in.

Here are a few best practices when putting together your own forms to keep engagement high:

1. Ask For Less Information (and have an easy login!)

If you have a page with a sign-up flow for a new mobile app, what do you want to know from your user? It depends on what the product is and why you need the information from them. As an example: a date or friend matching platform would want your age, gender, and zip code on one screen. The next page could be preferences about the person you are hoping to match with. All of this information is necessary for the app’s purpose, but connecting to Facebook or Google has also made it much easier to skip certain steps in this process, allowing for less info needing to be manually filled out.

The following demonstration shows just how easy it is for the user to access all of the fields needed—i.e. name, picture, friends—from the Facebook API instead of filling out the same information manually.

No alt text provided for this image

2. Single-Column Ease vs. Multi-Column Stress

When you’re making a form, make sure it’s displayed in a single-column instead of a multi-column. This design element will make it easier for users to scan through and complete instead of trying to tab through different fields and with the potential of resulting frustration.

The following demonstration illustrates, the relative ease for a user to scan through one column, answering questions in a linear format instead of doing a Z-pattern back and forth.

No alt text provided for this image

3. Automate, Automate, Automate

One of the best form practices for improving design is automation. Automation makes it easier for the user to go through fields, without worrying about switching from lower and upper cases. The only fields that should not be capitalized are emails and passwords, since those cause delivery issues.

4. Progress Tracker

A user who is filling out a form—unless it’s a simple sign-up—wants to know how long the process will take them, and maybe even if it should be filled out now or saved for later. For mobile and desktop alike, a progress tracker should be included, like the examples shown below.

No alt text provided for this image

If the user is on a certain step it’s important to note that as well, all within an easily understood display of what they’ve already completed.

5. Testing (even when you don’t want to)

This is the step that many don’t even think of taking, since the design could be flawed and more time could be wasted in redesigning. The form you just created should be tested on a few different devices (at the very least on mobile and desktop) to see if it actually works and makes sense. What’s the point of developing a product that doesn’t work for the user?

The ultimate goal is getting the user to click on the “continue” or “submit” buttons in the end. By following these best practices, you can remove common roadblocks in form submissions and make the experience better for your users. 

Written by Kaela Coppinger · Categorized: Design UX/UI, Learning and Development, Product Development · Tagged: best practices, design, design patterns, Designers, INRHYTHMU, learning and growth, product development, UI, ux, uxui

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Interim pages omitted …
  • Go to page 6
  • Go to Next Page »

Footer

Interested in learning more?
Connect with Us
InRhythm

110 William St
Suite 2601
New York, NY 10038

1 800 683 7813
get@inrhythm.com

Copyright © 2023 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT