Successful startups try to achieve product-market fit as quickly and inexpensively as possible. Rather than developing a complete product right away, they create a proof of concept, various prototypes, and a minimum viable product (MVP) to reduce the risk of building something nobody wants—a leading cause of startup failure.
Let's look at proof of concepts, prototypes, and minimum viable products, what makes them different, and when to use them.
Startups solving highly technical problems often start with a proof of concept. For example, Google's proof of concept was a proprietary ranking algorithm for its search engine. By proving that the algorithm delivered relevant search results on a small scale, the company could be reasonably confident that it would work on a larger scale.
In addition to technical problems, a proof of concept may be necessary to prove that a business model is viable. For instance, a startup might create a landing page that explains a product before building it to validate that a market exists. Or, a healthcare startup may generate a sample contract to validate that a hospital would be willing to purchase its software.
The next step is working on a prototype to communicate with stakeholders and validate assumptions about users. For instance, you might use Figma to connect a series of user interfaces and simulate a specific workflow. While the functionality is incomplete under the hood, prototypes help users (and stakeholders) visualize how the application will work.
Some of the best prototyping tools include:
Prototypes are valuable for a couple of reasons. First, they help validate an idea among stakeholders and early users without the time and cost of building a fully functional product. Second, it's much easier to fine-tune a design than a fully built application. In other words, you can iterate quickly to find the right starting point for building a minimum viable product.
Minimum viable products are standalone functional products with a limited scope. While they aren't the final vision by any means, they provide users with a valuable tool that solves a painful problem or two. For example, Airbnb's MVP was a simple landing page advertising the founders' apartment for rent to validate whether customers trust strangers.
As Eric Ries of Lean Startup says, MVPs enable startups to collect the maximum amount of validated learning with the least effort. They should focus on proving or disproving riskiest assumptions in the most straightforward way possible. In Airbnb's case, the most dangerous assumption was that customers would trust a stranger and the simplest test was a landing page.
The biggest mistake that startups make is creating a minimal product that's not viable to solve a real pain point. MVPs must be high-quality enough to provide an accurate assessment of user behavior. Another common mistake is building an MVP without having well-defined hypotheses, which severely constrains what you can learn from the experiment.
Non-technical founders working on a startup may decide to outsource the development of an MVP to an agency like us. In addition to handling the design and code, we help founders with consumer testing, research, and development. The result is a more robust and well-thought-out product with a higher likelihood of success.
Proof of concepts, prototypes, and minimum viable products all play essential roles in a startup's evolution. Most startups start with a proof of concept to spot-check their idea and ensure its viability. Then, they spend a few weeks building prototypes to iron out critical workflows. And finally, they spend a month or two building an MVP to prove product-market fit.
Each stage serves a specific purpose:
| Proof of Concept | Prototype | MVP |
| - Helpful for raising seed stage funding. - May be necessary to prove a technical concept is viable. | - Essential to visualize how an application will work before building. - May be necessary to raise capital without developers. | - Necessary to show customers a working application. - Essential to reach and verify product-market fit and succeed. |
Of course, some startups may skip past certain stages. For example, a non-technical startup with an established business model may not need a proof of concept. On the other hand, startups with simple applications that don’t have complex workflows may not require a prototype—developers could start work on an MVP.
Ultimately, prototypes are an excellent way to showcase new features to stakeholders or early users in a way that demonstrates their utility. However, MVPs are often necessary to achieve product-market fit since you can see how users interact with and derive value from a product. Both are essential tools for startups to succeed.
What's the difference between a proof of concept, prototype, and minimum viable product?
A proof of concept demonstrates the technical viability of a product or business model. Next, prototypes turn a proof of concept into a vision that showcases how a product will work through a series of mock-ups. And finally, MVPs turn these mock-ups into a functional product that solves a real user pain point to validate product-market fit.
If you're building a startup, Intent can help you with everything from a technical proof of concept to building a functional MVP. Our design sprint workshops provide a well-defined and controlled process that involves ideation, knowledge sharing, decision-making and prioritizing work, helping you launch your startup from a robust foundation.
Many startups fail because they have a poor understanding of users' problems and behaviors. While many startups neglect UX design and research in the early stages, the process is instrumental to understanding user motivations, uncovering pain points that deter would-be users, and avoiding spending time and money on features that aren't important.
Let's take a look at five principles for UX design that startups can leverage to maximize their odds of success.
UX design focuses on the user experience and workflows rather than pixel-perfect visual design. By starting with low-fidelity wireframes, you can clearly define how something works before spending a lot of time on how it looks. Once agreed upon, product managers can use wireframes to prepare functional specifications before the final design is complete.
Of course, UX design doesn't end when you deploy code. You can use wireframes to quickly iterate through and validate new features before investing the time to design a complete user interface.
That said, there are some drawbacks to keep in mind. For example, stakeholders may have difficulty seeing the "vision" behind a wireframe. And Figma, Sketch, and other tools have made it much easier to build higher fidelity designs with standard UI element libraries. Nevertheless, avoid spending too much time on design before knowing what works.
Most popular websites and applications use similar user interface elements and layouts. Therefore, when users visit your application, they have a pre-existing idea of how it should work. The key is creating user interfaces based on common and tested patterns. By looking at top-notch apps and incorporating research from industry leaders like NN Group, you can create seamless user experiences without making copies that lack originality and contribute to a stale brand.
Consistency is even more essential in mobile designs where users interact with native controls. For example, Apple's iOS Human Interface Guidelines and Google's Material Design Guidelines provide guidance for everything from gestures to animation. By adhering to these rules, you can reduce the amount of effort required for users to adapt to your application.
In addition to consistency with the outside world, UX designers should ensure that everything is consistent internally. The best way to do this is by creating a set of UI guidelines covering everything from design systems to brand voice. You should also ensure these experiences are consistent across desktop, mobile, and other devices.
Accessibility is often an afterthought for designers and developers—especially for fast-moving startups. However, accessibility affects a much more significant percentage of the population than you may realize. An application that makes it impossible for screen readers to do their job creates an abysmal user experience for those individuals.
Consider the following statistics:
Accessibility is a suggestion in some places and the law in other areas. For instance, the Americans with Disabilities Act (ADA) requires businesses to make accommodations for people with disabilities, including making web content accessible to blind users, deaf users, and those that must navigate by voice or screen readers.
The best user experiences aren't always award-winning designs. Instead, they help a user accomplish a goal. For example, Google's homepage consists of little more than a logo and a text field, making it incredibly easy for users to find what they need. Meanwhile, search parameters give power users a way to maximize their productivity.
Job stories help you think about usability without being boxed into a corner. Unlike user stories that start with the implementation details, job stories focus on users' motivations and intended outcomes. That way, UX designers can think outside of the box when building workflows and user interfaces to help them solve their problems.
Usability testing is also an excellent way to maintain and improve usability over time. Before a usability session, prepare three to five specific workflows and identify five candidates from your primary user segments or personas. During each session, ask probing questions as users complete tasks. For example, you might ask, "What is intuitive or counterintuitive?" or "What has caught your attention?" to understand their state of mind.
Websites and applications tend to become more complex over time. User interfaces may require more buttons or configuration settings that steepen the learning curve with each new feature. While these new capabilities may excite current users, new users may find the user experience intimidating and complex.
UX designers should seek out the most straightforward options in the early stages of the process. Then, over time, they should regularly revisit past decisions and look for ways to cut down and improve workflows. There are almost always ways to simplify user workflows once they've gone through a few iterations of adding features.
Of course, there are some areas where simplicity isn't an option. For example, an error message that says, "your username or password is incorrect" may seem overly vague and unhelpful. But it makes life harder for attackers because they cannot easily verify if a particular username has an account (since it might be an incorrect password).
UX design is an essential part of developing any website or application. By following these principles, you can optimize the user experience and enhance business outcomes—but keep in mind that this isn't an exhaustive list! The best UX teams are always looking to understand users better and maximize their experiences.
If you're struggling with UX design, our dedicated UX team can help you understand users, wireframe effective workflows, and implement attractive and functional designs.
It seems like there's a new major security breach every couple of weeks. While consumers have been desensitized, businesses that experience data breaches can incur millions of dollars in costs. In addition, some breaches impact downstream customers in significant ways that can have substantial global repercussions, such as the infamous SolarWinds hack.
Let's look at the importance of security at the application level and how DevSecOps can mitigate these risks.
Security is a growing concern for every business. Every year, the number of data breaches grows by 30%, while the number of compromised records soars by an average of 224%. Over the past year, nearly half of data breaches originated at the web application layer, using SQL injection, remote code execution, and other vulnerabilities.
The evolution of application development and IT infrastructure is driving these changes. Monolithic applications have been replaced by APIs, microservices, and serverless functions delivered in real-time through modern DevOps workflows. Meanwhile, the volume of first and third-party APIs with access to organizational data further enhances the threat.
Modern application development and infrastructure yield better user experiences, but they also expand the surface area for new, more complex threats. As a result, security teams need real-time visibility into these moving parts while moving quickly enough to keep up with modern DevOps workflows that involve continuous deployment.
DevSecOps stands for development, security, and operations. It's a natural evolution of DevOps that integrates security as a shared responsibility throughout the IT life cycle. The core idea is to build security into application development and infrastructure rather than relegating it to the perimeter around applications and data.
In essence, DevSecOps does to security what DevOps did to tests. Before DevOps, testing was a manual process that happened at the end of the development cycle when it was too late to make changes. Now, continuous integration (CI) processes automatically execute tests to ensure quality throughout the development cycle.
Similarly, before DevSecOps, security was the responsibility of a specific team at the end of the development cycle. DevSecOps involves thinking about application and infrastructure security throughout the development cycle while leveraging automated code analysis and infrastructure monitoring to keep the DevOps workflow from slowing down.
DevSecOps is still a relatively new field that's constantly evolving, meaning that best practices are still emerging. That said, there are some common strategies that development teams use to think about and improve upon security throughout the development cycle. These strategies are a great start to an effective DevSecOps workflow.
Sensitive information should never appear in source control or public databases. During development, engineers should use local environmental variables rather than checking production API keys or other sensitive data into source control. In production, sensitive information should be encrypted in databases to mitigate risk.
Static code analysis tools can automate security checks as part of a CI/CD process. For example, Veracode can identify OS command injections, SQL injections, hardcoded passwords, or other vulnerabilities and flag them to prevent the deployment of insecure code. Some tools even integrate into developer IDEs to proactively prevent these issues.
Many application performance management (APM) tools can catch exploits as they happen rather than relying on analyzing logs after the fact. For instance, AppDynamics monitors code dependency and configuration-level security vulnerabilities in production to ensure that code remains secure after it's shipped to customers.
Dependencies are a frequent source of security vulnerabilities, particularly as the number of application dependencies rises. Fortunately, GitHub's Dependabot and similar tools can automatically monitor dependencies and create pull requests when updates are needed to mitigate security vulnerabilities.
The best security measures in the world aren't a guarantee against a data breach. Zero-day exploits, dependency vulnerabilities, and other events can create unpredictable security risks. As a result, every business should have an incident response plan to mitigate the damage from a security incident and immediately close the vulnerability.
DevSecOps best practices can dramatically reduce security risks, but there are several common pitfalls to keep in mind:
APM, SCA, and other security automation tools are essential to the DevSecOps process, but they're useless without a follow-up plan. If these tools detect vulnerabilities, development teams must assign the resources to address the vulnerability and fix the problem. Otherwise, the security risks will only continue to compound.
DevOps teams must take the time to understand how to use the security features of APM tools to wield them effectively. At the same time, IDE security alerts aren't beneficial if developers don't know how to fix them. DevSecOps requires understanding underlying security principles and the tools used to identify vulnerabilities.
DevSecOps best practices aren't a license to ignore security once code checks out. Similarly, businesses should never become complacent because they have DevSecOps in place. Effective security requires a proactive and vigilant mindset embedded at a cultural level rather than a tool level across an organization.
Security threats continue to multiply and most attacks happen at the application layer. As a result, DevSecOps is quickly becoming the status quo for application development and IT infrastructure processes. By keeping the best practices that we've discussed in mind, businesses can mitigate security risks without slowing down their DevOps workflows.
Intent integrates DevSecOps into all of our processes to ensure that the code that we produce is secure and performant. If you need help integrating DevSecOps into your organization, contact us to schedule a free consultation and learn how we can help you improve security.
Empathy is central to most design and development processes. For example, empathy maps help UX designers better understand a user's state of mind when trying to accomplish a task. Similarly, developers employ user stories to provide context for software requirements. In both cases, the goal is to put yourself in the user's shoes.
Of course, user experience design is constantly changing, and there's no shortage of novel approaches to gaining empathy. For example, job stories have become a popular alternative to user stories that add more context to proposed features, enabling developers to explore the best ways to help users accomplish a given task.
Let's take a look at the difference between user stories and job stories and how to decide on the best option for your business.
User Stories are non-technical explanations of a software feature written from the end user's perspective. Unlike technical requirements, User Stories use non-technical language to provide context to development teams. The goal is to understand why the feature is necessary and its value for users, rather than just a technical scope of work.
The general formula for a User Story is: "As a [persona], I want to [action], so that [expected outcome]." For instance, "As a sales professional, I want to share notes with my colleagues, so we can more effectively close a sale."
Product managers write user stories, and the team decides what stories they'll take on during the sprint planning meeting. In addition, teams may estimate the difficulty of user stories using planning poker or other strategies. That way, it's easier for the team to ensure that they can realistically complete their story commitments during a sprint.
User Stories are helpful for several reasons:
A common criticism of User Stories is that they make some fundamental assumptions. In particular, the "I want to" statement assumes that it's the best action to take. As a result, the team cannot think outside the box when reading the user story because there's no other context, such as the situation or the user's motivation for wanting the feature.
Intercom came up with the idea behind Job Stories, and JTBD ultimately refined the concept and gave it a name. According to Intercom, rather than focusing on what users want to accomplish, Job Stories frame every design problem as a job focusing on the triggering event or situation, the motivation and goal, and the intended outcome.
The general formula for a Job Story is: "When I [situation], I want to [motivation], so I can [expected outcome]." For example, "When I want to find out more about a sales lead, I want to see conversations my colleagues had with a lead in the past, so I don't have to ask them."
Compared to the earlier User Story, the Job Story provides more context as to why the user wants chat functionality in the application. In particular, the user's pain point is much more visible (e.g., the annoyance of asking colleagues about past conversations with a sales lead) than the User Story leads on—and the team can design to eliminate that pain.
When writing job stories, product managers should provide as much context as possible, focusing on the motivation behind the feature rather than the implementation details. As a result, development teams may identify better ways to accomplish the job than the proposed implementation in a Job Story.
The decision between User Stories and Job Stories depends on your business and team dynamics. For example, if you have a mature product and team, you may not need Job Stories or User Stories to empathize with your users. However, if you have a new team or product, these stories can help your team better understand the user.
User Stories tend to work best in companies with rigid software requirements. If you don't have flexibility in building a feature, user stories can help provide customer-centric thinking without deviating from the desired specification. However, if you have flexible requirements, Job Stories are better to help the team consider problems from every angle.
Job Stories also work best when you're already taking a Jobs to Be Done (JTBD) approach. Unlike activity-centric design that focuses on tasks like "store a file," JTBD focuses on customer transformations, like "keep a safe backup copy in the cloud." Of course, you're storing a file in both instances, but keeping a safe backup is the driving customer motivation.
If you're interested in learning more about the JTBD framework, you can download Alan Klement's excellent book on the subject for free or purchase a hard copy on Amazon.com. The JTBD blog also contains a wealth of information about the approach to help you better empathize with customers and build great products.
Job Stories and User Stories are just two tools you can use to better empathize with and understand users. In addition to these tools, there are many other strategies that user experience designers, product managers, and developers can use to ensure that they're on the right track building products that customers will love.
Some other popular tools include:
Job Stories aim to provide more context than User Stories—and you can use them in the same way throughout the Agile development process. They work best when paired with other customer-focused development practices, such as JTBD, but you can also use them as a strict substitute to promote outside-the-box thinking by developers.
If you need help reaching product-market fit, Intent can help you with everything from pre-development research to marketing and maintenance. Contact us for a free consultation!
Steve Blank notes that entrepreneurs need to "get out of the building" to be successful. Rather than working in isolation, the founder of modern customer development believes that entrepreneurs need to talk with potential customers, partners, and suppliers to truly understand them and deliver the best possible solution to their problems.
Let's look at how to conduct compelling user interviews and leverage the results to improve your product.
Interviews provide valuable insights into a customer's (or a potential customer's) life and how they perceive and use your application. Since most developers don't consume products they build, these exercises provide a necessary perspective to ensure they're on the right path. Best of all, you can collect these insights before writing any code.
For example, suppose that you're building a feature to store medical data. You could try to guess what nurses will think when entering data and build out a solution—but the odds are you've missed something. After all, you don't have an in-depth familiarity with a nurse's workflow nor how they feel about their existing way of doing things.
Fortunately, you can interview nurses to see how they log medical data, what current solutions they use, and the shortcomings of those solutions. Then, you can build a product that addresses a real pain point and meshes with the way nurses already operate. The result is a much more compelling solution that they'll want to adopt.
Of course, validating a new product is only one reason to interview users. There are many other reasons that you may want to consider user interviews:
User interviews are invaluable when you're searching for product-market fit, but they're equally helpful when building a new feature or even just reassessing how an existing product performs. The most successful teams consistently interview users throughout the product lifecycle to validate features and ensure they're on the right track.
The ideal interview candidate depends on your interviewing goals. For instance, you might look toward your existing customer base to assess the usability of a new feature. On the other hand, if you don't have a product yet, you may need to interview potential customers in a target market to validate product-market fit before beginning development.
Fortunately, several platforms make it easy to source users:
You can also look for local users on Craigslist or at other in-person events. By sourcing local users, you can host them on-site and gather more specific insights than you can with remote interviews. The downside is that these meetings may take extra time to coordinate and organize, plus you may need to compensate test subjects more for their efforts.
Start by preparing the key points and questions that you'd like to cover. These questions should be open-ended—not leading questions—and focus on behaviors rather than feelings to provide the most insight. Then, during the actual interview, you can ask follow-up questions to get specific details about a workflow or piece of functionality.
When you start each interview, give the user a brief rundown of what to expect. Explain how long the process will take and explain the nature of the questions (e.g., background questions and then prototype questions). Then, actively listen to their responses, paraphrase answers to clarify uncertainty, and record the process rather than taking notes.
There are a few other techniques that you can use to gather insights:
When you've finished each interview, be sure to thank the participant. If you're conducting interviews outside of a platform, consider compensating users for their time. Many companies use gift cards or offer product-related rewards, such as a free month or year of service or credits on their account.
The user interview is only half the battle—you still have to consolidate your notes and draw real insights. When reviewing notes, the goal is to look for recurring themes. For example, you may notice that most users share a similar pain point or miss a particular part of a workflow. These are valuable insights that likely affect a large number of users.
In addition to drawing out these insights, you should adjust your interview notes and questions to reflect new information. For example, if you notice that most users share a similar pain point, you might adapt your questions to focus on that specific pain point to learn more. Or, you might notice that users were more responsive when framing a question a certain way.
User interviews are an essential part of customer development. By keeping the tips that we've discussed in mind, you can ensure that you have productive interviews that deliver real insight. At the same time, you should be sure to collect and analyze the insights you gain from these interviews to inform the future direction of your product.
If you need help fine-tuning your customer development or implementing technical features, Intent can help you with a wide range of services. Contact us today for a free consultation.
Most businesses are familiar with the idea of growth hacking—or testing and scaling strategies to improve the customer journey. However, before the term "growth hacking" was even coined, Dave McClure gave a talk to introduce his AARRR framework for product-led growth. The framework helped kick off the growth hacking revolution and remains relevant today.
Let's take a look at how the AARRR framework can help your business grow faster.
Dave McClure, the founder of 500 Startups, developed the AARRR framework in 2007 as part of a talk at Supernova, titled "Product Marketing Metrics for Pirates: AARRR!". The simple framework defines five user behavior metrics that product-led growth businesses should track and optimize to improve marketing and development.
The five "pirate metrics" are:
While measuring these metrics wasn't easy in 2007, modern marketing and analytics tools have made it easier than ever to measure and optimize these growth hacking metrics. In particular, Google Analytics is a free solution that enables you to measure all five AARRR framework components, and Google Optimize even helps you run A/B tests.
How are customers finding your product or service? For example, they may arrive from email marketing, content marketing, social media, or paid search. The most common way to measure acquisition is by comparing click-through rates to the cost of each channel. However, you may also want to look at the quality of each user (e.g., their conversion rate).
What actions are your customers taking to engage with your business? For example, Facebook's original activation metric was a new user making seven friends within their first ten days on the platform. The best starting point is a simple metric, like time on site, unless you already have a specific goal in mind that's more relevant to your success.
How many of your customers drop off over time? For example, you may have a high number of customers drop off during the first 30 days before reaching a plateau of long-term customers. Drip marketing campaigns are a popular way to boost retention rates over time by keeping customers engaged and encouraging them to use your product regularly.
How can you encourage existing customers to refer their friends and colleagues? For example, you may offer customers referral bonuses, such as free service or discounts, in exchange for onboarding their contacts. Referrals are an excellent source of revenue since there's a lot of built-in trust that comes with a colleague's recommendation.
How is your business bringing in money? You might have many happy users, but you don't have a successful business unless they're paying you sufficiently. A good starting point is identifying how much revenue you need to break even and then work toward reaching that level. Later, you can look at how to provide more value and increase revenue per user.
The AARRR framework doesn't provide step-by-step instructions for optimizing specific metrics. Instead, the framework helps you identify the types of metrics that you should measure. In other words, it enables you to avoid so-called "vanity metrics" and focus on data points that move the needle in terms of growth and profitability.
That said, a typical process looks something like this:
For example, suppose that you want to improve retention on your mailing list. If you use MailChimp, you can calculate the average number of unsubscribes per email. You might decide to try segmenting your email list by source (e.g., customers vs. prospects) and send different types of emails to each source to try and reduce the unsubscribe rate.
Again, the specific metrics and goals depend on your business. For example, some companies may want to optimize the number of leads going into a marketing funnel, while others may focus on increasing average revenue per user (ARPU). It's essential to take the time to sit down and define the right metrics for your business.
Growth hacking has come a long way since the AARRR framework came out in 2007. In fact, many companies have dedicated growth teams that focus on continuously optimizing these metrics. There are thousands of different growth hacking strategies and techniques that have come out designed to help businesses scale more quickly and cost-effectively.
Most experts recommend starting with processes rather than tactics. In other words, don't automatically try out the latest YouTube Ad tactic that you see on Hacker News or IndieHackers. Instead, create a repeatable process that you can use to develop and execute tests, learn from the results, and ultimately scale success stories.
There are many different tools that you can use to help with the process. For instance, GrowthHackers provides a software suite that you can use to define goals, manage experiments, and track results. If you want something cheap and straightforward, most tracking can be done with Google Analytics and a couple of spreadsheets.
There are also many online communities that have sprung up to share growth hacking knowledge. IndieHackers is an online community of solo founders and small businesses that frequently use growth hacking to launch new products whereas GrowthHackers provides an online community for growth hacking teams.
Of course, growth hacking also goes hand-in-hand with the Agile methodology. Without the ability to quickly pivot based on customer feedback, growth hacking would be a lot less effective. Agile development teams can quickly implement new features in two-week cycles and modify them quickly based on feedback.
The AARRR framework kicked off the growth hacking revolution in 2007. While the framework's metrics remain relevant today, you may also want to dive deeper into more modern processes and tactics to supercharge your growth rates. Fortunately, there's no shortage of tools and communities out there to help you along the way.
If you want to discuss your project, contact us today to schedule a free consultation and learn how we can help you quickly iterate based on customer feedback.
You've secured seed funding for your business idea, but your technical co-founder needs some help to build out a minimum viable product (MVP). You could spend more than half of your budget—along with a chunk of equity—on a full-time software engineer, but you're not even sure if the MVP will achieve product-market fit.
There's also the challenge of hiring a great software engineer. According to McKinsey, 87% of organizations are experiencing a software development talent shortage. There's also a high cost of hiring a lousy engineer in the early stages of a business since they represent a high cost and could write code full of errors and technical debt.
Let's look at how outsourcing can solve these problems and how to work with outside development teams.
Many startups must decide between hiring in-house developers or outsourcing development to third parties. While communication is more straightforward with in-house development teams, outsourcing is significantly less expensive and more flexible. These pros and cons can mean the difference between success and failure.
In other cases, you may have both an in-house and an external development team. For instance, you may have a B2B web application and outsource the development of companion mobile apps. That way, you can focus your internal efforts on the web-based platform but still offer users a convenient mobile app to add value.
The benefits of an in-house team include:
The benefits of outsourcing include:
The right decision depends on your startup's short-term priorities and long-term objectives. For instance, outsourcing may be the best option if you want to launch as quickly as possible, whereas in-house developers will be better if culture and team fit are essential. You may also be limited to one option based on your funding or other factors.
Startups that decide to outsource development should start by preparing some basic materials for potential partners. That way, you don't have to spend a lot of time in meetings gathering basic details. In particular, these materials should provide the context for the technical development and ensure that everyone is on the same page with tech and budget.
The three most critical elements include:
When searching for the right partner, the best source of leads is referrals from people you already know. You may also look for partners that have experience working with other companies in your industry or attend conferences or meetups to find leads. There are also many freelancer and agency portals for remote workers that have verified reviews.
When evaluating partners, it's equally important to consider their culture. For example, a partner that typically uses a waterfall development approach may not be the right fit for an agile team. You should try to find a partner that mirrors your approach to business rather than seeking partners based purely on price or expertise.
Outsourcing has a mixed reputation in the tech community. Startups seeking the cheapest possible option are often disappointed by the results. On the other hand, finding the right partner and effectively managing the relationship can significantly lower costs and cut down on time-to-market without compromising quality.
The most effective ways to manage the relationship include:
In most cases, communication is the most critical component to success when outsourcing development. Synchronous communication is typically the best option to ensure everyone is on the same page. Asynchronous communication may also be necessary when using off-shore developers located in different time zones.
Many startups outsource software development, but without the right approach, it's easy to get derailed. In addition to coming prepared, outsourcing development requires clear communication through regular meetings, a well-defined scope, and management tools to ensure that in-house and external developers are working well together.
Intent specializes in helping startups develop high-profile products at the intersection of physical and digital if you're interested in working with an expert partner. Since 2008, we’ve worked with some of the biggest brands and the most innovative startups out there, including Oura, Nike, and Samsung, from pre-development research to long-term maintenance.
There are many different software development philosophies, but the two most popular are waterfall and agile development. The waterfall method is the traditional linear development approach that has been around for decades, whereas agile is a newer iterative approach that emphasizes the rapid delivery of working software and customer feedback loops.
Let's look at the differences between waterfall and agile methodologies and how you can decide on the best option for your project.
The Waterfall Methodology is a linear and structured approach to project management. The software development life cycle (SDLC) consists of steps with formal hand-offs from one stage to the next. For example, a customer may need to approve the requirements before the design process begins, and then approve designs before development begins.
A typical sequence of steps might be:
You can think of waterfall development as a NASA project. There's a lot of careful planning and documentation at the beginning and diligent execution of the steps needed to complete a robust final product. There are checklists and approvals required at each stage to ensure that the project is on track and there's a big (and risky) launch at the end.
The waterfall methodology is typically used by larger enterprises with a crystal clear idea of what they want to build. For example, an e-commerce business may wish to create an internal inventory tracking tool with a very specific set of features. Since the scope of the project is unlikely to change, the waterfall methodology provides greater visibility.
Pros
Cons
Tldr; Waterfall development works best when there's a low level of uncertainty and a well-defined plan of action. You may also use the approach if your team isn't familiar with agile concepts.
The agile methodology is an iterative approach to development. The goal is to rapidly and continuously deliver working software so customers can provide feedback. Rather than maintaining a rigorous schedule, development work is time-boxed into "sprints" with a running list of deliverables that are prioritized based on their business value.
Many startups use agile development because they don't always know the full scope of their product at its onset. For example, they might try one idea and pivot to another if it doesn't gain traction among customers. They use the agile methodology to learn what customers want through the continuous delivery of working software.
While projects with a clear scope could use the agile methodology, there tends to be less visibility in terms of time and budget. The agile approach can also lead to the "piecemeal effect" that occurs when pieces of code are defined and added to an existing application where they may not fit as well as they would have with better planning in advance.
Pros
Cons
Tldr; Agile development is ideal when there's a high level of uncertainty. In addition, agile development tends to yield creative solutions to a problem that may not have been obvious at the onset of the project.
How do you choose between waterfall and agile for your project?
The important thing to remember is that the decision between agile and waterfall methodologies isn't binary. That is, you can blend elements of both approaches to get the best of both worlds. For example, you might plan out the entire application to provide stakeholders with an estimated time and cost, but be open to changing roadmaps along the way.
There are several factors to consider:
There is no "right answer" when deciding between the two approaches—it depends on your team and project. That said, there are several factors that you can use to make the decision.
Waterfall and agile are two popular software development methodologies with their own sets of pros and cons to consider. If you have a clear scope, waterfall development can provide greater visibility and a clear deliverable. If your scope might change over time, agile development enables you to learn as you go and produce the best final product.
If you need help planning your application development, contact us to schedule a free consultation and learn how we can help!
Digital products have become increasingly popular due to their large addressable markets and limitless scalability. Unfortunately, as they've become more popular, these products have become harder to market and sell. Competition tends to increase over time, consumer expectations are rising, and conventional advertising has its limits.
Let's look at a few strategies to boost digital product sales and how you can set your business apart in a crowded market.
The best way to boost sales is to create a product that consumers love, and in order to do that, you need to know your customer.
Empathy maps help visualize customer attitudes and behaviors to develop a deeper understanding. At its core, empathy maps look at what a user says, thinks, does, and feels when completing a task. Empathy maps work best at the beginning of the product design process to understand and prioritize customer needs before building anything.
Once you have an empathy map, you can create more accurate user personas. User personas ensure that everyone is on the same page about the target customer, from the team building products to the marketing team. They also help avoid the temptation to add unnecessary components and complicate the product.
Of course, the development of empathy maps and user personas shouldn't be one-time exercises. Instead, you should use them over time to support customer-focused reasoning and define product positioning. You can also update them based on new information that you uncover through user interviews or other customer discovery techniques.
Early adopters should already love your product if you've achieved product-market fit, making them perfect brand ambassadors.
There are many places to find early adopters depending on the product and audience. For example, a consumer-facing product targeting mothers might leverage Facebook groups, whereas a business-facing product might seek out trade groups. If you've identified a significant pain point, you should find some people willing to try the product early on.
Many early adopters come in the form of beta users. For example, you might provide an early version of an ebook or online course to a subset of users in exchange for their feedback. They can help you better understand the market and ensure you’re on the right track. Of course, they're equally helpful after a product launch as brand ambassadors.
There are several ways to turn early adopters into advocates:
Many products have complementary tools or services that can help promote the product and boost sales over the long-term.
For example, an SEO course might create a free website analysis tool that provides a customized list of suggestions. In the report, the company might pitch the course as a way to fix the problems identified in the website report. You’re providing immediate free value to visitors with an upsell to a product that they know they might need to fix their problems.
You can also create complementary services to boost digital product sales. A common example is a curated newsletter focused on your niche market. You can use the newsletter as a way to market your product in a subtle way while simultaneously reaching potential customers on a weekly or monthly basis with content that they enjoy.
Many companies also use digital products as a stepping stone to software products. For example, the same SEO course might evolve into an SEO tool that’s available as a software-as-a-service (SaaS) subscription. Complementary tools that you build for marketing might be repurposed as parts of these applications or help market a larger piece of software.
Most companies create digital products to solve a problem for a customer and end up becoming somewhat of an expert in the process.
Many successful companies launch products to solve these problems, but the most successful companies become thought leaders in the space. For example, an SEO course might write educational content on improving search rankings or send a weekly newsletter. These efforts establish them as a knowledgeable presence and not just a company selling a tool.
In addition to developing in-house content, companies might offer their expertise to journalists covering a related problem area. For example, Help a Reporter Out (HARO) and other services make it easy to reach out to journalists and get quoted in relevant industry media sources. It's a great way to build credibility and expertise in a space.
There are many different ways to promote and market digital products, but it's harder than ever to set yourself apart in today's crowded market. So, in addition to understanding your customers and solving real problems (the two most essential steps), built-in marketing techniques and becoming a thought leader can go a long way in building trust.
If you're looking for help building or marketing your project, contact us to learn more about how we can help!
Usability tests are a cornerstone of successful software businesses. By soliciting user feedback in the design stage, you can identify potential weaknesses and address them before the public sees them. Unfortunately, many usability tests are rendered ineffective by common mistakes made by interviewers that bias the results.
Let's look at seven techniques that you can use to get the most value out of your usability tests.
The best usability tests begin with a clear plan.
Start by defining specific objectives for the tests. For example, do you want to see if users can complete a task? Do you want to know how long it takes to complete a task? Or, do you want to identify stressful points during a specific workflow that could lead to abandonment? Specific objectives ensure that you get the results you want from the tests.
Next, you should prepare the scenarios and questions that you'll ask. Write down scenarios that users should complete rather than specific instructions. After all, the goal is to see how they naturally interact with a product—not how well they follow instructions! Finally, prioritize the tasks and tie each of them to one of the objectives you defined earlier.
Most people won't want to give you objective advice.
Begin each session by making it clear that you're open to criticism and that it won't hurt your feelings. When describing the product, use words like "the" and "this" rather than "my" or "our" to detach yourself. Again, the goal is for the user to provide honest feedback that can help improve the product—even if it's difficult to hear as a designer!
At the same time, when you do receive criticism, avoid the temptation to judge or correct users. Again, the goal is to understand how users use an application—not how you intended them to use it. When responding to criticism, watch your tone and body language to avoid subtle cues that could discourage honest feedback moving forward.
Thinking aloud doesn't come naturally, so you need to encourage it.
Make it clear that users cannot make any mistakes. You're like a therapist listening to their thoughts and problems without passing any judgment, not an instructor teaching them how to accomplish a task. Encourage them to express whatever is on their mind without worrying about how they sound or hurting your feelings in the process.
The key is making them think aloud. That way, you can get a better idea of what's in their head, and they can express their thoughts without reservation. For example, you might encourage them to think aloud by asking, "What's on your mind?" or "You look confused. Tell me what you're thinking." Like a therapist, you want them to open up to you.
Many users will inherently think they're taking a test.
It's common for users to ask for your advice, but giving them step-by-step instructions won't leave you with any valuable feedback. Rather than answering their question, try responding by saying, "If I weren't here, what would you do?" Answering a question with another question is a great way to dig deeper into their thought processes.
You can also use asynchronous usability tests to avoid the temptation to provide advice. While you can't ask follow-up questions in the moment, UserTesting and other platforms record experienced testers as they attempt to work through a scenario on their own. You can then review the recordings to see what happened along the way.
Non-verbal cues are just as important as words.
Albert Mehrabian, a body language researcher, found that 55% of communication is non-verbal, 38% is vocal, and 7% is words only. In particular, Mehrabian found that non-verbal communication was key to deciphering a person's attitude. Attitude can be a tremendous insight when conducting usability tests.
For example, if you notice a user is frustrated, you may want to ask, "Can you let me know how you're feeling right now?" If they say everything is fine, you may be able to dig deeper to disarm them. However, without interpreting non-verbal cues, you might never ask the question and assume that the user is okay when they’re actually frustrated.
Usability tests should occur early and be an iterative process.
Usability tests are most valuable early in the design process when you can easily make changes. If you test too late, you may not be able to incorporate all of the feedback. Or, the cost of integrating the input may be too high if you've already done a lot of design work. As a result, it's best at the beginning of a development cycle.
Fortunately, you don't need a high-fidelity prototype to get value out of usability testing. Adobe XD and similar tools make it easy to build low-fidelity prototypes that function "good enough" for usability tests without the high upfront cost of design work. You can even connect different screens to jury-rig a realistic feeling application.
Remote usability tests may be more accessible to some businesses.
Most remote usability testing platforms are asynchronous, meaning that you can assign scenarios and then focus on other things. You can then view recordings of the usability tests on your schedule, freeing up your time and enabling you to look for insights by watching sessions multiple times rather than relying on notes.
Some popular usability testing platforms include:
Usability tests are a critical part of any software business, but it's easy to make mistakes that invalidate their output. By keeping the five tips we've discussed in mind, you can avoid many pitfalls and maximize your value from usability testing to build better products.
If you need help with usability testing, Intent can help craft high-impact interviews that provide the insights you need. Contact us today!
The most common reason that start-ups fail is a lack of product-market fit. At the same time, the most common reason IT projects run over budget is unclear objectives and a lack of focus. These problems boil down to a lack of research and communication—and product development workshops are the best way to improve them.
Let's look at the different product development workshops and how you can streamline the development process.
Product development workshops provide a framework to help you design, prototype, and test the viability of an idea, product, or feature. Google Ventures combines these workshops into a 5-day Design Sprint, but you can also pick and choose specific workshops to meet your needs. The secret to success is structured meetings with specific objectives.
The most popular workshops include:
The exact structure of these workshops depends on your requirements. For example, Google Ventures provides a specific set of time-boxed activities and deliverables for each workshop, and it has been time-tested across many organizations. The Product Design Workshop is another example of a template for running these kinds of meetings.
You can even develop your own customized product development workshops that specify specific goals, deliverables, and participants. Here’s how:
It helps to look at existing product development workshops for ideas that can help you determine the best activities, time-box those activities, and define the deliverables that will make the most significant impact. In particular, Google Ventures’ Product Design Sprint is an excellent resource that defines different activities and timelines.
Product development workshops usually involve four to eight team members. If you have too many people, it becomes difficult to reach a consensus. If you have too few people, you may be limiting the number of possible solutions to a problem. Four to eight team members tends to be a sweet spot that yields many ideas without indecision.
The most important roles include:
The team should have access to a large enough room with a whiteboard and sticky notes. In addition, the facilitator should gather all relevant customer or competitor research, software design tools, and other information needed to complete the workshop. Again, the exact requirements vary depending on the workshop that you run.
The COVID-19 pandemic accelerated the trend toward remote work while other teams are dispersed throughout the U.S. or around the world. While product development workshops work best in person, modern communication tools have greatly improved the process for remote teams—as long as everyone has fast internet speeds!
The most popular remote-friendly tools include:
Organizations that outsource development may have additional challenges to overcome. For example, there may be significant time differences if team members are spread out across the U.S. or around the world.
Many organizations use product development workshops at the onset of a project, but they are invaluable at every stage. At the same time, many organizations forget that product development workshops can be helpful for more than just ideation. For example, you can prototype user stories or get everyone on the same page with a new feature.
Consider using a product development workshop when:
You can also hold product development workshops quarterly or annually to ensure that development is on the right track. For example, you may not recognize changing customer requirements or attitudes toward competitors in some cases unless you take a deep dive into the product and market with a regular workshop.
Product development workshops are an excellent way to build a clear product roadmap and align your team with a common goal. By reducing uncertainties and miscommunication, you can maximize the chances of reaching product-market fit and minimize budget overruns. You can even run product development workshops remotely using a variety of tools.
If you're new to product development workshops or want an outside set of eyes on a project, Intent can guide you through the process. Contact us for a free consultation today.
The software industry is full of acronyms, ambiguous terms, and evolving roles. Perhaps nowhere is this better illustrated than the ideas of UI and UX design. While user interface and user experience sound very similar, there are some essential differences between these two terms and their roles within a software development team.
Let's look at the difference between UX and UI design and how both roles work together to build usable products.
The user interface, or UI, consists of all the elements that enable users to interact with a product. For example, text, buttons, colors, and layouts are all user interface elements. UI designers are primarily concerned with designing, organizing, and arranging these elements on a page to achieve specific outcomes, such as guiding a user through a workflow.
UI designers may also have a background in art or design, including typography, color schemes, animation, branding, and other areas. Or, they may have some HTML/CSS experience, enabling them to incorporate design elements into basic code that front-end developers can use as a basis for the actual production application.
Most UI designers use tools like Figma or Sketch to build user interfaces. These UI elements are then sent over to front-end developers that convert the designs into code. For example, both Figma and Sketch enable UI designers to export image assets in various formats and even generate vector icons that developers can drop into designs.
In some cases, a dedicated visual designer will be responsible for creating the actual artwork based on strategic design principles. For example, these individuals might handle logo design, iconography, and creating marketing materials appearing in a user interface. In other cases, these responsibilities may fall to UI designers.
The user experience is what the user takes away from interacting with a product. For example, a user's journey toward solving a problem or accomplishing a task is the user experience. UX designers focus on helping users solve problems with minimal friction and help teams avoid building the wrong solutions to a problem.
UX designers typically have a background in user research and design thinking. For example, they may have experience running A/B tests, user interviews, email surveys, or using other techniques. In addition, they may have expertise using low-fidelity design tools and excel at communicating with product managers or owners.
UX designers typically use Customer Personas, Empathy Maps, and Journey Maps to discover a user's goals and design the optimal ways to achieve them. These tools form the high-level vision before UI designers add fidelity. For example, empathy maps help UX designers understand how a user feels throughout a workflow to eliminate frustrations.
UI designers can create beautiful designs, but they would be confusing without a good UX design. On the other hand, UX designers could create the perfect workflow, but it could fall flat without a good UI design. Together, UI and UX designers understand the customer's needs and build beautiful and functional products.
Some of the key responsibilities for each team include:
| UI Design | UX Design | |
| Visual Design | Yes | No |
| Layout Design | Yes | No |
| Wireframes / Prototypes | No | Yes |
| User Research | No | Yes |
| Team Collaboration | Yes | Yes |
| Creative Mindset | Yes | Yes |
In some cases, a single role fulfills UI and UX responsibilities. These UI/UX roles are typically responsible for everything from user research to front-end deliverables. However, a common criticism is that fulfilling both rules is challenging and can reduce the overall quality. Separate teams tend to be a far better option, especially in larger organizations.
Most Agile development teams have UX and UI design teams that work alongside front-end and back-end developers. UX teams are typically involved in the planning stages of a sprint, whereas UI designers usually join the process during the earlier stages of a sprint. Both groups tend to also work closely with front-end developers to bring the vision to life.
Here's how a typical Agile workflow might function:
UI and UX designers both work with Agile and communication tools, such as Jira or Slack. In addition, both roles require collaboration with developers, product managers, and quality assurance engineers to iterate designs and workflows based on the market, user feedback, and technical constraints—all critical components of Agile.
Many businesses outsource software development to focus on their core competencies, while other companies add outside expertise where needed. When outsourcing UI or UX roles, you should consider the differences between them when selecting a partner. The best partner for UI support may look very different than a UX partner.
For example, Dribbble and other design platforms make it easy to identify UI design talent. These designers may have a firm grasp on design theory and produce intuitive and easy-to-use interfaces. However, these same individuals may not have UX-related skills, such as running user interviews or developing A/B tests.
If you're looking to outsource UX design, the best firms position themselves as partners. After all, UX design is a much more intimate discipline that involves working with stakeholders in the early stages of development to build the right product. In particular, these firms should have expertise in customer testing and prototyping/MVPs.
UI and UX teams both play important roles within an Agile software development firm. While UX designers are focused on the high-level flow, UI designers implement the granular details before handing off design elements to front-end developers to put into the final release.
If you need to help with UX or UI design, contact us today to schedule a free consultation!
How many times have you struggled to identify images in a CAPTCHA? Do you fight to create passwords that comply with complex requirements?
The best UX designers create flows that are intuitive and easy to use with as little friction as possible, but security often requires some degree of friction. From password security to DDoS protection, there's a delicate balance between security and the user experience, which can be hard to achieve without the right approach to development.
Let's take a look at how to strike that balance.
Authentication is among the most challenging areas for balancing UX design and security. Since it's often the user's first interaction with an app, authentication can influence their entire experience and should be as seamless as possible. On the other hand, it's one of the most common attack vectors for bad actors to access a system.
The best way to improve security with minimal UX friction is by accurately identifying legitimate users. For example, you might look at a user's device, geographic origin, or IP address to predict the likelihood of an honest login attempt. If you have a low confidence score, you can introduce more friction to stop malicious attempts to gain access.
Some parts of authentication may require poor UX design. For example, error messages that say "your username or password is incorrect" may seem like poor UX because they’re vague. But this message makes it more difficult for attackers to guess usernames and passwords using brute force attacks—they cannot easily verify if an email address has an account.
Chargebacks are a common frustration among e-commerce shops. For example, if a malicious user successfully uses a stolen credit card, merchant banks could force you to refund the user, pay a fee, and lose any product you already shipped. On the other hand, requiring too much information at checkout can hurt conversion rates.
As with authentication, the best way to prevent fraudulent credit cards is by prescreening customers. Users that have successfully logged in to their account with their historically-used location and IP address may require minimal extra verification. But, you might make users that login from an unfamiliar computer verify their CVV or address.
The most common signs that you may need to introduce more friction to the process include:
E-commerce shops with guest checkouts must balance the probability of fraud with the friction of adding more verification methods. For example, using Address Verification Service (AVS) ensures that user-entered addresses match the cardholder's address, but it adds an extra step that can lead to attrition in some cases.
Many applications have a heavy collaborative component that introduces security risks. For example, a user may want to share a health record with another user, creating HIPAA compliance risks. UX designers must create an easy-to-use workflow for sharing these records while minimizing the risk of accidentally sharing them with the wrong parties.
A critical security principle is that of "least privilege"—or users only having access to what they need. When planning out an application, consider what data should be limited based on each user type's job. Attackers typically look for admin-level logins, so restricting access minimizes the surface area for these attackers to target.
Sharing also poses a security risk to organizations managing sensitive documents. In general, it's a good idea to default to no sharing unless a user deliberately chooses to share. In addition, the document owner or administrator should have the ability to set explicit permissions for the document to prevent any unauthorized access, editing, or deleting.
Rate limiting is another tough trade-off for some applications. For example, many APIs impose rate limits on applications or users. A rate limit set too low can cause frustration among legitimate users, while a rate limit set too high can cause availability issues. These same issues might arise in non-API use cases, such as hosted storefronts.
Security is often an afterthought in the development process, but just like writing software tests after the fact, that can lead to problems. Trying to bolt on security fixes just before a release leaves little time for UX designers to minimize user experience friction. Instead, it's better to have a team that brings security expertise to the table from the start.
DevSecOps is the idea of integrating development, security, and operations into the development process. By incorporating security protocols into the Agile development process and software tests, teams can create faster and more secure delivery pipelines. You can also quickly respond to threats when they inevitably arise.
If you're working with an outside development group, you should ask how they incorporate security into the development process. You should also ask how they balance UX design with security to minimize friction and ensure a delightful user experience. If they don't have a good answer to these questions, it might be time to consider other options.
Leonardo DaVinci once said, "Simplicity is the ultimate sophistication." In other words, it's hard to make things simple because the tendency is to overcomplicate them. A DevSecOps approach results in cleaner and more maintainable code by incorporating security principles from the start rather than bolting them on at the last minute.
The same focus on simplicity should guide UX design. When thinking about security, seek solutions that offer the simplest user experience. For instance, DNS solutions like Cloudflare's built-in bot protection stops malicious actors from accessing your website. Only introduce friction to the user experience when there's a risk.
Security often involves a trade-off with the user experience, but a single data breach can be catastrophic. Keeping things simple and incorporating security into the development process with a DevSecOps mentality can minimize friction to the user experience and reduce the odds of a security breach.
DevOps is a term that has been thrown around for the last few years, and it is one of those words everyone seems to be using but not many people are sure what it means.
DevOps can be defined as a cultural change in which software developers take on more responsibility for quality assurance and operations tasks traditionally performed by dedicated teams of IT professionals. This blog post will highlight everything you need to know about DevOps and its role in the software development life cycle.
So what exactly is DevOps? It's a combination of two words, "development" and "operations," which refers to the collaboration between software developers and IT professionals. Contrary to popular belief, DevOps is not a specific technology. Instead, it's a mindset involving collaboration, communication, and automation for software delivery among different departments within an organization.
A key goal of DevOps is to develop software faster, which allows organizations to react more quickly to changes in the marketplace and deliver innovative products. For example, a company that develops a new digital product can typically deliver it into production much sooner than competitors who use traditional development methods.
Another benefit of DevOps is the ability to fine-tune and continuously improve an application in a production environment, which helps organizations reduce the length of time between releases and respond to issues more quickly. As a result, many organizations have adopted DevOps practices to improve their efficiency and quality of service while reducing the time it takes to deliver new features and products.
Other vital benefits include reducing the cost of coding errors and responding quickly to market changes, which ultimately help organizations deliver innovative products faster than their competitors.
DevOps practices are designed to enhance the speed and stability of software delivery while cutting operational costs. DevOps increases software development and deployment efficiency when appropriately used by aligning business goals with quality assurance and operations functions.
Through this collaboration, companies can quickly deliver new features and updates to customers, providing feedback on applications in a production environment. This collaboration also improves communication among departments, leading to greater efficiency and reduced expenses spent on deploying software.
When organizations look to integrate DevOps into their software development life cycle, various methodologies can be applied. Two common software development methodologies that are incorporated into DevOps practices are Agile and Waterfall.
Waterfall is a sequential development process in which you perform steps one at a time (like building blocks), and once you begin creating an application, there's no going back to change it later on. All changes must be made before the next step can be performed. When a problem is identified in the application, you have to go back and rework previous actions before moving forward again. Thus, this development method is not very flexible and can delay an application by weeks or even months if problems are encountered later in the cycle.
Waterfall methodology can often lead to lengthy testing cycles, which can result in dissatisfied customers if not managed thoroughly. As a result, customers might not receive the applications they need when they want them. The Waterfall method can present certain challenges when developing software. It doesn't allow you to rapidly make changes to an application or fix problems that arise as work progresses. However, it offers the advantage of providing high-quality applications that can be thoroughly tested and reviewed before deployment.
Agile is a software development process that focuses on delivering small chunks of applications (usually called "features") to customers quickly, typically every two weeks or so. Because each feature is developed independently of the others, you're able to deliver them more quickly than methods such as waterfall.
Small groups of developers work on the features and combine them later in the development cycle using "integration testing" to ensure they all work together. Agile methodology allows for rapid feature delivery, with continuous improvement and iteration throughout the development process. It also allows teams to develop working software from a business perspective at an early stage, which gives the customer and developer a chance to engage early in the process.
Lean-Agile development methodologies also consider that there are no perfect applications, and you should strive to create working software as soon as possible so users can use it before the full completion of an application. This means that some features might be missing or not fully developed; however, the product's value is realized early in its development cycle.
Lean-Agile development methodologies provide faster time-to-market and rapid feature delivery while still maintaining quality assurance standards, potentially saving significant development costs for the organization.
DevOps is a paradigm that has changed the way software development teams work. It's not just for large companies and enterprise-level projects anymore; it can be used by any company, no matter how small they are or what type of project they're working on.
The goal of DevOps is to create a business that's able to react quickly to the needs of its customers. By employing Agile methodologies and Lean development strategies, you can help your company and its development projects meet the ever-changing demands of your customer base.
At Intent, we work with Partners from a variety of industries: from software to hardware, and everything in between. During all our years in business, we’ve determined that no matter our business Partner, what problem they are tackling, or what product they have in mind, they all look for the same thing:
Why tending to all three equally is important and what are the good project management processes and practices to achieve that?
Before we jump into this discussion, let’s define the three main terms discussed here as they pertain to building great products:
Before we discuss some great project management practices, let’s examine what product development looks like when there is an imbalance of emphasis between scope, quality, and budget. This usually results in products that are half-finished and just not ready for prime time.
The scenario in which we tightly control the budget and keep the quality high at the expense of a set scope is not that unusual and appears, seemingly, pretty welcome: it shows that we are all aware of feature creep (the inadvertent adding of desired features during development) and would rather develop and thoroughly test a few key features, rather than squish as many things into our product as possible. In reality, this is much more tricky because it assumes that our Partner thoroughly understands the needs of their users and has carried out full UX testing before coming to Intent. In our experience, that is usually not the case and a lot of the assumptions our Partners have at the get-go, after undergoing the UX Discovery Phase, turn out, surprisingly, different from the previously held. Monitoring budget and quality during product development are crucial, but a product with features not corresponding to end-user needs will falter. That is why we always encourage our Partners to take advantage of Intent’s user-testing experience when starting work.
Probably the most common scenario in our experience of working with clients is the situation where the budget is set and accompanied by a very ambitious, set scope. A lot of our Partners come to us with their scope fleshed out and calculated budget, though in our experience there is often little leeway to keep the quality good. We often find out that estimates which we receive from Partners at the start do not account for a lot of the fundamental practices that result in good quality tech: unit tests for features, no planning for even rudimentary documentation, or manual test case runs. At Intent, we help our Partners not only understand their user base and business needs but know exactly what quality controls to apply to avoid a buggy release.
Last, but not least, it goes without saying that you can create a great and really polished product when there are no budget constraints whatsoever - though that is rarely, if ever, the case.
At Intent, we have years of experience in all kinds of software and hardware projects, with Partners ranging from big household names to rising start-ups. Over the years, we honed a lot of internal and partner-oriented processes to help assure that we maintain a balance in the spheres of a software project’s scope, quality, and budget.
The main metric for project management at Intent is the Intent Project Health Score. The Intent Project Health Score is a scorecard with 45 different project metrics divided across the areas of Commercial, Team, Processes, Scope, and Quality. It draws on years of experience Intent has managing software and hardware projects, paying special attention to indicators relating to scope, quality, budget, and more. Every week project managers update it for all projects to get a scorecard with a total of 388 points. This allows us to assess how the project is performing with a single number as well as see a trend over time.
What accounts for the main drivers behind the scope, quality, and budget sections of our metrics?
Accessible roadmaps. All our projects have a roadmap that's updated regularly with scope progress, internal deadlines, as well as any external deadlines that our Partners have. This roadmap is always available to the entire project team and to our Partner.
Internal milestone setting. It’s very hard to manage scope over a period of more than a month when there are no set internal milestones in the roadmap. In projects that are several months long, we create at least monthly milestones, so that at the end of each month we know how we are doing towards the release. Based on that, we can make decisions to feel confident about the project deadline and budget.
Curated weekly reports. These have been an essential part of all our projects for years now. Every week, we send out a report to our Partners that has all the most important information about the project currently: what has been accomplished last week, what is planned for the next one, the status of the budget, and graphs with current product quality metrics.
Regular project progress demos. Every project has regular, either weekly or biweekly demos. We always encourage our Partner to attend to see first-hand the progress on the project. No worries, though, if the Partner cannot attend: we always send out the relevant recordings in those situations.
Maintained quality dashboards. Our quality assurance specialists maintain a project quality dashboard with all quality metrics on the project. It is the single go-to place to find out information about any known bugs with their priorities, all operating systems and devices the product supports, and access information to project environments.
Comprehensive unit tests. Unit tests are an essential part of our development at Intent. This type of automated tests performed by developers slightly increase the time needed to develop individual features of a product, but assures a controlled and stable project end-game and release. In our experience, projects that do not conduct unit tests appear like they are going smoothly, until the period right before the release when the convergence of feature releases results in regression, i.e. the reappearance of old bugs and accumulation of new ones.
Frequent test runs. The main job of our QA specialists besides making sure that developed features meet their business and technical requirements is to conduct regular test case runs. Our QAs keep logs of all actions feasible in the product and in regular intervals test the entire product to make sure that during the development other sections were not affected by recent additions or modifications of existing features. This can be treated as a warranty that allows the team to concentrate on new development without having to worry and coming back to already developed parts of the product.
Mandatory code reviews. All the code that a developer produces at Intent is always cross-checked by another developer. This not only assures an additional layer of quality but is a method to assure that all code is produced according to standard coding practices.
Use of alerting services. No matter if the product is destined for desktop, mobile devices, or even hardware, we always choose appropriate automated alerting services. Those not only alert the team to any irregularities in how the product runs 24/7, but also provide vital logs and information whenever a team member or end-user encounters a problem. Just by knowing the approximate time of when a problem occurs, we can easily find the reason behind an unexpected behavior and address it.
Baseline security standards. At Intent, we understand that different products have different threat models when it comes to security. No matter the type of project, however, we have stringent minimum viable security standards that we enforce across all projects, so you can be sure from the get-go that your product, and thus the data of your end-users, is safe.
Always updated designs. Oftentimes after the designs of a product are created, small UI changes during development for various reasons are desired and implemented. There is nothing wrong in that, but if the appropriate designs are not updated to reflect even those smallest of changes then it is very hard to track back and decide which version is correct later on. Clarifying this takes up time (thus, budget). At Intent, we assure that designs stay updated throughout the project to remain as the single source of UI truth.
Final design reviews. When getting closer to a release of the project, we take up our UI designers to do a design review of the implemented product. This assures really the highest visual fidelity of the UI layer and animations, as sometimes very small or subtle differences can escape the notice of the development team and Partner for a long time.
Shared FTE budget counters. Dedicated project managers update the budget tracking document every week and share it with the Partner. It is very important to us here at Intent that our Partners are always aware of currently accrued and planned costs and we strive to provide full transparency in this regard on a regular cadence.
Common understanding of deadlines and releases. At Intent, we pay special attention to understanding our Partner’s needs related to the final release of the product to end-users. We foster a common understanding of that process and its result from the very beginning of the project to avoid different expectations of what's going to happen during and after release.
Product owner support. Depending on the nature of the project, Intent project managers are either scrum masters or product owners of the developed products. When our Partner wants to play a more active role in the project and wants to help the team save time (and budget), we offer all necessary tools, training, and access to facilitate our Partner’s active involvement during the development process.
When creating great products you need to be able to strike a balance between a scope that fulfills the main mission of the product, make sure that the quality allows for good end-user experience, and assure that the project budget is kept in check. Too much emphasis, no matter how well intended, on one or two out of these three elements results in unbalanced product development. That, in turn, creates products that flounder, are over-budget, or delayed. Here at Intent, we provide our Partners with the know-how, transparency, and tools to assure that the end product becomes a success.
Designing a successful digital product from the ground up requires the right teams, communication, and execution strategies. However, even for organizations with all these requirements in order, producing error-free software is a near impossibility.
Maintaining software quality throughout the duration of the SDLC (Software Development Life Cycle) requires various methodologies and design principles coming together to maximize efficient execution. And while each development project has its own set of demands and scope, certain quality assurance elements can be applied across multiple project types.
Below, we'll cover seven steps you can take to improve your software quality significantly.
One way to ensure your software development project stays in alignment with company objectives and meets the needs of your user base is by deploying "SMART" goals.
SMART is a goal-setting framework that includes the following attributes:
In software development, your customer journey can be likened to a roadmap you need to follow from start to finish to ensure your product users receive value from the product. Maintaining a clear vision of this mapping throughout the entire SDLC helps development teams visualize the end result of each development phase, ensuring a customer-centric approach to quality assurance.
Customer journey testing ensures you're considering all customer personas when developing your products. This includes customers who have high demands for mobility, those who require certain levels of accessibility, and others who have specific preferences when it comes to application navigation and usability.
Another way to ensure you're giving your projects the due diligence they need when it comes to quality assurance and software integrity is by deploying a continuous testing strategy.
Continuous testing brings automation to your quality assurance processes by executing regular testing cycles as part of your software delivery pipeline. Continuous testing helps to significantly minimize the chances of releasing products too early and establishes a safety net before product launch that identifies when a product may be too risky to launch or requires additional testing and validation.
Continuous testing allows development teams to create and execute stable test environments that validate test data before it goes through to the next stage of development. This method of end-to-end testing allows for actionable insight at each development stage and results in a high-quality user experience while eliminating redundancies in the development process.
The most successful digital products are produced by teams that know how to communicate effectively. It's easy to say that proper communication is the key to success, but often it's hard to define how this should be accomplished.
Effective communication can take various forms, and there are many different ways this can be accomplished whether your teams operate locally or remotely. Regular strategic planning sessions, project timeline reviews, and team meetings are all great ways to ensure your projects remain on task. It's also important that your company stakeholders stay in the loop on project milestones and are able to inject their thoughts and ideas at relevant stages of the software development process.
Near the final stage of your software development process, it can be beneficial to deploy UAT (User Acceptance Testing) to ensure your software meets the requirements of your users. When deploying user acceptance testing, organizations arrange for a small group of users to perform specific tasks that highlight the software's functionality. This scenario aims to quickly identify issues in the software that can be addressed before product release or recognize low-impact but lengthy updates that may be needed further down the road.
One major mistake that many development teams make early in the development process is making security a secondary consideration when it comes to the form and function of their digital products. While strong security protocols in software development projects can start to impact the user experience to a certain degree, it can be detrimental to the project's long-term goals not to have a strong focus on security when building software. Adopting a DevSecOps approach can be a great way to ensure security awareness and goal setting becomes part of your development processes.
When gauging the reliability and accuracy of your software development process, it's vital to rely on key metrics that help you identify if and when there may be a problem. Depending on the type of project you're planning and executing, you can track any number of relevant metrics. Some of these metrics include:
Developing your digital product from the ground up requires the right team with the right skillsets. However, it also requires careful due diligence when it comes to the quality of your software. By following these seven steps, you'll be better equipped to release a digital product that maximizes user value and minimizes costly software revisions.
Software development partnerships have become a big part of the digital product industry. Companies realize just how important it is to develop relationships with other businesses to enhance their own products, grow their customer base, and stay up-to-date on trends in technology.
But what steps can you take as a digital product brand to get more out of your software development partnership? We're going to discuss that below.
Weekly check-ins and monthly meetings, with feedback on the previous period's accomplishments, as well as goals for the next month, are a great way of staying on top of your software development partnership. Doing this helps ensure that deadlines are met, deliverables meet your expectations, and both parties remain informed during all stages of the process. Once you've established these accountability rituals with your software development partners, it will be easier to get more value out of each of your engagements.
It's essential to have a clear vision, measurable timelines, and milestones when building a new software development partnership. This gives both parties a unified understanding of all objectives, how to achieve them, and the accountability they’re associated with.
You should establish regular meetings with goals that are achievable within smaller sprints throughout the year, as well as longer-term objectives. These meeting times will allow both parties an opportunity to share the progress they have made towards each goal or milestone and adjust accordingly if any need arises.
Setting goals and milestones at the outset also ensures that you're both on the same page and defines each of your responsibilities within this partnership. This will help make sure that deadlines are met, deliverables meet the expectations of key stakeholders, and both parties feel a sense of accomplishment throughout all stages of the software development lifecycle.
Sharing knowledge is the key to getting more out of your software development partnership. Whether you're a blogger or an application developer, engaging in conversations with other professionals will lead to new ideas and innovative collaborations that can help both parties grow.
Additionally, if you work on a project with someone who does something that your company doesn't, it's important to share resources so both of you can learn from one another.
It's essential to make sure your budgeting needs are clear from the beginning so that you can stay on top of your cash flow. Are there any extenuating circumstances or substantial financial uncertainties? These are things that should be discussed before starting a project with an outside party and need to be addressed early on for both parties to get the most out of their relationship.
When it comes to software development projects, the scope of work should be outlined from the very beginning so that there are fewer surprises later on. While budgets may, from time to time, need to be stretched, by outlining your budgetary expectations at the start, you'll minimize the need to move outside of your financial comfort zone.
Software development lifecycles can have a certain level of unpredictability. This is why it's essential to remain flexible while you work with an outside development group. Whether monitoring deadlines, budgets, or specific ideas regarding the final execution of a product, keep an open mind when it comes to subtle changes in outcomes. So long as you've chosen the right partner, sometimes, change may lead to much better things.
It may take time before your software development partnership starts bearing fruit and seeing benefits from one another, and you should expect those kinds of fluctuations. Make sure to work together with your software development partner to solve any obstacles that arise and communicate any concerns or issues on both sides of the relationship.
Before you start a software development partnership, it's essential to know your partner and their values. This will help ensure that both parties have the same expectations for each project.
For example, an application developer might insist on using open source libraries in all projects, while another company may strictly use proprietary code. These values should be aligned appropriately before starting a project to ensure there is a good fit and that both parties can get the most out of their software development partnership.
Every company is different, and your needs for a software development partnership will differ as well.
Certain development companies have different strengths and weaknesses. Be sure to understand whether or not the company you're choosing to work with truly understands the space you're in and the vision you have for your digital product. Differing perspectives can actually help to bring more balance to a project, but if both companies are moving in different directions on a project, the final product will suffer – so will the budget. So when identifying what kind of software development partner you want to work with, make sure you're also identifying what sort of partnership your company really needs.
Partnerships are, by nature, a two-way street, and you should consider what you can offer in return to the relationship you're establishing.
When entering a new partnership with a software development company, one mistake many businesses make is taking a "hands-off" approach when planning for and launching a successful product. On the contrary, building the right relationship with your software development team takes communication and support. Remember, the more you put into your relationship, the more you will gain.
Pairing up with the right software development company can be one of the best things you do for your business. However, it's not always easy to find someone who you can trust long-term. By following these helpful tips, you'll be sure to get the most out of your software development partnership and ensure your projects are well-executed and within budget.
Building a successful digital product from the ground up requires careful planning and execution, both of which take varying levels of communication between executive leadership and development teams. However, when tasked with long-term projects, it can be challenging to execute all development needs without a clear picture of all of the tasks at hand, realistic budgets, and acceptable timelines without the right documented plan.
Below we'll discuss how developing a product roadmap can help you and your organizations better prepare for project execution and how you can create one effectively.
When it comes to software development, product roadmaps are constructed as step-by-step visual plans that outline all relevant goals and milestones involved to get a product from concept to final design. Often, the scope of a project may seem too large to tackle without segmenting tasks into smaller, more manageable project components. Product roadmaps provide an easy-to-digest, actionable outline to follow, ensuring all members of a project have clear goals they can follow to contribute to its completion.
Product roadmaps are a great way to bring teams together on a project, giving developer teams, marketing teams, company executives, and stakeholders a transparent view of a project vision and the goals needed to achieve it. This helps to foster a culture of communication, focus, and brand alignment that results in better teamwork and improved product deployments.
Below we'll cover five key components of a product roadmap and what you need to make it successful.
The first stage of a product map is to define exactly what you're looking to accomplish. This could be a new digital product, idea, or improvement that needs a strategic plan to execute. This stage can also be referred to as a project summary and can be an invaluable element when it comes to getting stakeholder buy-in for the project.
It's important at this point to present relevant answers to questions about your product:
Answers to these questions and others like it will help ensure your project goals and strategies are well-documented and put the project's scope in perspective.
Establish Timelines
Project timelines are the lifeblood of your product roadmap. They ensure tasks are completed on time and that all relevant parties have a sense of the high-level priorities of the project. While these timelines aren't necessarily set in stone, they can help keep teams accountable for finishing their individual tasks on time as they help visualize all cross-departmental needs.
Timelines are typically one of the more visual elements of a product roadmap, often represented as a Gantt chart that stacks individual project elements onto another, showing sequential tasks to take place from left to right. An important note for developing timelines for your project is that you should plan them in shorter sprints. For example, timelines scheduled for 3-6 months show 20% better prioritization than projects spanning six months or more.
Product roadmaps should be built to prioritize elements that have desired outcomes and measurable results. The goals you set should be measurable with specific milestones that identify whether or not a project is staying in alignment with the initial vision set out.
Depending on the type of product, there may be a number of metrics that can be used to ensure you're meeting both your customer and business needs. For example, software development teams may use metrics like customer acquisition costs, recurring revenue, conversion rates, or other application metrics that highlight success. These can be implemented and monitored at different stages of your product's long-term roadmap to ensure you're hitting key milestones along the way.
An essential part of your product roadmap is budgeting. However, establishing a budget for a long-term project isn't always easy, and many organizations aren't sure how they should start documenting the process. One way to do this effectively is by identifying project benefits vs. cost considerations and using them to drive decision-making in this area.
Project benefits can range considerably in scope and strategic value, including increased revenue, improved long-term cost efficiency, better brand engagement, and any other measurable improvement for the business. When measuring whether or not a certain product feature will be worth the development effort, you can measure the implementation efforts, operational costs, and project risk with the perceived value of the initiative. If the benefits outweigh the cost, this should be added to your overall costs outlined in your product roadmap.
Product roadmaps are invaluable to keeping a project on task and ensuring multiple teams understand the overall vision. However, they also serve as a great tool to use when securing buy-in from necessary stakeholders in the organization.
Product managers often have to present ideas to a wide range of audiences. A product roadmap, if appropriately structured, helps to identify the value of new projects and effectively communicate the status of ongoing projects. In addition, since stakeholder buy-in is often needed to approve a particular budget, a well-drafted product roadmap with measurable objectives, documented timelines, and clearly outlined business benefits will give stakeholders all relevant information they need to approve the project.
Product roadmaps have become an essential component of all successful product launches. They not only provide the level of detail necessary to communicate the total value of a project, but they play an important part in keeping teams connected, on task, and in alignment when executing all areas of a project.
By following these steps when constructing your product roadmap and ensuring you secure the necessary stakeholder buy-in, you'll be sure to infuse more productivity into your projects and encourage more collaboration within your development teams.
Development projects rarely go as planned, especially when they're centered around evolving digital landscapes. Whether intending to design an original program or craft software updates for existing platforms, developers have the unique and challenging responsibility of managing complex products used by any number of people worldwide.
This reality makes the work of most software development teams open to experiencing specific roadblocks or detours during long-term projects. However, while many programming teams regularly experience delays and budget overruns, mitigating these issues is key to ensuring successful and meaningful project execution.
Besides the apparent benefits of sticking to a plan, creating innovative products, and saving money while doing it, these overarching goals are shockingly difficult to achieve across many industries. Time and budget overruns occur so frequently that they are anticipated in many companies' operating procedures. Over two-thirds of enterprise IT projects run over budget by as much as 100 percent. Typically, only a quarter manage to reach release within 25 percent of their original project budget.
Given the complexity of general software development, as it includes conceptualizing, specifying, designing, programming, documenting, testing, and refining–it's clear as to why these overruns occur in the first place. When developing programs while following company and industry protocols, engineers are bound to experience delays and encounter unexpected costs to deliver intuitive products.
When a team is equipped with the following best practices, one can only imagine the potential for productivity and creation in software development. While employing project management, detailed planning, and effective communication, programmers can significantly advance individual projects, companies, and the industry as a whole.
There's virtually nothing better for sustainable productivity than investing in a project management team for your software development project. As specialists in initiating, planning, monitoring, and controlling activities required to fulfill project commitments, project managers are equipped with tools to transform the efficacy of workflows, documentation, and results. While project management is applicable in nearly any field, it has been used extensively amongst engineering teams. Given the multifaceted nature of software development, there's no doubt that a portion of your team should include seasoned project managers to keep you on schedule and budget.
A significant prerequisite to beginning work on software development is understanding the project requirements or what users expect the software to be capable of. These needs are then met with solutions, designs, and building plans to construct programs that execute the necessary tasks. Without these requirements or overarching project goals, the actual programming can't begin.
With that said, it's best to offer this information to the development team as soon as possible to allow for feedback, questions, or initial problems with the project's direction. As soon as these requirements are approved and solidified by the developers, it's best to let them begin writing code. Clear and thorough requirements should provide them with as much information as possible, providing more uninterrupted working time.
Especially when planning rather lengthy and intensive software development projects, it can be much easier to generalize some aspects of the timeline, budget, and other constraints. However, it's essential to provide an estimate of these details, seeing as they will ultimately affect how your team even begins to approach the project. Completing extensive planning when setting out on a new software project minimizes the likelihood of "scope creep," or the addition of desired features beyond what is defined in the original project requirements.
With the help of project managers and focused developers, deadlines and milestones can be set with complete transparency and a greater possibility that they will be met.
It's never ideal to start planning for delays, but it can be risky for project timelines to go without any pre-established buffers in place. Simply put, project buffers offer a designated amount of additional time to an individual task. These cushions allow developers to breathe more easily amid tight timelines, as a delayed task will not affect the overall project schedule. Better yet, breaking up project tasks into smaller, more flexible sections offers team members some leeway should they encounter unexpected issues or have to prioritize another task.
When in doubt, project buffers make work processes and timelines much more comfortable for all those involved. Not only do they ensure that the most critical deadlines are met, but they take the inherent challenges of software development into account.
With a detailed project scope–including a timeline, budget, and other constraints–be sure to recruit talent within your development team with their skill sets in mind. Depending on the project needs, assess each programmer's professional and personal attributes and determine who might be best suited for specific tasks and objectives. Setting team members up for success by allowing them to focus on their strengths will ensure an efficient and enjoyable working process for everyone on board.
In virtually any context, effective communication can make all the difference. But when it comes to software development, many moving parts of a project can become perfectly aligned when all team members are transparent about their progress, challenges, and successes. While more formal meetings may regularly allow for structured discussions, more informal check-ins can let developers ask lingering questions, consult team members, and build better working relationships.
Of course, effective communication is only valuable when it happens frequently. Additionally, regular and productive discussions about projects can introduce accountability to the working environment, instilling motivation to complete individual tasks efficiently.
There is no surefire way to keep a project from breaking the planning constraints, but there are certainly ways to mitigate the risks. With the many project management tools available and a suitable working environment to support them, software development teams can be better equipped to navigate projects precisely as planned.
For many startups and growing businesses, knowing how to get your product up and running while minimizing risk can be a challenge.
These are all questions that keep business leaders up at night. And getting to the bottom of each of these concerns takes the right approach when it comes to launching a successful product development project.
Many businesses find that the best way to address each of these questions is by creating an MVP (minimum viable product) to validate their product ideas and ensure they are executed properly. But what steps should organizations take when following this path?
This article will help you understand the importance of MVPs when it comes to new product launches and the 5 steps you need to know when beginning a development project.
An MVP (minimum viable product) is a basic, launchable version of a product. It supports the minimal, must-have features of a product, which attracts early adopters and validates the viability of a conceptual design early in the product development lifecycle. In industries supported by software development, MVPs are incredibly valuable because they help the product team receive user feedback quickly and early in the process, so they can ultimately improve the product.
Below we'll address the five critical steps you should be taking in order to execute an MVP successfully.
If you’re developing an MVP, you’ve established the core concept of a product you want to create and are taking the steps to make it a reality. The MVP will be the basic version of the product that you launch, giving you the opportunity to improve on it as needed. Doing market research in advance will help you assess the viability of your new product or service before you begin development.
During this phase, use surveys, product tests, focus groups, etc. to gather information about your ideal customer base. Unfortunately, some ideas simply do not fit market needs. In fact, lack of real product need accounts for more than 40% of most startup failures.
Before you initiate an idea and begin to develop an MVP, check to see if it fulfills the target users’ needs. The more information that you collect about your users, including their demographics, their likes and dislikes, devices they use, and their overall product needs, the greater your chances of success.
Having completed market research, you should have a clear idea of what the users’ problems are to solve. Ask yourself, “How can I make this product most valuable to my customers?”
This is your primary goal, and all of your actions should be based on this. The next step is defining a user flow. The user flow is the path taken by the prototypical user on a website or app to get the desired result. Understanding the user flow will help you to define the required features of the MVP.
After creating your user flow, list out the features of your product and prioritize them by importance. A good way to categorize the features is by creating a table with three columns: “must-have,” “nice-to-have,” and “additional.”
Going through this planning stage will help you to understand the goals and process before beginning to build and launch your MVP.
After you’ve created a plan, you’ve arrived at the development stage. With the help of the Lean Startup methodology, you can continue on to the MVP creation process using the Build-Measure-Learn (BML) feedback loop. Here are the cycle stages that can help you launch your plan:
Build
In this cycle stage, you figure out problems and define how to create a minimum viable product that will solve them quickly. There are four different options to choose from for development:
After you’ve built your MVP, you can move onto the next two stages, measuring and learning.
Measure
This stage is where you determine if you’ve made real progress. You can use your Customer Acquisition Cost (CAC) and Average Revenue Per User (ARPU) sales metrics and their correlation to determine whether it is profitable to continue the development of the MVP. You can also utilize Google Analytics and Hotjar for your website to see your traffic, conversions, etc.
Learn
In this stage, you launch the product you have built and collect the users’ feedback for future improvements. You have to determine if that feedback means you should persevere in the direction you’ve started or pivot and change certain features. You may also determine that you need a new development strategy.
In the third step, we talked about the different options you have to develop your MVP. It’s important to note that not all are created equally. In fact, collaborating with an experienced MVP development team can help you save costs and launch more quickly, compared to struggling to work out the kinks yourself. By releasing your product earlier to your competitors, you have increased your chance of being competitive in the market and beating out your rivals.
For example, if you work in software and you want to build an MVP that offers basic functionality, then working with an established company will help you to accomplish your goal much faster due to their vast experience and in-depth industry knowledge.
If you initially go in the wrong direction (freelancer, in-house developer, etc.), and you need to redirect, then an MVP development team can always provide you the expert assistance that you need to improve the project.
When you build an MVP, you build it off of features you feel are most important to your customers. As soon as it lands on the market, you'll be able to quickly assess if you stayed on track with these goals. At this point, it’s all about what your users think. Now, it’s your job to collect ‘real data’ after you launch your MVP, so you can measure whether or not your product was successful and how it can improve. Here are some of the metrics you can look at to gain this insight:
MVP development is an important step to take when you need to validate a product concept quickly and with minimal investment necessary to move forward. By following these five steps, you'll ensure your design project takes the right user-centric approach and you gain the valuable insight you need to build a long-term viable product.
When organizations begin developing a digital product, the primary goal is often to ensure the finished product meets the end-user's needs and can be improved over time. While the purpose of these development projects may be clear enough to the organization at their inception and throughout the software development lifecycle, there are various paths organizations can follow when trying to execute them effectively.
When considering how a project can be effectively executed, organizations often hear the terms "Design Thinking" or "Design Sprints" concerning taking a concept or idea and turning it into a tangible product. But how do these terms compare with another? Are they the same idea, or is one a more effective process when bringing your digital product to life?
Below we'll define the different terminologies when referring to product design & development lifecycles, including how they differ, how they're alike, and when each should be applied.
While the terms "Design Thinking" and "Design Sprint" are both closely aligned with the conceptualization and execution of an innovative product, they are separate elements of the process and used in different contexts.
Design Thinking is a methodology that can be applied when developing products that focus on innovation while continuously keeping the user experience at the forefront of development priorities. This is done by identifying any user pain points and using creative problem solving to help you draft a sustainable framework for successful development.
A Design Sprint is a formulaic approach to compressing the Design Thinking process into a 5-day execution. Design Sprints are used to verify ideas or features while creating a tangible prototype within a short amount of time. A Design Sprint encourages cross-departmental collaboration and focuses while also catering to open-minded thinking, creative problem solving, and increased accountability.
Design thinking is highly effective when searching for innovation or adjusting solutions to the users' needs. It should be used to simplify different prioritization techniques. The design thinking can be applied by keeping to a 5-phase process created by the Stanford d.school:
Phase 1: Empathize
The first phase of the Design Thinking process is Empathize. This phase is all about getting a better understanding of the users and is done in various ways. This can include:
Phase 2: Define
The second phase of the Design Thinking process is Define. Once the appropriate information has been collected during the first phase, you can define and synthesize all the information collected. At this point, you'll want to document each of the significant challenges that users face and how to choose the top ones you want to solve.
Phase 3: Ideate
The third phase of the Design Thinking process is Ideate. In this phase, the participants will want to think of broad ways to address the challenges identified in the second phase. This is a highly creative phase in which the participants brainstorm ways to tackle user issues by thinking outside the box and sharing their ideas on addressing the crucial problems.
Phase 4: Prototype
The fourth phase of the Design Thinking process is Prototype. While prototypes can be in many different formats, in digital product development, it often comes in the form of a functional mockup with basic features that showcase the capabilities of the software. During this phase, the goal is to create a simulation of the final product while presenting a platform that can be used to collect relevant feedback for the final development and future improvements.
Phase 5: Test
The fifth and final phase of the Design Thinking process is Test. Once the Prototype has been developed, it's ready to be tested with a focus group of users to get their unbiased viewpoints and reactions to the product. The testing phase is typically an iterative process and is used to inform a series of ongoing changes and edits.
Design Sprints let development teams verify an idea and test while gathering feedback on a rough prototype in record time, allowing you to weigh user reactions before making expensive commitments in lengthy development projects.
Design Sprints are derived from the Design Thinking process and provide a battle-tested, revolutionary framework for effective feature testing of development projects. This framework is built on a 5-day format and helps to reduce the risk when bringing products or services to the market.
Here is how the framework looks:
Day 1: Understand
On day 1 of a Design Sprint, development teams review the scope of the project and identify all relevant goals.
Day 2: Sketch:
On day 2 of a Design Sprint, teams get together to brainstorm new ideas and start developing priorities for how to sketch solutions to problems discovered.
Day 3: Decide:
On day 3 of a Design Sprint, teams review all sketched ideas and solutions and agree on which ones should be storyboarded and moved to the prototype stage.
Day 4: Prototype
On day 4 of a Design Sprint, development teams decide on what should be built to gain the right level of feedback for the project's future success. This is an accelerated prototype based on your storyboard and isn't designed to be perfect. The primary goal is that it is visible and functional enough to test with your users.
Day 5: Test
On the last day of a Design Sprint, a functional prototype is used for testing with a small test group. TThis is typically no more than five individuals, one-on-one, who are then interviewed to give the development team a general feel of whether or not the product meets the needs of the user.
Both Design Thinking and Design Sprints are essential elements for designing successful products on time. While Design Thinking is the methodology and foundation needed to understand the needs of a project and the end-user, Design Sprints provide an effective framework for solving the challenges by designing and testing the right solutions.
Intent is a purposefully small agile development company specialized in delivering products and MVPs at the intersection of physical and digital. During our selling processes, some of our potential customers asked us who we wanted to work with. The first time we met this question, we, of course, gave an answer, but it was crude, and we were unhappy with it. After the meeting, our growth department met to discuss the issue thoroughly. So who do we enjoy delivering our software and hardware solutions to the most?
One of the most important things is that the potential customer asked us about our needs. Being concerned about those takes you halfway to becoming our dream Partner. You don't come to us just to get the best quality. You know that being mindful of our needs during the process will ultimately help you achieve the best service possible.
The second most important thing to us is that the potential customer trusts us with the budget. The negotiations sometimes might get emotional, but you should never forget that if you want,
It might be quite a stretch for the whole agile development team we dedicate to your project. And stretching in business, as you well know, usually means stretching the resources too.
When the other agile development company offers you better conditions, just compare the quality of the products it delivered, the quality of their tender deliverables and the rapport they built with you. You will usually see that if the price is lower, the mentioned factors are of lower quality too. You might also learn the hard way what overpromise and overinvested marketing mean.
WHY TRUSTING INTENT PAYS OFF - A SHORT CASE STUDY
An example of the Partner who trusted us with their budget during their agile product development is Lover. Trust is always mutual. If the Partner trusts us, we trust them. In Lover’s case, trust was so strong that we invested in them after we finished the work. A few months later, Lover raised a $5M seed round from Tinder’s Founder, Sean Rad, Lerer Hippeau and other notable VCs.
Our dream Partner is not up for a short affair with us. Of course, first, they usually want to try us with a smaller project, but, from the very beginning, they are seriously looking for long-term cooperation. The longer we work together, the better our agile development team knows the Partner and the better projects they can deliver together. The Partner learns what we are best at and can align their projects accordingly. On the other hand, we learn from the Partner how they work, soak in their brand's DNA and explore all the nuts and bolts that allow us to deliver more and more perfect projects each time.
We clearly state this when we begin our cooperation. If you know what you want and have everything planned to the smallest detail, we might not be an agile development company for you. We are not soldiers; we don't only act. We think about the actions that have the most sense in the setting we are in, and we sometimes question the Partner if we believe our solution might be better. Questioning the Partner means that we are always up for a discussion to find the best idea when we have second thoughts about the Partner's proposition.
Of course, we have created over 160 standalone applications, but our agile product development process really shines at the intersection of hardware and software. We call it PxD (physical x digital) for short. Here is a short case study to complement our statements.
WHY CHOOSING INTENT TO DELIVER A PXD PROJECT IS A WIN-WIN SITUATION - A SHORT CASE STUDY
We helped Oura achieve the app parity and implemented several other features. After working with us, the company raised a follow-on $28M Series B from Forerunner Ventures, Square, and Google's Gradient Ventures.
As a result of our workshops, we have enhanced the world's first wellness ring and mobile app that tracks sleep, activity, and physiological responses in your body. Oura ring enables you to learn how your lifestyle choices affect your sleep and how your sleep quality affects your ability to perform.
With our extensive expertise in cross-platform technologies and integrations, we've managed to seamlessly connect the Android application with Google Fit, integrating the user data from Oura and Google Fit.
We are proud of the culture we cultivate at intent, and it is important to us that our employees respect it and make their own. If then, the Partner has a culture that is compatible with ours, the work naturally goes much smoother.
Below you can learn what our values are and so, check if our companies are compatible.
WE THE PEOPLE
Geeks, yogis, fighters, tech freaks – a jigsaw puzzle where every piece somehow adds up to an A-team-level. We’re there for one another. We genuinely care and have a hell lot of fun together.
TAME THE ELEPHANT
We don’t mind doggies, but when there is an elephant in the office, we’ll sure make noise about it! We know all too well that problem-solving starts with sweeping the problem from under the carpet. We give feedback and always want to hear it, the good and the bad alike.
OWNERSHIP IS A SHIP WITH A CAPTAIN
Trust is a given around here. We believe it to be the setting stone for autonomy and ownership. Have an idea or a project?
You know what they say: ships are not built to stay in the harbor. Be the captain, set sail, don’t give in to the first iceberg.
WHAT IS THE BOX?
Think outside the box? What even is the box? We question, we challenge assumptions and we redesign the box. We exercise creativity as a conscious approach to our work and believe that it goes hand in hand with mind wanders. Unlearn the default.
IT’S A MOVING TARGET
It’s our ever-hunger for knowledge and innovation that makes us stay on top of the game. We have a thing for experiments and we adapt swiftly. We’re not scared to take risks because we know priceless lessons come from successes and failures alike. Learning is the name of the game.
An exciting project, a good atmosphere, and a generous budget are always great, but if our agile development teams can't grow during their work, we won't ever become the best versions of ourselves. That is why it is crucial for us to take part in the projects that will help us grow. Our growth is especially beneficial to the Partners who plan to commit to a long-term working relationship or return to us with their next projects.
At intent, we specialize in creating MVPs. We have delivered more than 50, which gathered almost $0.5B in funding to this day. We have also developed a large arsenal of methods to make MVPs, from which the Design Sprint seems to be one of the most versatile. How to build an MVP, then?
Before we answer this question, let us define some terms so that we are on the same page.
At intent, we understand the MVP as the smallest collection of the product's features that realize the end-users' needs (in line with the Product-Market fit). Building an MVP means delivering a product with crucial functions while spending as little money and time as possible. We have grounded experience in building MVPs from scratch to launch and beyond. We also understand the startup ecosystem's pace; we know the realities of early-stage companies: you have to satisfy its investor, co-founder and customers. And they all have different needs! Through 12 years of our commercial experience, we have learned how to meet all of them.
According to CB Insights, 42% of startups fail because they don’t tackle marketing problems. They chase something interesting to them, not necessarily their end-users. While ideating MVP, we help our Partners validate if their insight is a real market problem. If it isn’t, we aid them in rewiring the idea to meet the Product-Market fit.
Design Sprint is a battle-tested workshop framework based on the design thinking approach. Its goal is to reduce the risk when bringing a new product, service, or feature to the market. It is a shortcut to learning without creating and launching a whole, complex application. So it is perfect for building the MVP!
It was invented at Google by Jake Knapp and perfected with more than 150 startups at Google Ventures.
Design Sprint is one of the best choices when:
As you can see, all these features define the common MVP building situation. With Design Sprint, you can also prevent the 7 deadly sins while creating an MVP.
The Design Sprint process consists of several stages. They are basically the same for the regular DS process and the DS for MVP creation process:
Collecting insights, benchmarking and market research
Defining challenges and producing multiple solutions
Choosing the right path and creating a visual user story
Creating an interactive prototype and preparing for testing
Gathering and analyzing feedback from target users
Design Sprints we carried out resulted in 75% faster than the market average MVP delivery.
At intent, we never are only words. When we claim something, we have experience and data to back it up. Browse the following short MVP case studies to become a believer.
After we delivered the MVP to SWING, the company raised $5M from Black Jays and soon was acquired by Microsoft.
Polaroid SWING was a UK-based company that reimagined photography for the mobile era. They brought an entirely new visual medium to life: the moving photograph. Tommy Stalden and Fred Blackford founded the app and Twitter co-founder Biz Stone backed them up. Simultaneously, the man behind Instagram’s original filters, Cole Rise, was responsible for the creative direction. Intent co-created the SWING MVP and worked with the founders, their product, and development teams beyond the MVP. We helped SWING until the broadly covered acquisition by Microsoft in 2017. One of the intent’s back-end developers, who worked on the app, also contributed to the official Node repository.
We supported SWING in building their server infrastructure too (which reduced the server costs by 37%).
We cooperate with SWING’s founders to this day by supporting their efforts around the new ventures.
Watch SWING’s showcase to learn more about the app which intent helped create and shine.
Block has raised $17M in Series A from several New Enterprise Associates.
Block simplifies the chaos and construction costs by bringing design, sourcing, and management all under one roof.
Intent's team went all the way from Poland to the Block's HQ in the USA to better understand the product and get a broader view of the client's business. We've fuelled Block with professional services consulting. This included transferring our lead developer to Block's team to help them grow further and help build out the engineering muscle.
Our partnership included significant involvement from our C-level at every stage of the way too. We owned the tech workstream and all its business angles while delivering a successful MVP, which brought 1M of sales in the first 6 months after deployment.
We continued with Block past the MVP stage of the project.
Lover raised $5M from Tinder’s Founder, Sean Rad, Lerer Hippeau Ventures and several other notable VCs.
Lover is a sexual health app that provides online therapy at a fraction of traditional psychotherapy costs, with no face-to-face conversations required.
Lover was an early-stage startup idea when they asked us for help. They had already had some code and a credible concept. Our entire team onboarded in 4 weeks and hit the ground running. We rose the product-market fit of the app while involving our C-level executives in the process.
Soon after our collaboration Lover raised their $5M. Intent also decided to invest.
Not only did we facilitate a full Design Sprint here, but we also provided Lover full MVP-as-a-Service, during which 2 developers we delegated to the project delivered at the power of 4.
We decided to go with this story because it’s the best to describe the Design Sprint for MVP process (and the Partner allowed us to share it in detail).
Today Goodify is an application focused on encouraging people to do good deeds every day, thus forming supportive, happier communities.
CORE PROBLEM
During our pre-sprint research, we have discovered that people actually withhold from asking for help. Psychological studies show that there are substantial barriers that hold people back from asking for help. Our major challenge for the MVP was to lower that barrier for Goodify users.
TACKLING THE ISSUE; THE PROCESS
Pre-sprint research; we conducted a series of interviews to define the problems and determine what the process of asking for help looks like in various organizations, foundations, and associations.
This provided a good basis for the workshop. As part of Expert Interviews, not only did we interview the Stakeholder and collect the team’s insights, we also went through the interviews conducted during the research and discussed the most important outcomes.
Workshop; the first step during the workshop was a joint discussion about the research results from the pre-sprint research phase. It was based on interviews with target users of the application as well as organizations focused on providing aid. This helped us understand and define the main issues.
During the lightning demos - which is an exercise focused on finding inspirations and useful practices - we reviewed different products on the market that are solving problems similar to our own. Inspiration presented by people from different areas of expertise provided interesting and extremely varied references, all of which helped us during the following stage when we started working on our ideas for the MVP.
Using the dot-voting technique, we quickly chose two ideas (instead of just one) that we wanted to prototype and test to find a final MVP. One of them was a classic form to request help, another a chatbot.
Prototyping; creating two prototypes instead of one during the sprint was a considerable time challenge. Nevertheless, we were able to prepare both prototypes in time, working on two solutions in parallel. The classic form was designed in Figma, while the chatbot was created using landbot.io.
Testing; we recruited seven people for testing from the following groups;
We asked the users to request help using both the classic form and a chatbot. The purpose of the tests was to check which of the two solutions would translate into faster task completion and an overall positive assessment of the experience.
A CONTENTED PARTNER'S QUOTE
“They’re easy to work with, organized, and have effective processes with a professional, customer-centric attitude. They also provide a lot of valuable feedback to improve product outcomes.”
Kristian David Elgen
CheerMeOn is a startup that wished to create an app, which would measure any goal a person might set for themselves. They knew that this was impossible, so they came to us with a shortlist of the objectives. We persuaded them that, for starters, they should go with one goal only. They agreed. And together, we developed a successful app.
It is not unusual that the Partner asks us to create an application with several functionalities. But seldom do we develop such a product from the start. The complicated software is hard to test and hard to pitch to the VCs. We had to create something small and simple at first, the MVP. We cut CheerMeOn’s initial idea down to setting and tracking progress for the weight loss only. To this day, the app is quite similar to the MVP and is thriving.
CheerMeOn is a simple weight loss tracker. The user puts in,
The app encourages the users to share their progress on social media too. Two psychological insights underlie this functionality. On the one hand, letting other people know about your targets makes you feel accountable; on the other, it triggers peer pressure from those who learned about your goal.
We used React Native and Firebase, joined with Hasura hosted on Heroku. Thanks to this conjunction, we could use a relational Postgres database with graphQL API instead of the NoSQL Firebase Firestore database. We preferred the relational database because CheerMeOn benefits from uploading the feed with posts and comments. This functionality is much easier to implement with the use of the relational database.
The Partner is so happy with us that we are still working together today.
One of our long-term targets is the further development of the application so the users could set various goals like quitting smoking, creating a habit of regular training and so on. Our other long-term target is making the app more and more engaging to attract new users faster.
The collaboration has been going smoothly so far. The Partner had his bold vision when they came to us, but as I already mentioned, they agreed to reduce it to just one goal. They trusted us fully, and we are very thankful for it!
During our bi-weekly sprints, CheerMeOn usually praised us. They were pleased with our job’s results and not really interested in the processes that led to them.
The genuine challenge we encountered while working with various Firebase projects was Cloud Storage Optimization. Below I will describe this problem based on an example from my experience.
Even though we didn’t have any Cloud Storage files, the indicator showed almost 425 MB of data.
Surprisingly, we found 63 objects in the Cloud Storage, even though we hadn’t kept any files there!
We went to https://console.cloud.google.com/storage/browser to find the Cloud Storage Buckets list. We have found the eu.artifacts mentioned above on this list. They were cache files that hadn’t been removed automatically.
Our further research showed that these files were connected to Cloud Function in Node Js v10 environment. More specifically, 4 small cloud functions (which had 10 to 15 lines of code). Each time we upgraded our functions (deployed them on the Firebase), new artifacts were generated.
To optimize this issue, you need to go to console.cloud.google.com (link above), choose artifacts bucket, and click on the lifecycle tab.
Then, you need to add a new rule, “Delete object.”
After you click “Continue,” you should choose “Age” and fill the bracket with the number of days after which the artifacts should be removed automatically (we have decided to go with 3). Press continue and confirm with “Create” button.
Thanks to learning this, we know we can reduce the cost of the projects that use Firebase. The free limit of Cloud Storage is 5 only GB and some projects can generate even a few dozen of gigabytes with the mechanism I described above. The knowledge and experience we gained allow us to give you a better price for the apps that we develop using Firebase.
When it comes to software development, different industries have different needs. Some companies continuously create digital projects, while others need new software only from time to time. Surely, though, both can benefit from hiring a remote development team to unburden them with some of the tasks.
IT LOWERS THE OPERATIONAL COSTS
For starters, hiring a remote development team is a significant cost-saver. It cuts the hiring processes' costs. You just need to pick the right company, and they will provide you with a well-knit team of developers proficient in the technologies you need. On the other hand, finding in-house developers with the right stack and integrating them into a smoothly working team is challenging.
The payment schedule is beneficial with the remotes too. When they finish the job, you don't need to pay them anymore unless you contract them for yet another project. When you hire in-house developers, you need to pay them regardless of the workload they get. As you can see, hiring a remote developer is a go-to practice for companies that do digital projects from time to time. However, the company with its own IT department can also benefit from hiring remote teams. Especially if they currently have too many projects on the table.
YOU CAN START WITH YOUR PROJECT IMMEDIATELY
Hiring processes are very time-consuming. Simultaneously some profitable projects cannot wait. It's the perfect situation for the remote team to come into play. They are ready almost instantly and can jump right into it within days. Thanks to them you can undertake some projects you couldn't tackle by yourself.
WHEN SHOULD I HIRE A REMOTE DEVELOPMENT TEAM?
You should also consider hiring remotes when the time for gathering and integrating the team is short. To hire in-house developers, you need to invest in their onboarding, recruitment and employee benefits. Also, hiring the right people usually takes from 3 to 9 months (plus notice periods). A remote development team is like a ready block that you add to your company. They integrate with your team through the project manager who knows the developers well and whose soft skills are top-notch if you picked the right company.
The other situation in which the shortage of human resources can be painful for your company is when the project you are doing is overwhelming for your current IT staff. Again - hiring a remote development team is a great solution. You can let them create the non-core functionalities while your in-house team delivers the essential modules only. Or, once the mutual trust is established, you can even outsource the full scope of the project.
A NEARLY UNLIMITED TALENT POOL
When you hire in-house, you are usually limited to the talent pool of the people closest to your company geographically. Even if your new employees worked remotely, you would like them to show up in your office from time to time. So when your business is in the US, your first choice wouldn't be a person from, for example, Poland (this country is ranked 3rd in HackerRank’s best developers and is closer to the Western cultures than the countries in the first and the second places). This is not a constraint while hiring a remote development team; you don't have to get to know these people. You can always finish the collaboration after just one project, regardless of the outcome. While deciding on launching a project with a remote development team, you get almost a limitless talent pool of highly effective, affordable and approved experts.
THE WORK AROUND THE CLOCK
Some projects are so big that no regular development team can handle them unless they don’t sleep. If you choose to hire a remote development team from the right country, the work on your project can go around the clock. Your in-house team (or one remote development team) operates during your workday, and the (other) remote development team engages in the project after the working hours (in a different time-zone), allowing you to double the effort in the same time frame.
MULTICULTURAL IDEATION
If you decide on hiring your remote development team from another culture, you get a different perspective on your project. People think and also code differently in different cultures. The clash of the different thinking ways might result in a fresh, unorthodox approach that could attract a broader audience than your initial ideas. Innovative concepts are also instrumental while designing MVPs.
1. PICK A TEAM EXPERIENCED IN THE PROJECTS YOU WANT TO DELIVER
Remote software developers usually have specialties. At first, always pick those who have already done some projects for your industry in a remote environment. Later in the process, you can supplement your choice with those who haven't worked with your industry yet.
However, they should have completed some projects similar to the one you need.
2. PICK A TEAM THAT EARNED YOUR TRUST
In business, there are many smooth-talkers. Unfortunately, there is no way to discern them from honest experts. You have to trust your gut feelings and choose a company that earned your trust in the preliminary talks. You can support this by going through their portfolios. Sometimes this stage should be more important than the previous one. For example, some might claim they have done a big project for a company from your industry, while in fact, all they did was support another company at it. As a result, they delivered some trivial functionalities that your project wouldn't need at best.
3. WHAT QUESTIONS TO ASK TO MAKE THE RIGHT DECISION?
At first, tell the team about the project you want them to deliver thoroughly. After that, ask the team a few questions about their experience. For example,
1. THE THINK PARTNER IS MORE THAN A BUILD TEAM
We always discuss the solutions we see with you, and we give you ownership of a part of our team. You don't leave the project to them; our employees join yours to deliver the highest possible quality while maintaining constant communication. Our approach joins the best aspects of hiring an in-house team and outsourcing the project.
2. A FIXED BUDGET
We work in a transparent FTE model. We precisely adjust the time we can spend on your project to your budget, and we don't cross the budget we agreed on in the scope of work (the document we create before we start the collaboration) unless we renegotiate it.
3. BATTLE-HARDENED AND EMPATHETIC PROJECT MANAGERS
On the one hand, they know their team very well; on the other, they have highly developed soft skills which help them deliver everything you need and can be delivered within your budget.
However blurry the product design term might be, we can say without exaggeration, that the design itself determines the value, functionality and usefulness of the product. The design process affects what users feel while using your product. In that way, it decides whether the final product is a real innovation or just another merchandise.
Some well-known frameworks provide very useful guidelines for the product design process. One of them is the Design Thinking framework by Ideo. The other - Double Diamond mapped out by the Design Council. However, no product design process works every time, so we rarely follow the strict order of steps in business situations. Each project is unique. It depends on: its main goal, product stage, requirements, the team involved and budget. That is why we don’t have a universal recipe for the product design process. What we have in intent is a list of phases we usually follow while building products with our partners. As you can see the design process can be quite intangible and yet it plays an important role in a product's success. That’s exactly why we decided to describe it in more detail.
At this stage, we want to answer the main question of each project: what issue is our customer trying to address? At the beginning of the project, we gather and analyze all the information about users, the business and the product (if it already exists). Getting to know the project, learning as much as possible about expected results, business goals and user needs is vital to coming up with better solutions and design later on. At intent, we use two main tools to gather all the intelligence we need.
This method helps us to establish the foundations for any project. It provides valuable insights about business goals, technical constraints, usability problems and more.
Interviewing stakeholders means asking the right people the right questions. It also requires working closely with the client from the very beginning, and so it sets some solid foundations for further successful collaboration.
This method is very effective in transferring knowledge, defining a project's goals and its roadmap. The workshops can take different shapes. They depend on the size of the project and the complexity of a challenge. A workshop can be a two-hours-long call with one of the stakeholders or a three-day-long meeting consisting of strictly defined exercises that engages people who hold different roles - stakeholders, developers, marketing specialists or even external experts. During the workshops, we run different exercises including Customer journey mapping, Business model canvas, Value proposition canvas, User story mapping, Empathy map and Personas. The choice of the most suitable method depends on the project’s specifics. Mainly, though, on the goal, we want to achieve. After every workshop, we prepare a report. We also put down some recommendations that include the next steps our new partner can take in the process.
All right, we have lots of information and assumptions about the product and its users. Now we should validate them. We need to find out the most about the product (if it already exists). To achieve this, we research its competition and the target group using quantitative and qualitative methods. Data-driven research should give a clear idea of ‘who, what, why, when and how’. The deeper this knowledge, the better the final result of the design process.
Since there are many different research methods, it is vital to know when to apply each of them. Conducting research takes time, but don’t even think of skipping this process. It provides great value to the product design and helps avoid costly mistakes.
Quantitative research methods can reveal valuable information about the state of the existing products and how people use them. When looking into Google Analytics, or any other analytical tool, it’s vital to determine what are the metrics we want to analyze. We might review for example traffic, conversion and user retention. It all depends on the goal of our research.
It’s important to keep in mind the quantitative data we get sheds some light on what people do on our website but not “why” they do it. We can explore this using the qualitative methods described later in this article.
An in-depth interview aims at collecting detailed information beyond initial and surface-level answers. Using this method, we can learn the details of the real-users’ perspectives and reveal the true needs of the target audience. This knowledge is crucial to creating a marketable product.
Surveys are a quick and relatively easy way to get data about your potential users. You can gather a lot of their thoughts without too much effort with the use of one simple form.
Very few businesses can be successful without keeping an eye on the competition. Competitive analysis is very important. It allows you to objectively determine where you stand in comparison to your competition and to spot any gaps in the market your product might benefit from. Benchmarking, on the other hand, clearly indicates who the top players in your market are. Thanks to this method, you learn who to borrow effective design elements from.
You can also run a UX Audit to quickly identify potential usability issues of your product. Professional evaluation of the user interface identifies imperfect areas of your product and reveals which parts of a website or app are a headache for their users. The UX audit provides a list of issues along with actionable recommendations.
Once we have a deep understanding of the problem and users’ needs, it’s time to develop a relevant solution. At this phase, we brainstorm and visualize ideas and then gradually turn them into tangible user interfaces. This phase contains several sub-phases:
We must create flows before we jump into designing interfaces. Every functionality a user sees is not just a screen, it’s a flow - a process that is driven by users’ goals and occurs in a specific behavioral context. Preparing flows speeds up the design process and ensures that there are no dead-ends for the users. Different methods can be used to conclude this sub-phase: user flows, task flows, story mapping and/or use cases.
Sketching (and yes - we mean pen-and-paper sketching) is a great way to experiment with different ideas and to communicate them visually to others. We love it because it allows us to spend more time exploring different screen layouts and testing hypotheses without consuming too much time preparing designs on the computer.
In this sub-phase, a designer usually prepares lots and lots of wireframes. The trick is to create rough but clear representations of the chosen ideas which can give us enough to be able to imagine the final result accurately. The main function of wireframes is to convey a few visions of a certain screen. After everyone agrees on one, we can proceed with the design process while avoiding confusion among the team members.
This sub-phase’s outcome is to transform the static designs into more dynamic ones. In the interactive prototypes, the screens are enriched by adding some user-triggered transitions. The great value of the interactive prototypes is also that we can use them to test our solutions with real users to check how they perceive them.
At intent, we are big enthusiasts of the iterative process which is based on continuous improvement. This ensures we build the best possible version of the product. The iterative design process is a simple concept. Once you develop a prototype, you test it with users to see whether it meets their needs in the best way possible. Then you take what you learned from testing and upgrade the design. Following that, you create a new prototype and begin the process all over again until you are satisfied. Depending on the project budget and timeline, we usually run one or two iterations.
We always try to test our prototypes with real users, before we hand them over to developers. It allows us to get quick, actionable feedback on the product and uncover any drawbacks and issues that need to be addressed.
Once all the screens’ structures and flows are approved and tested with users, it’s time for some final polishing. The main goal of this step is to deliver a final product design, that is visually pleasing, consistent and aligned with the branding. The product can also be enriched by some animations or custom-made illustrations that will enhance the users' experience.
This is usually the final step of the product design process. It takes place when the finished UI is ready to be passed into the hands of the development team. At this stage, designers need to collaborate closely with the developers to make sure that they have a mutual understanding and that there are no knowledge gaps. The designer needs to provide design files and all the necessary assets, including icons, flows, animations, validation specifications and edge-cases for this phase.
Now that you know how the backstage of our product design process looks like, you can see the number of different steps involved in it and that most of them require the participation of diversified specialists that are skilled in design, research, business strategy and problem-solving.
We cannot repeat often enough that the design process is not about building cool looking products. It’s about delivering solutions that bring value by fulfilling business goals and responding to users' needs. That is why it’s crucial that designing the product is managed by professionals who know how to run a foolproof process. It allows them to deliver the expected outcome quickly and most accurately.
Contact us, and we will advise you on what product design process would be optimal for your product. Together we can build an innovation that users love and share.
Working with an external agency (or even an in-house team) is not always a smooth and easy process. Whenever we ask designers to translate complex business requirements into beautiful and useful products, we often meet the most common barrier – the transfer of knowledge. So, how can you – a person with extensive business knowledge about your company – pass all of this information to the people who need it? How can you make sure that the design they create will meet your needs perfectly? The workshop is the answer.
Well, the sad fact is, none of us are mind readers, including designers. We are, however, experienced in extracting important information and knowledge from stakeholders and turning them into actionable points. This may almost sound like magic, but our most effective secret weapon is actually the humble workshop (and some research too).
A workshop, in contrast to what some people may imagine, is not about playing with post-it notes or brainstorming ideas. It’s a well-defined and controlled process that involves ideation, knowledge sharing, decision-making and prioritizing work.
And the benefits of this process are pretty huge.
THE BENEFITS
For example, well-conducted workshops:
But, of course, these benefits also depend on the persons involved in the process. Choosing the right set of people helps us make the most of it.
To get the best results, a workshop should include between 3 and 10 participants along with an experienced facilitator whose job is to make sure that everything goes smoothly – so that there are no ineffective discussions or disputes, and everyone is working towards the same goal. There are also two important rules to follow:
Plus, making sure that you are well-prepared will help you make the most of it, no matter how experienced you are.
The most significant part of preparation is to first clarify the most important goal of the workshop. Since this is meant to be an effective and time-saving measure, you won’t be able to do absolutely everything in these few hours. However, if there are many topics and challenges that you would like to cover, you can always carry out a few workshops. So, how do we handle this ourselves?
As you can see, the entire process is very different from a typical brainstorming session during which people are usually just tossing ideas around and the most charismatic person in the room gets their way. A good workshop is all about collaboration and working with various ideas to create something that works best for the determined goal.
However, we typically run a few different types of workshops in order to achieve the best results.
As stated above, each workshop can vary depending on its goal. We typically start by identifying a few important stages in the project, and then we establish when a workshop would be the most beneficial, and figure out the most effective way of working. Even though we customize workshop activities a bit based on individual goals, we also have some repeatable formulas to work with. Balancing customization and process automation is the key to success!
1. KICK-OFF WORKSHOPS
The main purpose of this initial workshop is to facilitate knowledge sharing and define the scope of processes at the beginning of every project. During this phase, the partner’s main interest can often be summed up with: “I want to develop an app with intent, but I also want to make sure they (the designer) understand what I do and what I want”. Well, worry no more, as this workshop is the perfect way for the partner and the design team to achieve a common understanding.
The kick-off workshops provide answers to a lot of questions, such as:
The kick-off workshop is also a great way to get to know each other and encourage team spirit. Some techniques that we can use during this event are: proto-personae, impact mapping or the impact vs. effort matrix for prioritization.
Results & benefits:
2. DESIGN SPRINTS
“I have a bold idea for a product, but I’m not sure if it is going to work client-wise or business-wise”. Ooh, this is a topic we love! Big challenges are our thing. We have an effective and tested method of tackling them – design sprints. This type of workshop was founded at Google and has been used by the most innovative companies in the world, such as LEGO, Slack, Headspace, and many more. This comes as no surprise since design sprints are really helpful in navigating the most complex challenges effectively.
Design Sprints last a bit longer than ordinary workshops, as they require 4 or 5 full days of work. During the first 2 days, our team and the partner’s team spend time on-site (or they can also do this part remotely), collaborating on ideas that are to be tested with real users within the next 2 or 3 days.
The formula is simple:
At the end of the design sprint, our partner has a working prototype as well as an answer to the critical question: will this idea work?
It’s a fun and, more importantly, an efficient way of validating business assumptions. You don’t spend weeks or months building your product only to find out that no one wants to use it at the end. Taking 5 days to test an idea at the beginning sounds much better than wasting weeks or months, doesn’t it?
Results & benefits:
3. PRODUCT IMPROVEMENT WORKSHOPS
What if you already have a working product, but want to make it even better? The answer, as you may have already guessed, is to hold a workshop! The biggest challenge with further developing an existing product is in toeing the fine line between improving on a good product and instigating so-called feature-creep.
The most common case of this for startups and more mature organizations is: the more people engaged in product development, the more ideas for its improvement and new features. But how can you distinguish between great ideas (that will have a real impact on user experience) from poor ones (that will just make the product more complex without any added value for the end user)? Of course, the main tool for prioritization should be a clear roadmap. But in order to create one, we need to hold an effective workshop to gather different stakeholders and discuss their expectations and ideas around the product.
This kind of workshop can also act as a great tool for discovering new business opportunities. When you map out your partner’s experience, from A to Z, you can easily spot bottlenecks and pain points that you can try to address in the future.
Some techniques that we use during this workshop are: the Customer Journey Map, Scenario Mapping, Design Studio and some prioritization techniques.
Results & benefits:
4. BUSINESS WORKSHOPS
Many people have already discovered that when they build a new business, they don’t have to spend days or weeks creating a business plan in an Excel spreadsheet that, in the end, will have nothing to do with what they actually need for their business. There are many lean methods that can help you quickly prepare a business plan to test and validate.
These methods – such as proto-personae, the Value Proposition Canvas or Business Model Canvas – are perfect for a one-day workshop. Just gather your (future) teammates and work together on creating a business plan from the ground up – a plan that you can later validate with research and prototypes.
Results & benefits:
The answer is: yes, definitely. As you can see, you can solve almost any problem more effectively with just a one-day or a two-day workshop. The types of workshops mentioned above are just suggestions, but you can definitely organize them however you want. There are many sources of great workshop techniques that you can find on the Internet, so just do the research.
The most important thing is to make sure that you have a clear goal and plan for the workshop before jumping into it. This will save you a lot of time and guarantee that you will meet your challenge or find some spot-on ideas.
And of course – if you need any guidance on organizing a workshop for your company, don’t hesitate to contact us!
When starting a cooperation with a software development agency, one of the most crucial decisions that must be made right off the bat is the selection of the appropriate pricing model. It's pivotal as it will have a huge impact on the whole project: processes, time-to-market, price, client's involvement and his comfort of work.
Up until recently, companies were choosing mainly between fixed price and Time and Materials (T&M) pricing models. Each of the models has its own strengths and weaknesses, and is appropriate for different project methodologies.
After a decade of working closely with clients from all around the world, learning how this business of expectations vs. outcomes work, we have developed and incorporated a new pricing model: Full Time Equivalent Engagement (FTE Engagement).
Allow me to detail the two most common pricing models first, and then, by comparison, show how FTE Engagement works and we think it's best suiting our culture and philosophy.
Choosing a billing model for a project does not happen in a vacuum and out of context. It should be a consequence of choosing a specific software development methodology along with its processes and deliverables, be it waterfall and agile (regardless of whether we are talking about kanban, Scrum or Extreme Programming).
For the sake of simplicity, each IT project consists of roughly 4 stages:
In case of waterfall, we move on to the next phase only once the former is finished, documented and signed-off. In case of agile, by contrast, all stages are run in parallel with sprints that tackle specific problems or functionalities, followed by the release of the latest working version.
The pricing model one chooses must correspond with the software development methodology. If you work in the waterfall model then you are probably doomed to use the fixed price contract. If, on the other hand, agile is your thing, you have mostly Time & Materials or FTE Engagement to choose from.
Fixed price means that you agree on a single, predefined sum for a specified scope of work within a certain period of time. To give you a real-life example, it’s like when you order a birthday cake for your daughter’s birthday party. The scope you order from the bakery around the corner is a strawberry cake with lemon icing on top and your daughter's name written all over the top with white chocolate. The deadline is two days from today and you agree to pay $35 for the service. Sometimes in advance, too. This is what a fixed price model is in a nutshell and it works pretty well for non-complex errands. As long as you receive exactly what you ordered and that's not always the case, sadly.
| Pros | Cons |
| - Known price means no surprises - Known timeline and set deadlines - Little to no involvement in the development process from the client's side | - Long process of planning and documenting each stage - Focus on delivering agreed scope of work, not on a better product - High risk of having product that doesn’t fit the market - Very hard to make changes during and after the project once it starts - It is difficult to change the product quickly in case of market or legal requests |
So far the fixed price contract sounds great, doesn't it? At least on paper. You know well what you will get, when and for how much. No surprises. Unless, that is, it turns out the product isn't what the market or its customers wanted.
So what could possibly go wrong?
Software development in the waterfall methodology means that an application must be designed, detailed and described along with all its features and components before it can go into production. Every little element is going to be priced and documented separately. This means three things:
On top of that, once software developers start working on coding wireframes, few things might happen:
The worst thing, however, is that the fixed price model forces developers to deliver the final product based on the detailed scope of work as accurately as possible, rather than delivering the best possible product. Due to the fixed price model's limitations developers are rarely involved in the project before the development stage so their concerns and ideas are not taken under consideration. And when they are finally given a stage to perform, it's usually too late for any changes.
Those are the reasons why most of the software development is being done using agile methodology.
Time and Materials is an approach in which clients are billed for the time dedicated experts spend on developing the product based on hourly rate that has been agreed on in the contract.
| Pros | Cons |
| - Flexibility of agile development - Better Product-Market fit - Work on the product itself starts earlier - Lower risks of potential failure | - Timeline is difficult to predict - Costs are difficult to predict - Higher involvement from the client side in the development process |
Time & Materials model allows one to work in sprints, where it's often the client who decides on the next feature that will be designed or developed from iteration to iteration. Each sprint is followed by a demo of what has been built and allows validating both UX/UI and performance.
Each successive sprint is planned based on a greater understanding of the problem, which results in a product better adapted to the market realities and user expectations.
In this regard, though, T&M can require higher involvement in product development from a client. It may seem like additional workload, but it isn't from an outcome perspective. If one calculates the amount of time and energy that might be needed to fix a product that doesn’t meet market needs, that initial involvement really pays off.
Unpredictable costs are another worry with T&M. Customers fear that one day they will be surprised by an exceptionally high invoice they weren't ready for. Or, similarly, that it will be difficult to predict the ongoing monthly costs, keeping in mind that the project can change its course and its timeline a few times as it goes. If this happens, it gets harder to allocate and plan the project's budget and the costs can grow exponentially.
Before moving on to the FTE Engagement pricing model, lets go back to the question, whether it makes sense to combine fixed price model with the agile approach.
The scope of work often changes in the agile methodology. We add features, modify them, change the order of features developed as we go and see best for the product and its final outcome. Now imagine that every time we make even the smallest change we would need to price it and produce a detailed documentation before moving to the development stage. It would be the opposite of agile and efficiency which makes agile and fixed price an unlikely duo.
Most of intent's past projects had been carried out on the basis of the Time And Materials (T&M) billing model. At some point, however, we decided this does not fully reflect the transparent nature of how we approach co-operation with our partners and clients. Therefore, we have created a new model to meet our own, high standards: full time equivalent engagement (FTE Engagement).
In short, FTE Engagement means hiring specialists exclusively and paying for the full Man Days that these specialists have dedicated to your project and its end-result. We call such specialised teams pods. Their strength lies in the fact they can be deployed quite fast and with industry-specific expertise depending on the project, adding tons of value to every project (be it extensive customer knowledge, tech consulting, Go-to-Market and Product-Market fit experience of the pod).
Let me elaborate.
| Pros | Cons |
| - Predictable monthly costs - Dedicated and exclusive team of specialists - Higher efficiency due to the lack of task and project switching - Far greater and industry specific know-how of the team | - Requires a higher dose of trust in a partner - Deadline may be harder to predict |
FTE Engagement is our proprietary concept that gives one the most significant advantages of employing someone full-time without the burdensome disadvantages of having someone on his/hers payroll (sick leave, social security, medical insurance, holidays and restrictive labour laws to name just a few).
In reality, this means that our developers only work on one project at a time. They devote their full attention for 8 hours a day and 20 days a month to one client, which is rarely the case in a T&M model. They do not lose efficiency or focus, time and attention switching between projects doesn’t occur and, thus, they can go really deep into understanding key elements of a client's project and that project only.
What is equally important is that our partners most often need from a few to a dozen developers for their complex and long-term projects. Due to the fact that developers usually work on one project, we establish teams of specialists that have already worked together and are industry experts, which makes the whole development process way more efficient and smooth. One can consider those teams as his/hers dedicated and exclusive product delivery team, just not in-house. They do, however, feel responsible for the product's success, as all owners should.
FTE Engagement has one more advantage over T&M. It makes each month's deliverables and costs predetermined and they can't be exceeded. Simply because each specialist will dedicate no more than 8h per day, which gives 160 hours per month. It makes it easier to estimate the value of the project over time and there are no surprises, which is what clients sometimes fear when working in the T&M model.
However, this billing method requires a lot of trust between a client and a tech partner. At the end of each sprint you will not get a detailed report on how many hours of work each feature took. We rather encourage our partners to take part in demos that show the progress of work on an ongoing basis and allow them to test the product on the go.
One should never think about pricing models in a total isolation from project management methodologies and should always consider pros and cons of each combination.
Fixed price contracts might be good for some very simple, predictable projects with limited features. In all other cases, it is better to opt for an agile approach that leaves you with either T&M or FTE Engagement.
Time and Materials is a very convenient pricing model, but in our opinion FTE Engagement has significant advantages:
If you would like to discuss details of your project and how we can go about it, let us know through the contact form.
Human-computer interaction, human-centered design, user experience (UX), user interface (UI) design and, among them, product design are more than simply buzzwords. The mouthful of the industry’s terminology, however, can be overwhelming. We are constantly being flooded with a multitude of definitions, names of professions, processes and terms that don’t tell us much. Even the oldest design lions often have problems with an unambiguous definition of what they are doing on a daily basis. This article will clarify what product design is and how we use it at intent.
Just a few decades ago “to design a product" meant simply that: creating a blueprint of a commodity such as a chair, knife or a teapot. With the appearance of computers and the development of information technology, the term “product” went beyond the well-known material world. The emergence of new technology helped setting a course for something that is intangible but still invaluable to users and businesses alike: a digital product.
The first (or at least the most popular) reflections on creating digital products and their importance in the human-computer interaction were those shared by Donald Norman. His book “The design of everyday things” resounded throughout the designers’ world, highlighting the importance of the experience that accompanies users while they interact with computers. This phenomenon wasn’t to be ignored, according to Norman. Giving more attention not only to systems’ functions, interface appearance and information architecture but also to users’ feelings, impressions, touchpoints and behavior, effectively contributed to the coinage of terms such as user experience and user experience architect. The latter is how Don Norman called himself and the folks from his design team at Apple back in the 90s.
Soon after, user experience started to be considered an essential element of creating websites, systems and applications. And rightfully so. It helps to design those products in a way that is not only meeting business goals but is also a response to the needs of real users. And as a truism goes: a happy customer is a loyal customer and those, supposedly, generate the most income.
People who are in charge of designing the best possible solutions at the intersection of businesses and users’ well-being alike started to be called User Experience (UX) designers. Often mistaken for graphic designers or User Interface (UI) designers, UX designers are those who aim at being users’ advocates but also at the same time at bringing value to business that stands behind every product. Even though the work of UX designers is not as obvious and tangible at first sight as UI designers’ work that creates the visual layer of a product or service, they both have significant impact on the success or failure of anything we want to build. UX designer’s role is especially crucial when it comes down to whether or not a product will generate return on investment as well as how functional and usable it will be. As more and more companies notice the important role of UX and its value for the business, they distinguish two types of product designers:
UI and UX designers, through close collaboration, are trying to execute all above with the support of workshops, user testing, research and iterations. Of course, designers’ competences sometimes overlap and there is no strict line between one another. A UI designer can have a great sense of UX and a stellar skill set in prototyping. A UX designer, on the other hand, can have a crush on graphic design or be keen on user testing and meticulous research.
Every professional has their specific preferences and skills that define their role in a given project - and it is always unique. The trick is to adjust the resources and design strategy to the product we want to build, its goals, budget - and time restrictions. To make things even more complicated, we have been recently observing a rising popularity of a new job title, namely Product Designer, that extends the scope of UX designer’s responsibilities as it aims to cover all aspects of one’s experience with the product, including monitoring the product’s life-long position and sentiment on the market. However, as it often happens with theories and definitions, it may be a bit controversial. As you can see, however, a proper design of digital products is an outcome of a team's massive effort, with different but equally important skills, rather than individual performance.
Throughout the years, the UX design community started to notice that while taking care of users’ experience, we should really be thinking about the whole process of research, designing and launching a product which consists of not just the “design” work, but much more: defining and redefining business goals, market research, user testing, and even communication (copywriting, tone-of-voice) or marketing (branding).
The aforementioned sir Don Norman highlights that the term “user experience” is much broader than we used to think. According to him UX starts with one’s first interaction with a product, its purchase along with the accompanying journey and, finally, the usage and product related impressions. This is why we should see the product design as the result of various disciplines that influence each other.
As pointed out earlier, designers are not the only ones that shall be attributed to the creation of new products. So, what exactly is product design then?
The definition on Wikipedia tells us that there is no one consensually accepted definition of product design that sufficiently reflects the topic’s breadth. Therefore, we need to consider two separate, but still interdependent, meanings of the term. One defines product design as an artifact and the other refers to product design as a process related to this artifact.
Even though the adjective “tangible” is not quite what responds to our digital world, we can agree that it covers the idea of creating a product. While going deeper to find a bit more exact definition, we can find out the following:
Or, quoting Interaction Design Foundation:
Although product design is considered a superior term to digital product design, it’s nowadays used as a synonym in the creative industry. It describes a process of designing and creating fully digital products such as apps and websites or products that have both digital and physical components, like electronic devices with complementary applications (IoT or Internet of Things).
One of the most popular design process models is, so called, Double Diamond. It consists of the following stages:
As hopefully proven above, designing in itself is crucial, but would lose most of its impact without all the other elements. The presented model is an idealistic and theoretical example of the design process, which can evolve depending on the situation. However, if you want to know our approach to the product design process, contact us - we will be happy to talk to you!
During the product design process, designers have to consider not only steps before and after the development stage where they give a product its form and function, but they also have to take into account other important factors:
At intent, we believe that product design is a process in which the essential ingredients are the holistic approach and close collaboration of all teams engaged in the project. Starting with a great plan and setting business goals fueled by in-depth research to prove our clients’ assumptions then followed by meticulous design with continuous testing and finishing with a reliable, state-of-the-art implementation. Last but not least, the most essential part of product design: creating effective and handcrafted solutions for real problems of the target audience.
At the same time, we don’t want to be pleased with the status quo and pick just one correct definition of the products we make. Although in love with digital, we aim to break the limit between material and digital and find new turning points and ideas at that very intersection.
Have we caught your interest? Check out how we cooperated on the design sprint with Goodify!
We can’t create a building only with the floor plans, can we? The same is true for the product design. It is a process that includes hard work of designers and experts in other disciplines as well.
The digital design industry is constantly evolving. Thus, new technological solutions and roles are appearing every day, which means no ultimate definition is given once and for all. As the ancient philosopher once said: panta rhei, everything flows. We’re sure this suits product design and designer definitions as well, but at least one thing should be stable in all of this: the holistic approach while creating a successful product that respects the end-user and brings value for the business.
Want to know more about UX? Check out our latest article about the advantages of UX research and in fact, when you should do it.
Let’s imagine you’ve had this fantastic idea for a product or service. You managed to bring this idea to life, you put a lot of effort into creating this concept, refining the visual layer and coming up with a marketing strategy.
Perhaps you were inspired by some already existing products, used best practices that you know of, maybe even mirrored the business model of some popular product that you like and admire. Seemingly, you must think, everything should go flawless. But for some reason, it turns out that despite the investments made, the product is not appreciated by the market and the business plummets.
What could be the reason for this? Well, there is a high probability that your assumptions about other people's needs and preferences do not correspond with the reality. That is why it is essential to precede product development activities with a UX research phase which focuses precisely on verifying assumptions, trying to understand users, identifying possible problems and then, based on that, formulating the solution that will be verified by the market’s end-users - your customers.
UX Research done well is a crucial part of the success of the product. Only by having a good understanding of the market and users‘ needs, we are able to deliver an adoptable product-market fit and also — what’s incredibly valuable today– product’s or service’s resistance to changes constantly happening on the market. Using a wide range of methods, we are able to properly select research techniques required to achieve desired goals, depending on our product’s maturity, or specific questions we want to get answers to.
Keep on reading to find out the advantages of UX research, selected examples of methods commonly used as well as the answers on how to use those methods in the product development process.
After that, I recommend you check my previous blog post about best practices for product design workshops with remote teams!
UX research is a specific product design & development phase focused on gathering functional requirements, researching target users along with their needs as well as constantly testing solutions on the target audience. The aim of such activities is to confront the concept and design work with the reality to verify whether the solution has a feasible chance of working in the real world scenario and for real users. In short, what we do in the course of research is defining what we create, for whom, in response to what problems and obstacles, why we do this particular solution and how - well before we spend significant sums of money developing something not yet validated, saving ourselves a lot of money and even more headaches in the process.
The importance of UX research is best put in bullet-points. Every product or service should consider it for the following reasons:
There are plenty of methods that we can use, depending on our needs, type of product or service and the stage it is at.
There are two types of methods depending on what kind of data we want to collect: qualitative and quantitative.
Quantitative — giving answers to “what” and “how many” questions
Methods:
Qualitative — providing answers to “why” and “how” questions
Methods:
You can distinguish many different models when it comes to the stages of product development. One of them, described by the Nielsen Norman Group, is the division of product related work into 4 stages:
Stages of UX Research
Source: Nielsen Norman Group
This stage consists of collecting information and deepening knowledge about users in order to better understand what their needs are. It is especially important when creating a new product to verify whether our idea has a chance of success, but also when developing new features or services.
Methods:
Once we have successfully examined end-users' needs, the next step is to define the problem we aim at solving and correlate those needs with the required design work.
Methods:
The testing phase takes place when we already have a prototype of the product as well as during development. Using appropriate methods, we make sure that the product fulfills its role and works as expected. At this stage we must make sure the designed solution is intuitive and understandable for users.
Methods:
During the entire product development phase, we collect information about users, their needs, changes in their behavior and emerging problems. This stage is an ongoing process and should never stop for the product or service to remain relevant. The methods that we can use include:
In short — investment in research always pays off and basically, regardless of the product and the industry, it is always worth doing. But let’s take a look at specific use-cases:
When creating a new product, it is crucial to precede it with as deep research as possible to identify the needs of the target users and make sure that the product we want to create will meet them. It is equally important to check the competition — what products are already on the market, what are their strengths and weaknesses, where we see the value that our product can provide and be better at than the products of others. In other words: what is its advantage over the competition.
For a product development team, working together with startups and companies on their product ideas, it is essential to understand both the client and end users at an early stage and — using UX research methods – make the whole team aligned on business goals and assumptions of the project.
The methods used to create a new product are the methods listed in Discover and Explore stages, including:
2. Adding new features
When working on a new functionality for an already working product, we can confidently use the same approach as when we use creating a new product . It is then equally important to research the market, understand users and define the problem we want to solve. However, at this stage, we can also use the knowledge provided to us by the existing product and feedback from its users, using methods such as data analysis (e.g. Google Analytics), surveys or interviews.
3. Redesign
When redesigning a product, we can learn from our current user base and their behavior for design decisions to be driven by data. This, however, doesn’t mean we shouldn’t use A/B tests or usability tests along the way, too.
4. Attracting new audiences
If we want to expand our product to a new group of users, we naturally need to get to know this group well and understand what their needs, problems, and habits are. Thanks to techniques like interviews, surveys, usability tests or creating user personas, we can make the research much more accurate.
5. Product’s end-to-end lifecycle
Research should be a permanent element of the work on a product during its whole lifecycle. Thanks to this mindset we will be able to constantly improve the product, react to new problems, and changes on the market. Having the right amount of data on our users, competition and the industry in which we operate, we will be able to react faster to such changes and improve the product accordingly or, if necessary, even pivot our whole business model.
A product created and developed based on UX research methods is able to achieve a product-market fit, which determines the degree of product adaptation to the market needs. Founders often tend to focus on the solution rather than the problem itself while creating new products. According to Michael Seibel from a renowned startup accelerator Y Combinator “only through launching, talking to customers, and iterating will you actually find a product that reaches product-market fit”.
Knowing the market and our users, we can make informed decisions both when creating and developing a product as well as when a change on the market forces us to pivot or change.
Usability has a direct impact on user engagement and conversions. What is more, making sure the product is usable for people with various types of limitations or disabilities, increases the overall user experience (it also benefits users with temporary restrictions, i.e. due to intense sunlight, using an app or a website in a hurry, in a noisy place, and so on).
Thanks to UX research methods such as user story mapping and prioritizing, we can agree in advance which functionalities are key and plan for further stages of product development accordingly, which translates into risk and cost reduction (mind you derisking is a recurring theme of UX research).
As mentioned above, knowing your customers and monitoring their behavior as well as the ever-changing market on an ongoing basis, we are able to respond to sudden changes (like the one we all have been experiencing in the recent months) much faster and make more informed decisions.
The UX research phase is often perceived as an additional cost and more time spent working on the product. Paradoxically, investing time and resources in UX research directly translates to big savings in the future, because it protects us from corrections and changes at further stages of the product development that are costly.
Without good research, it may turn out that after the development phase our product does not fulfill its purpose, does not deliver value or is unusable for the desired audience. And so, the hours saved on UX research can render into many days or weeks or even months of extra work on improvements and changes later on in the process with some of the previous work being thrown away. Not to mention how cost inefficient that mistake may be. Thankfully, potential spillage is totally avoidable by implementing UX research to one’s early-stage action plans and budgets.
It’s always important to do UX research and despite it being an additional work it always pays off. There’s plenty of methods you can use at different stages of your product lifecycle. Still, by using only a few, well-known and well-conducted methods, you will be able to collect precious data that will support your design decisions and translate it into a better end product that users should appreciate.
If you’re still unsure whether you should consider investing in UX before jumping straight to software development or if this investment noticeably pays off in the future - check out our Simple Guide to the ROI of UX.
If you do, however, understand the importance of UX across all product’s lifecycle stages, contact us for your project estimation.
As a developer, you may face the need to introduce a payment method in the application logic at some point. Business is business, after all, and even a few cents at the end make a difference, regardless of you being a startup, scaleup or a corporation.
When you work with a backend infrastructure there are plenty of different players in the payment and credit card processing as a service to work with, and today we will focus on one of the most interesting and flexible solutions we have had to deal with recently.
Sorry, we’ve already spoiled it in the title, but it’s obviously Stripe we’ll be tackling here.
One of the first checks that I like to do on an as-a-service solution is to figure out what is the language supported natively (and also if any third-party developer might have enhanced any of those already).
Support for Stripe is pretty wide. In the case I am going through in this article, I focused on Node.js to dig down a bit more and noticed that apart from the original library done by the original team, we have more than 640 other packages on NPM.
For sure it is something to think about, but mostly I see integration with the third-party framework, so nothing that makes me scared like “Oh, it’s so over-engineered that someone had to create a wrapper to make it more humane”.
Also, as you can see below, the library is being kept up to date. Since Stripe makes releases very often and timely, we can say that their average sprint time is around 1 week. Conclusively, the frequency of Stripe’s bug updates and fixes can be associated with the security of their library.
Having this in mind, all I need to do is to keep my package.json a bit more updated than usual, but I’d rather bother myself with periodic updates than regret and waste time for avoidable issues.
Last, but not least, even the attention with which Stripe treats PR seems quite tailor-made:
On top of that, Stripe’s willingness to accept PR and fixes even from externals is also worthwhile :+1:.
By the way, Stripe’s library supports typescript bindings too, so if you love force types - it’s a good one!
As an old school developer I love to have clear documentation. I’m from the pre-internet era when books were the source of truth and you had to rely on them and trust them in order to accomplish anything. In this respect, I pay a lot of attention to having a well-documented API.
And this is where I think Stripe is able to provide a very detailed API reference to dig and play with before any implementation, which is very helpful.
Digging around is quite easy to get familiar with their unique naming conventions and to prepare a high-level flow of the steps we will need to achieve our project’s business goals.
A dedicated section is linked to errors, usually pretty verbose and detailed.
Worth mentioning, the package for Node.js supports automatic pagination, so again something less to be worried about.
TLDR; if you, unlike me, hate documentation and want to jump into the center of it as fast as possible, there’s a very detailed quick start documentation too with some examples of basic payment flows. Worth taking a look into it!
As mentioned before, Stripe's huge advantage is a micro-feature API structure that allows you to manipulate flows in the most profitable way for your company.
Keep in mind the first rule of business that rightfully claims not all the businesses work in the same way, hence both customization and flexibility Stripe provides are the two most essential features.
I know that first hand. Recently I had to take care of implementing Stripe’s API in two different projects. One of them was more of a common eCommerce approach with payment as the last step of the user flow to finalize the whole order. Pretty standard, no?
The second one involved more custom approach with steps that included credit card verification or payment holding during the pre-transaction and background check.
To be honest, I was very worried about the second one at first. According to my previous experience with other suppliers, namely the nightmare of having to debug the outdated documentation and figuring out how to deal with the related bugs.
In comparison Stripe seemed like a salvation right off the bat! I managed to achieve the goal quite fast and the documentation was well-prepared. and supportive, using the verbose response and snippet examples for your language. Time saver!
As a developer myself, I suggest having at least a bit of development training first (this is not entirely a no-code solution after all). Apple did it very well with Playground tool which is a powerful instrument as a sandbox for Swift code, where you can experiment quickly and easily without having to create the whole project. It is a way to test some algorithms or functions in a lean and fast way without wasting time on creating the whole project. For Node.js you can still find similar options like JSFiddle. Make sure you use them before taking your VSCode and creating a dummy project to save yourself some time.
Don’t forget to register to Stripe website before you dive deeper into integrating its API with your website or app.
One thing I’m pretty sure of is two keys that will become your best friends at the beginning of your journey through the Stripe’s sandbox:
They can be found in Stripe Dashboard under the API keys section. Below you can see how they should look like.
Before you start any action, remember to switch to “Viewing test data”.
The orange colour of UI will confirm that you are sandboxed. By using this feature you will avoid a real financial transactions using any dummy card.
Okay, so we'll start our simulation with the most common flow for the eCommerce market, where we'll keep the user's payment details for future transactions. By the way, if you are interested in the eCommerce market, we recommend you to check out our article regarding the worst aspects of online shopping.
One additional aspect, assume we do not use any official or external credit card helper to collect the data. We will simulate that the data comes from a custom field.
But before you start writing your first line of code remember to check the logic of the whole process - always.
Once you have familiarized yourself with the above flow, you can go to the appropriate reference in the Stripe documentation. Now let’s get down to business.
We have already gone through Libraries and Documentation - it's time to create a project:
Once we do this we should run our favorite editor and take a deep dive into the project.
Create a file called index.js and integrate Stripe API. In order to do this you just have to run following the command in the directory of our project:
Let's create a boilerplate in the index.js to be able to use async/await approach:
const stripe = require('stripe')('REPLACE_WITH_YOUR_SECRET_KEY');
// helpers
const createUser = async () => {};
const addCreditCard = async (user, card) => {};
const processPayment = async (user, card) => {};
(async () => {
try {
console.log('Stripe demo');
// TODO: create user
const user = await createUser();
// TODO: add credit card to user
const creditCard = await addCreditCard(user, {
number: '4242424242424242',
exp_month: 9,
exp_year: 2021,
cvc: '314',
});
// TODO: create payment intent for user
await processPayment(user, creditCard);
} catch (e) {
console.error(e);
}
})();
I added a few comments in the code and intentionally left some console.logs to speed up the debugging, but the point is to mimic the flow that we defined above: create a user, add a credit card and finally process the payment.
In case you wonder: 4242 4242 4242 4242 is a dummy credit card that is supported by Stripe.
Remember to replace the secret code with one of your accounts. Otherwise, it will not work and you may be disappointed.
Ok, at this point we should focus on creating a client by adapting the code like this one below.
const createUser = async () => {
try {
const customer = await stripe.customers.create({
email: 'jdoe@example.com',
});
console.log(customer);
return customer;
} catch (error) {
console.error(error);
}
};
As you can see, we are using the customers.create API, in particular, we are going very lean in this case using just the email, but we can provide additional data for the user, if needed.
Next step is to add the credit card. Below you can find how the snippet will look like.
const addCreditCard = async (user, card) => {
try {
const paymentMethod = await stripe.paymentMethods.create({
type: 'card',
card,
});
console.log(paymentMethod);
const attached = await stripe.paymentMethods.attach(paymentMethod.id, {
customer: user.id,
});
console.log(attached);
return paymentMethod;
} catch (error) {
console.error(error);
}
};
Now, here we have to combine two APIs under the same roof: paymentMethods.create and paymentMethods.attach.
We need to create a payment method with our credit card data (code, expiry, CVV, etc.) and associate it with the user we have created a moment ago.
Our last step is to put everything we’ve done so far together and process the payment:
const processPayment = async (user, card) => {
try {
const paymentIntent = await stripe.paymentIntents.create({
amount: 1250,
customer: user.id,
currency: 'usd',
payment_method: card.id,
});
console.log(paymentIntent);
} catch (error) {
console.error(error);
}
};
Our wingman here is the paymentIntents.create function, it requires just a few parameters passed as an object:
It shall be pretty straightforward from now on. You might, however, be wary of just one potentially tricky element…the amount.
Remember that Stripe API is expecting the amount as an integer number, so you will need to add a little helper to convert it, according to this logic:
$10,00 → 1000
$10,50 → 1050
$0,50 → 50
OK. so now it’s turn to run the code.
Let’s use:
And a little of JSON will start kicking in into our terminal.
You can also open Stripe Dashboard (remember to set the test mode!) and double check the payment and the user just created.
And we're done. It's time for you to start counting the incoming influx of cash from your eCommerce. Happy hunting!
If you want to see the whole code and play a bit with it - feel free! You can find it here.
P.S. Once you’re a millionaire, thanks to this, don’t forget to say thanks by letting us do some development work for you, will you?
In the times of high demand for developers in start-up and enterprise industries, coding skill is worth its weight in gold. The lack of access to this core competence becomes an obstacle for some companies, especially in the reality of the post-COVID-19 new norm that forces businesses both online and offline to reinvent themselves or at least pivot. At the same time, the inability to code turns out to be a business opportunity for others. It’s not a surprise to see a rising number of no-code applications that aim at supporting developers or even replace them. But why use this solution only to create an end-to-end product and not get the prototyping phase to a higher level? In this article, we will answer the question if and how a designer can make the use of no-code applications in the design process.
Low-code and no-code platforms appeared as a response to a lack of skilled developers on the market and an increasing need to solve problems quickly during the development process.
They are derived from Rapid Application Development (RAD) tools such as well-known Excel, Microsoft Visual Studio, or Microsoft Access, which give a non-IT-professional user a range of features that touch on coding.
While the mentioned examples required at least some technical knowledge, low/no-code platforms go a step further. Although the line between low- and no-code is still vague and in low-code platforms, a user needs to understand some level of coding, the main goal of this solution is clear: limit the development activity (or developers’ involvement) and speed up the process by using the graphical user interface (GUI).
Potential users of such platforms, like developers, UX/UI designers, or graphic designers, can skip writing lines of code and use visual tools in the form of drag-and-drop components to quickly build a website or application. As a result, to create a real digital product, one doesn’t even need to know how to code (hence the no-code term). However, no-code has its obvious limitations that raise questions about how effective these kinds of tools are, what their limitations are, and - finally - what are the instances when one simply can’t go about designing without the help of an experienced developer.
There are currently a bunch of no-code tools at designers’ disposal that enable them to painlessly build digital products that are not just prototypes but have actual code so that they can be immediately implemented. One can find an enormous list of platforms that compete with one another in offering more and more advanced solutions, from creating a newsletter (Mailchimp), a website (Webflow, Wix) to building an online shop (Shopify) or even complex web apps (Bubble).
The ease of accessing these platforms can vary. Some of them require additional applications and/or direct contact with the company about a potential collaboration. Nevertheless, many of them don’t require a start-up budget or big investment and can be used for free by a freelancer or a small business.
So, why would a designer want to use no-code platforms? There are a few things that pose a challenge during the design process and user testing stage.
No-code platforms, as has been hopefully proven above, could easily solve big challenges of the product design process. But one shouldn’t get too much hope. These tools are still in their infancy and it will take much more time to even discuss replacing developers if that’s ever going to be possible in the first place. But it doesn’t mean that these tools cannot be useful for the designers right now, to make the process more efficient and faster or to bring new prototyping possibilities to reality in an organization.
To analyze the usefulness of no-code platforms from a designer’s point of view, we gave a closer look at the following tools:
Bubble positions itself as a place where one can prototype, launch, iterate, and scale their web application. As a designer, I was interested in the “prototype” option, which they describe as “Demonstrate your idea before making an investment in technical resources”.
After a quick sign up the user is taken to onboarding, which explains the app building process step by step. This is indeed very helpful, as the interface is complex and doesn’t seem intuitive at first. The onboarding on the other hand is simple and even though it’s a bit long, it’s well justified, as it helps to really understand what is going on (and why). The whole onboarding consists of 12 lessons that are skippable. Some of them also include a “hard mode” at the completion of a given lesson. With each lesson, the user is taken deeper and deeper into the complexity and possibilities of the product.
When users decide they are ready to build their own web app, they can choose from many types of digital products, such as marketplace, online store, CRM, and many more. This acts as a template for the design of the app in Bubble and is helpful if one doesn’t want to start from scratch.
When building an app, the user is also guided through the interface and all the possible actions.
There’s a ton of elements to choose from, such as text, buttons, video, map, form fields (e.g. file upload, sliders). Users can style every element separately or apply a predefined theme, which immediately makes the app look much better. They can also add simple or more complex interactions - for example when a user searches for an address, it’s displayed on the map and saved in the database.
After testing the app for a while I can confidently say that it can act as a great and efficient prototyping tool. As one can choose from many interface elements and apply interactions almost automatically, it can greatly improve the prototyping process. I wouldn’t recommend creating a UI Design in Bubble, though, as the styling options are a bit limited. The process is also different from how most UI designers work, where they build their own design system, style single elements, and group them into bigger components.
To summarize: as long as one is not using a predefined design system and wants to quickly prototype an app with complex interactions - they can definitely use this tool. The problem arises when one needs to then translate the prototype into visual design, which means the necessity to start off in the design tool from scratch, as every element is in Bubble instead of e.g. Figma or Sketch. This, however, does not resolve our challenge about the inefficiency of the process but does resolve the challenge of limited interactions. It’s also faster to create a prototype from provided elements, and not having to draw them yourself.
I’ve also tested a few other apps to compare the experience. I tried Honeycode from Amazon, but the app has limited options and it’s unintuitive, which makes it hard to use by someone without technical knowledge about the AWS platform. I would even go as far as to claim that for designers it’s rather useless.
Webflow, on the other hand, had great user experience, with simple and helpful onboarding. It definitely makes building websites much faster and fun, and I dare to say that one can ditch visual designer altogether if the desired website is simple and doesn’t have to look very polished. I would definitely use it to do some quick usability testing of the website, and the work would be much faster than building components from scratch in Figma.
I also tested Appian, but I got discouraged by the platform’s unclear logic and complex interface, which makes it difficult to understand the tool and use it effectively and AppGyver seems to have some potential in the future but is more of a work in progress at this point.
Even though all platforms that I’ve tried are so-called no- or low-code tools, some of them require zero technical knowledge, and some of them require some or more. Even if the app seems easy to use, the onboarding really helps to understand all possibilities of the tool which might be missed during free exploration. What’s significant from the designer’s perspective is that these platforms are never a tool in which you can build everything in - from mobile and web apps to websites. But if one wants to quickly prototype and validate his/her ideas, I’d say that those tools are definitely worth trying. It will be much faster and easier to use no-code platforms than to build everything from scratch in a prototyping tool since on those platforms one can use predefined and working elements (e.g. sliders, file uploaders, maps) that otherwise take time to draw and to connect interactions with one another.
Pros:
Cons:
So, will I use it in the future? Maybe. If so, I will definitely stick to Bubble and Webflow, as they were the most intuitive and helpful in the design and testing process.
HQ Trivia needs no introduction. It has had its ups and downs but one cannot deny the fact that when released, it was a completely new type of experience on our mobile devices and it took the market by storm notching 10 million downloads on Android and iOS devices.
HQ Trivia has been all about questions and answers. And the question you may be asking yourself right now is how it all looks like under the hood?
There are a lot of moving parts inside the app’s engine, but one that plays the most crucial role is the producer panel that controls all sorts of stuff happening during the game.
It all starts with the creation of the new game, selecting what type of game it should be, and scheduling when should it happen.
The next step is, of course, adding a set of questions for which you can select a category, add possible answers, and then select which one of them is the correct answer. But that’s just the beginning.
Some questions, as you may know, have videos, photos, or audio files attached to them, and this is the place where the producer can add all of those things to the questions.
Then there is also a matter of not all questions being created equal from a reward standpoint.
After some questions, there are checkpoints that allow players to finish the game and get some bonuses or continue if they’re feeling lucky. This is also something that will be set during the process of creating questions.
The producer can also specify how many coins a specific checkpoint offers to the players. He basically designs the whole in-game reward/gamification system as he plunges in more questions for the day ahead.
Another feature that is a part of the process of game creation is adding gift drops. They won’t be appearing in every game, but have to be prepared and attached to specific questions in advance.
As you can see there is a lot happening before the game even begins, but what happens when questions start to pop up on your screen. How do they even get there? Are they being sent to devices in advance? Or maybe there’s a way to take a look at them before they are asked?
It’s not that simple. It turns out the only safe haven for trivia questions to queue before they appear on players’ screens is the backend.
HQ knows this very well and that’s why they send each question only when the time is right, which is when the question is being asked. The way it’s being done is through socket connections which keep each player connected to the server for the entire duration of the game.
Let’s have a quick look at what sockets are and how they differ from REST APIs, which are used by most apps on our phones.
REST APIs are interfaces that allow us to get specific data from the server. It may be weather, recipes, or photos on Instagram, but the way the communication between devices works is the same: the app asks the server for some data, the server then answers by sending the requested data and the connection is closed.
You can read more about REST API in our article on integrating Google Fit with an Android app.
Sockets on the other hand keep the connection between the app and the server alive for as long as it’s needed, and this allows messages to go back and forth with no need to re-establish the connection.
Those messages, like in HQ Trivia’s example, may contain different kinds of data. For instance, when the presenter is ready to ask the new question, the producer simply clicks the “Start question” button which causes the server to send a message containing said question to all of the players, who then see the question appearing on their screens. Such a message doesn't contain the answer to the question, in case you were wondering, which makes this type of connection the safest for HQ Trivia's purpose.
This is how it works in practice:
1. 10 seconds after a question pops up on the screen, all the players are given the answer.
2. The results are being sent in the exact same way as questions, using a socket connection.
3. The producer selects the option to send the question summary which triggers the server to send each participating player a message with data such as:
4. In the event of a player being wrong, the message will also contain the info whether the player should be saved by an extra life or a free pass or if he or she was eliminated.
I hope you enjoyed this behind the scenes of how HQ Trivia creates its quizzes. And hopefully, learning about it will help you come up with your idea for the next big thing.
If that’s the case, then we - at intent - will be happy to help you bring the product to life, using our extensive knowledge and experience. Don’t hesitate to contact us.
Data is king and possessing it gives you power. But there’s no way that you can use it to rule your industry if you don’t turn this data into actionable insights. In order to make sense of the immense amount of digital information that your business generates these days, you need powerful business intelligence software. And one of the best options available, no matter what kind of data you’re dealing with, is Power BI. So let’s take a closer look at what this option has in store for you.
Power BI is a Microsoft flagship business intelligence product – it is a versatile platform with a number of tools for processing massive amounts of data, so you’re not only able to collect and aggregate all of your data, but you can also visualize it graphically, analyze the outcomes and share your insights with others. The platform consists of both local and cloud-based apps and services, and connects to a wide variety of Microsoft and non-Microsoft based data sources and business tools.
And because Power BI has such an intuitive interface and easy-to-use features that ensure a pretty low barrier to entry, even non-technical business users can use it. Now, let’s keep going and see how you can benefit from this solution.
Plus, Power BI is pretty cost-effective, with two different pricing plans to choose from – Pro and Premium. You can even try the first one for free and then upgrade if you feel like you need the more advanced edition.
There are a number of ways that businesses can leverage Power BI, no matter the size of the company. For example, it can be used to:
Of course, since Power BI can be integrated with many different services and apps, and has a great variety of internal features, the sky’s the limit in terms of its applications. And speaking of features… there are at least 10 of them that deserve special attention.
All of these features – and many more options that are available within the platform – help you create useful and actionable visualizations. These dashboards can be used for different purposes while allowing you to maintain full control over your organization, department, or project. The examples listed below speak for themselves.
Power BI is extremely versatile and can be used in a wide variety of situations. And while it can have a steep learning curve (after a pretty easy start) – it also allows you to create reports or dashboards that are elegant, clear, and easy to understand from the perspective of a decision-maker. And this is absolutely priceless since the ability to make adequate and timely decisions based on undeniable facts can quickly turn into real profits for a company and its customers or the society, depending on the kind of data you analyze and for whom.
Cover image by Stephen Dawson
With the influx of health-conscious customers, ensuring that your fitness product delivers a holistic, integrated service is growing ever more important.
Every creator of a health-oriented application is practically obliged to connect it to a fitness service to facilitate the seamless transfer of data between various (often competing) applications. In the Android world, that solution is the Google Fit API.
As is standard for Google’s server APIs, there are two ways to communicate with the server:
These solutions do not share a code base, so for example, slightly different fitness activity (as in “rowing” or “kayaking”, not MainActivity) types are available:
Google Fit activity types list
Google APIs for Android documentation list
(Note the lack of “Guided breathing” activity type for SDK.)
The choice between the two mainly depends on the level of technical sophistication of the SDK - if it’s advanced enough, well maintained, and documented, it is almost always more convenient to use than raw REST endpoints.
However, some optimization techniques, especially in using cached data, might mean that the data provided by the SDK is less reliable than acquired directly. At least until recently, this was the case with the Fit APIs (plural), with its Local Storage (described below), so that is something worth testing before deciding on an approach.
In order to improve performance and reduce server load, most API calls do not connect to the Google Fit server, using the local store for a reading and writing data instead. Unless explicitly demanded, data propagation happens only every few hours. This can lead to confusion if, for example, you expect the changed data to be immediately available on another device. On the other hand, this does make the data accessible to any local Fit-integrated applications even without a network.
This is particularly important to keep in mind when testing the application since with data sync not happening immediately, false negatives can be reported.
On the other hand, all local changes will be available immediately, even if the device doesn’t have a network connection at the moment. This is a great solution performance-wise, but quite confusing (and currently under-documented) during testing. With that, of great help will be the Playground:
One feature of Google APIs I personally found particularly useful was the possibility of seamless online testing of its REST APIs. Not just for Fit - the list is astonishingly long and only keeps growing. With real data underneath, the Playground allows for quick verification of the stored data, before writing a single line of code.
As is often the case, an application might need to separate the Fit activities created by it from the remaining activities. There are two approaches to achieve that:
The first one is straightforward - simply call setAppPackageName when creating an activity, and verify that value when checking the downloaded activity’s type. The obvious downside is that this value will be identical for all activities an app creates, so if a more sophisticated separation is required, the package name alone is not enough. That’s when the naming pattern comes in - set the session identifier according to the chosen pattern and then verify, like below:
private fun activityIsCustomActivity(session: Session): Boolean {
return session.activity == FitnessActivities.KITESURFING
&& CUSTOM_SESSION_KEY_REGEX.matches(session.identifier)
}In times when user’s privacy is an ever-growing concern, it is increasingly important to guarantee that an application will know about the user only as much (or as little) as it is required for it to function. It is entirely feasible for a user to wish to allow an app’s access to his basic biological data, but withhold some more sensitive data such as heart rate. In response, Fit allows very detailed compartmentalization of the accessed data.
fun syncOptions(): GoogleSignInOptionsExtension = FitnessOptions.builder()
.addDataType(DataType.TYPE_ACTIVITY_SEGMENT, FitnessOptions.ACCESS_READ)
.addDataType(DataType.TYPE_ACTIVITY_SEGMENT, FitnessOptions.ACCESS_WRITE)
.addDataType(DataType.TYPE_HEART_RATE_BPM, FitnessOptions.ACCESS_READ)
.addDataType(DataType.TYPE_HEART_RATE_BPM, FitnessOptions.ACCESS_WRITE)
.addDataType(DataType.TYPE_HEIGHT, FitnessOptions.ACCESS_READ)
.addDataType(DataType.TYPE_HEIGHT, FitnessOptions.ACCESS_WRITE)
.addDataType(DataType.TYPE_WEIGHT, FitnessOptions.ACCESS_READ)
.addDataType(DataType.TYPE_WEIGHT, FitnessOptions.ACCESS_WRITE)
.build()
For a simple example, let’s read the user’s height data from the server. First, we need a working Google Account object:
val signInAccount = GoogleSignIn.getLastSignedInAccount(context)
If the signInAccount value is not null, the app is authenticated, but not yet authorized. We need to request the permission to read/write data of the required data types.
fun syncOptions(): GoogleSignInOptionsExtension = FitnessOptions.builder()
.addDataType(DataType.TYPE_HEIGHT, FitnessOptions.ACCESS_READ)
.build()
val requestCode = 123
GoogleSignIn.requestPermissions(activity, requestCode, googleSignInAccount, syncOptions())The SDK will display a permissions dialog to the user. The result of the user’s action will be returned in a standard onActivityResult callback. To use the SDK later, we only need to check if the permissions are still granted (as in they have not been revoked)
val hasSyncPermission = GoogleSignIn.hasPermissions(signInAccount, syncOptions())
If permitted, it is finally time to read the data from the server. We only need the latest height data, so the limit will be set to 1. We want to make sure that we get data from the server and not just from the local storage, so we set the “enableServerQueries” flag. And of course with the full-time limit, to get even the oldest data.
fun readPersonalProperty(
signInAccount: GoogleSignInAccount, dataType: DataType): Task<DataReadResponse> =
Fitness.getHistoryClient(context, signInAccount)
.readData(DataReadRequest.Builder()
.read(dataType)
.setTimeRange(1L, Instant.now().epochSecond, TimeUnit.SECONDS)
.setLimit(1)
.enableServerQueries()
.build())
readPersonalProperty(signInAccount, DataType.TYPE_HEIGHT)Of all the APIs that compose the full fitness solution, Sensors Api is of particular importance. For all health applications that do not have a backing hardware device (like a bracelet or ring), the smartphone will be the source of all new data.
In general, sensors on Android devices belong to three categories:
The availability of sensor data depends on the presence of sensors of different types inside the device, hence the need to verify that in your application, before querying for the data. Therefore, a fallback mechanism needs to be implemented to provide a satisfying user experience even if most sensors are absent or malfunctioning.
Most of these sensors can have varying accuracy, of which the application will be notified by the onAccuracyChanged callback - particularly important for uses that require fine-grained data.
Photo by Ketut Subiyanto from Pexels
“All the world's a stage, And all the men and women merely players; They have their exits and their entrances, And one man in his time plays many parts” - William Shakespeare (and Civilization IV)A successful project requires many people, filling different roles. Let’s assume that the design is ready, you know what to do, but you want to do it better. I believe that with the help of role-playing and some creative gamification you and your fellow inmates actually can do a better job. Roles such as:
“Ok, but my kid is just 3 years old! He can’t read or write yet, has an attention span of about 10 seconds on any given task, and prefers to just monkey around. What then?” - you say.Well, funny you should ask since he seems to be the perfect person for the role of:
However, more often than not, it just isn’t that simple and you’ll see why, below.ROI = net profit of investment / cost of investment * 100% (net profit = gain of investment – cost of investment)
Arduino has been around for years, and you've probably heard the term. It is an open-source electronics platform that allows developers to connect hardware with software easily. The popularity of Arduino is vast because it offers a simple and accessible user experience. As an iOS developer, I wanted to play around with this platform, so I've built a toy car that can be controlled with a mobile app. Read this article to find out how I did it.
There are two key components in this project:
You can see the final result in the picture below. On the left side is an iOS application, on the right side, a toy car.
Let’s start with the car controller (iOS application). In this article, I won't go into details about iOS application implementation. I will describe briefly how it works from the user perspective.
The application connects to Arduino using BLE (Bluetooth Low Energy).
After launching it, the device discovery screen is displayed. The application starts searching for Bluetooth devices automatically and displays devices with matching service UUID. User can restart device discovery by pressing the Search button (in case of network errors). The application can automatically connect to the last selected device by checking the Auto-connect checkbox.
The controller screen has four controls:
It shows connection status in the top right corner. By pressing the back button, the application disconnects from the car and navigates back to the device discovery screen.
The toy car was built using mechanical parts from an old toy: chassis with wheels and 2 DC motors (one for driving, the other one for turning).
The custom components are Arduino, DC motor controller, Bluetooth, LEDs.
1. Arduino Due
Arduino is an open-source electronics platform based on easy-to-use hardware and software. It can be used for prototyping hardware devices. Implementation is very fast and in a few days, we can have a working device for real-world testing.
It is responsible for controlling hardware components (motors, sensors, LEDs), Bluetooth communication, and handling iOS application commands.
Arduino Due main characteristics:
2. Waveshare Motor Control Shield L293D
It is capable of driving 4 DC motors or 2 stepper motors at one time.
When using an external power supply of 9V it allows you to adjust the speed and direction of the motors with current consumption up to 600mA (1.2A peak) and a voltage between 1.25V - 6.45V.
Toy car has two DC motors: the first one is used for driving, the second one for turning.
3. Bluetooth module HM-10
HM-10 is a Bluetooth 4.0 module. It works with voltage from 3.3V to 5V, it communicates over a serial UART interface (RX, TX pins). The maximum transmitter power is +6 dBm, the receiver sensitivity is -23 dBm.
4. Two DC motors
DC motor for driving (operation Voltage of 3-6V, free-run current of 200mA).
Mini DC motor for turning (operation Voltage of 3-6V, free-run current of 30mA).
Choose your DC motors depending on the weight of the car.
5. LED lights
4 x red LEDs for turn signals
4 x white LEDs for headlights
6. Other components
The photo below shows how components are connected. It doesn’t look pretty, but I assure you that it works :)
And here is a schematic diagram:
Let’s examine each and every component individually.
One of the biggest advantages of Arduino is that there is a vast set of ready to use components and libraries available. They are very easy to use and don’t require us to write much code. They are named Shields. In this project, I used a Bluetooth Module and a DC Motor Control Shield.
Let’s start with the Bluetooth module first. It communicates with the Arduino board using the Serial port.
Connect Bluetooth module HM-10 pins to Arduino board:
Define a helper macro named HC06 that points to a Serial3. configureBle() method starts Bluetooth connection.
#define HC06 Serial3
void configureBle() {
HC06.setTimeout(100);
HC06.begin(9600);
}Define Bluetooth commands for controlling the toy car. iOS application sends commands to the Arduino. Currently, the application supports the following commands: drive, turn on headlights, change gear, turn.
Command length is 3 bytes.
First byte is a command code defined as an enum BleApiCommand.
Second byte is an additional parameter, depending on the command code:
Third byte is a command terminator 0x0f.
const int commandTerminator = 0x0f;
const int commandLength = 3;
enum BleApiCommand {
cmdDrive = 0x23,
cmdHeadlights = 0x24,
cmdGear = 0x25,
cmdTurn = 0x40
};
Main application setup method.
void setup() {
configureLightsPins();
configureMotorPins();
configureBle();
}Main application loop responsibilities:
void loop() {
int tickTime = millis();
// Command loop
while(HC06.available()) {
byte buffer[commandLength];
int size = HC06.readBytes(buffer, commandLength);
if (size != commandLength) {
continue;
}
lastCommandTimestamp = tickTime;
handleCommand(buffer);
}
handleTurn();
turnSignalControllerTick(tickTime);
stopIfDisconnected(tickTime);
}
Handling commands
Extract command code and parameter, then handle each command in a separate method.
void handleCommand(byte data[]) {
byte code = data[0];
byte param = data[1];
byte terminator = data[2];
if (terminator != commandTerminator) {
return;
}
switch (code) {
case cmdHeadlights: {
bool on = param == 0x02;
setHeadlights(on);
break;
}
case cmdGear: {
setGear(param);
break;
}
case cmdTurn: {
turnWheels(param);
break;
}
case cmdDrive: {
drive(param);
break;
}
}
}Headlights (white LEDs) can be turned on and off manually by the user using a button in the top-right corner of an iOS application.
Connect each LED to a separate digital PIN through a resistor (220Ω) as shown in the diagram above.
Declare 4 headlights and 4 turn signals pins as constants and set their mode to OUTPUT.
const int pinHeadlightsRight1 = 22; // Remaining headlights pin numbers: 24, 26, 28
const int pinTurnSignalLeftFront = 31; // Remaining turn signals pin numbers: 33, 35, 37
void configureLightsPins() {
pinMode(pinHeadlightsRight1, OUTPUT);
pinMode(pinTurnSignalLeftFront, OUTPUT);
...
}
void setHeadlights(bool on) {
int value = on ? HIGH : LOW;
digitalWrite(pinHeadlightsRight1, value);
digitalWrite(pinHeadlightsRight2, value);
digitalWrite(pinHeadlightsLeft1, value);
digitalWrite(pinHeadlightsLeft2, value);
}Turn signals (red LEDs) work automatically - they blink every 0.5 seconds when the car is turning. They work in four modes: disabled, blink left, blink right, blink both sides.
Define mode as an enum and tick interval as constant.
Use turnSignalControllerSetMode() method to change the blinking mode.
enum Modes {
idle = 0,
blinkLeft = 1,
blinkRight = 2,
blinkBoth = 3
};
const int tickInterval = 500; // milliseconds
int lastTickTimestamp = 0;
int mode = idle;
bool ledOn = false;
void turnSignalControllerSetMode(int newMode) {
if (newMode == mode) {
return;
}
mode = (Modes)newMode;
lastTickTimestamp = 0;
updateState();
}turnSignalControllerTick() method is called from the main application loop. lastTickTimestamp stores the last timestamp (number of milliseconds passed since the Arduino board began running the current program) and compares it with the current timestamp. The result is a timer with a 500ms interval.
void turnSignalControllerTick(int currentTimestamp) {
if (mode == idle) { return; }
if ((currentTimestamp - lastTickTimestamp) > tickInterval) {
lastTickTimestamp = currentTimestamp;
updateState();
}
}Method updateState() turns LEDs on and off depending on the current mode.
void updateState() {
if (mode == idle) {
ledOn = false;
} else {
ledOn = !ledOn;
}
int value = ledOn ? HIGH : LOW;
switch (mode) {
case idle:
case blinkBoth:
digitalWrite(pinTurnSignalLeftFront, value);
digitalWrite(pinTurnSignalLeftRear, value);
digitalWrite(pinTurnSignalRightFront, value);
digitalWrite(pinTurnSignalRightRear, value);
break;
case blinkLeft:
digitalWrite(pinTurnSignalLeftFront, value);
digitalWrite(pinTurnSignalLeftRear, value);
digitalWrite(pinTurnSignalRightFront, LOW);
digitalWrite(pinTurnSignalRightRear, LOW);
break;
case blinkRight:
digitalWrite(pinTurnSignalLeftFront, LOW);
digitalWrite(pinTurnSignalLeftRear, LOW);
digitalWrite(pinTurnSignalRightFront, value);
digitalWrite(pinTurnSignalRightRear, value);
break;
}Connect DC motors to the Motor Control Shield L293D:
const int pinMotorDrive_dir1 = 8;
const int pinMotorDrive_dir2 = 7;
const int pinMotorDriveSpeed_pwm = 10;
const int pinMotorTurn_dir1 = 12;
const int pinMotorTurn_dir2 = 13;
const int pinMotorTurnSpeed_pwm = 11;
void configureMotorPins() {
pinMode(pinMotorDrive_dir1, OUTPUT);
pinMode(pinMotorDrive_dir2, OUTPUT);
pinMode(pinMotorDriveSpeed_pwm, OUTPUT);
pinMode(pinMotorTurn_dir1, OUTPUT);
pinMode(pinMotorTurn_dir2, OUTPUT);
pinMode(pinMotorTurnSpeed_pwm, OUTPUT);
digitalWrite(pinMotorDrive_dir1, 1); // set forward direction
digitalWrite(pinMotorDrive_dir2, 0); // set forward direction
digitalWrite(pinMotorDriveSpeed_pwm, HIGH); // set to high to enable the L293 driver chip
analogWrite(pinMotorDriveSpeed_pwm, 0); // set speed to 0
digitalWrite(pinMotorTurn_dir1, 1); // set forward direction
digitalWrite(pinMotorTurn_dir2, 0); // set forward direction
digitalWrite(pinMotorTurnSpeed_pwm, HIGH); // set to high to enable the L293 driver chip
analogWrite(pinMotorTurnSpeed_pwm, 0); // set speed to 0
}Speed parameter (0-127 - drive backwards, 127 - stop, 128-255 - drive forward) must be converted into a speed (0-255) and direction. Choose the minimum speed/voltage depending on the car weight and DC motor parameters.
void drive(byte value) {
int minSpeedValue = 100;
int maxSpeedValue = 255;
if (value < 127) { // backwards
digitalWrite(pinMotorDrive_dir1, 0);
digitalWrite(pinMotorDrive_dir2, 1);
int speedValue = minSpeedValue + (maxSpeedValue - minSpeedValue) * (127 - value) / 127;
analogWrite(pinMotorDriveSpeed_pwm, speedValue);
} else if (value > 127) { // forward
digitalWrite(pinMotorDrive_dir1, 1);
digitalWrite(pinMotorDrive_dir2, 0);
int speedValue = minSpeedValue + (maxSpeedValue - minSpeedValue) * (value - 127) / 127;
analogWrite(pinMotorDriveSpeed_pwm, speedValue);
} else { // 127 stop
digitalWrite(pinMotorDrive_dir1, 1);
digitalWrite(pinMotorDrive_dir2, 0);
analogWrite(pinMotorDriveSpeed_pwm, 0);
}
}Connect potentiometer pins to the board:
const int pinPotentiometer = A0;
int readPotentiometer() {
int sensorValue = analogRead(pinPotentiometer);
return sensorValue;
}Convert target angle received from an iPhone (0-255) to integer (0-1024) in order to compare it with the potentiometer reading.
void turnWheels(byte value) {
int minLeft = 300; // it means that the wheels are turned all the way to the left
int maxRight = 900; // wheels turned all the way to the right
int center = 600; // wheels are straight
if (value < 127) { // turn left
turnSignalControllerSetMode(1);
float factor = ((float)value)/127.0;
targetTurnValue = minLeft + factor * (center - minLeft);
} else if (value == 127) { // straight
turnSignalControllerSetMode(0);
targetTurnValue = center;
} else if (value > 127) { // turn right
turnSignalControllerSetMode(2);
float factor = ((float)value - 127.0) / 128.0;
targetTurnValue = center + 1 + factor * (maxRight - center - 1);
}
}Method handleTurn() does a few things:
Choose the speed/voltage depending on the DC motor parameters.
void handleTurn() {
int sensorValue = readPotentiometer();
const int tolerance = 20;
const int speed = 130;
if (abs(sensorValue - targetTurnValue) < tolerance) {
// value reached, stop motor
analogWrite(pinMotorTurnSpeed_pwm, 0);
} else if (sensorValue > targetTurnValue) {
// turn left
digitalWrite(pinMotorTurn_dir1, 0);
digitalWrite(pinMotorTurn_dir2, 1);
analogWrite(pinMotorTurnSpeed_pwm, speed);
} else if (sensorValue < targetTurnValue) {
// turn right
digitalWrite(pinMotorTurn_dir1, 1);
digitalWrite(pinMotorTurn_dir2, 0);
analogWrite(pinMotorTurnSpeed_pwm, speed);
}
}
That’s pretty much everything. I hope you enjoyed this article and you will build your toy car!
All the signs in the sky tell us that Machine Learning and Artificial Intelligence will be as important of a revolution as web browsers or smartphones were back in the day. Unfortunately, this technology has a relatively steep learning curve, which makes its adoption much slower. Very few companies can afford a dedicated data scientist on the payroll. If they do, often, the quality or the amount of data becomes the problem, and just won’t be enough to train your models well.
Fortunately, there are companies on the market that provide very well-trained models and easy to integrate Machine Learning APIs for everyday use cases that you can incorporate into your project and thus take advantage of cutting-edge technology without making the leap of faith. In this blog post, I’d like to point your attention to some of those use cases, which can be the low-hanging fruit you can pick right up.
When thinking about AI and machine learning, a problem of recognizing patterns in an image usually comes first to our mind. Facial recognition, pattern recognition, QR or barcode read-out, detecting inappropriate images before they get published, matching face to a person and many many more use cases fall into this category. As with everything, when a problem is fairly common and there are many solutions to tackle it out there. Let’s first have a look at what device vendors offer us in their platform SDKs.
Apple’s CoreML and CreateML
It turns out both Apple and Google have been offering quite a set of APIs we can take advantage of to perform image recognition directly on a device. In the case of iOS devices, we got CoreML framework with several pre-trained models (for example for face detection or optical character recognition) along with a very easy to use software for training your own models called CreateML. One of the key changes in the third version of this framework is the ability to re-train your models on-device, so your apps can get smarter as users use them, without breaching their privacy because no data will leave their handset or tablet.
Google’s MLKit
Of course, Google has a counterpart to CoreML called MLKit. Things get very interesting with Google’s offering because they made MLKit very closely integrated with Firebase (Google’s Backend as a Service platform) therefore the framework is available for both iOS and Android. What’s more, it can work in two scenarios - on-device and powered by the cloud, both of which have their pros and cons. Integrating MLKit is just a few lines of code and it’ll let you tackle a number of image recognition related problems for instance: detect faces, read barcodes, detect & track objects, recognize and label objects in an image and more. Obviously you’ll have to keep in mind the fact that your performance on the device will be much faster than when sending heavy imagery over to Google’s infrastructure, but you’ll be limited to only light and limited models. A good example may be OCR - on the device, you will only be able to detect alphanumeric characters.
Google’s Cloud Vision
If for whatever reason you don’t want to do the work on the client-side, you’re not out of luck, as there’s plenty of APIs you can take advantage of and move heavy lifting to the cloud. One of my favorite ones is Google’s Cloud Vision. As with any cloud services these APIs, unfortunately, don’t come free, however, usually, you’ll get a few free credits to start and experiment with.
Cloud Vision will let you do as much as previous examples of on-device frameworks and more, after all, you’ll be using Google’s state of the art infrastructure and extremely well-trained models on loads of data. One of the best examples of the quality results I often show people is the case of New York Times digitizing their entire photo library with Google Cloud. What’s really interesting in this example is how they took the result of the OCR process and piped it into another API for NLP (natural language processing) to understand things written on the back of the photos. Similar APIs are offered by Amazon under their Rekognition service, Microsoft under Azure Cloud and IBM on their Watson platform.
Another very common ML application is Natural Language Processing and everything that’s related to pulling insights from unstructured blocks of text. Overall it’s an extremely tough nut to crack because of the multitude of languages, dialects, wording styles, etc. Thankfully there are APIs that can help you tackle this problem, the bad news is you’ll be pretty much exclusively limited to the cloud - the models to address this are way too heavy for doing it on the device.
Looking at providers, again we have the usual suspects: Amazon Comprehend, Google Natural Language, and IBM Watson Natural Language Understanding. They all will obviously give you very different results, so before you start integrating any of these services make sure you thoroughly test each and every one of them. Ideally, you’ll want to structure your code so that it’ll be relatively easy to swap services underneath because all of them change and you may start with one, but decide you’ll want to change it later in the project lifecycle.
What kind of results can you expect after applying these models to your text? First of all, you’ll get a list of classified entities. You’ll also be provided with detailed sentiment analysis of the entire text, structural sentence breakdown, some high-level categories visible in the text, and much more. Following up on the example from the previous paragraph, once folks from NYT recognized all the labels on the back of the millions of photos they attempted to digitize, they feed these results into Google’s NLP service and were able to pick out important details of the photos like where it was taken, when, what’s on the photo and additional metadata from the back.
Making conclusions based on user behavior in the app is just a perfect case for applying heavy ML. So far in this scenario we’re pretty much limited to only one vendor: Google Firebase, however, it’s well worth giving it a go.
By using several products from under Firebase umbrella (RemoteConfig, A/B Testing, Notifications, and Predictions) you can target users who are (according to Google’s models) likely to churn and shower them with promotions via push notifications convincing them to stick around. Or do just the opposite - you can segment out users who are likely to make a purchase.
Because the system learns as people use your digital product you can create custom predictions based around your own events created in the Firebase analytics and then pick out users who are likely to hit them. Finally, thanks to Firebase’s integration with BigQuery you can export both events from your Analytics as well as Predictions and crunch them directly in BigQuery for further analysis.
Best of all, Firebase Predictions are free of charge on all Firebase plans, so the barrier to entry is almost non-existent.
As you can see there are plenty of platforms offering various APIs and models for a lot of different scenarios. And we’ve only covered a few relatively common cases. I highly encourage you to dip your toes into the services I mentioned, the time investment is minimal and you can try out a number of APIs that can bring a lot of value to your product and your users. Also, it’s a great way to get started with machine learning and eventually level up into building your own models and APIs, from there onwards sky is a limit!
Cover Photo by Hunter Harritt
liveDataVar
.distinctUntilChanged()
.map { /* do the RX magic */}
.nonNull()
.take(3)
RxBroadcastReceivers
.fromIntentFilter(
context,
IntentFilter(LocationManager.MODE_CHANGED_ACTION))
.subscribe {
// react to broadcast
}
disposable = url.download() .observeOn(AndroidSchedulers.mainThread()) .subscribeBy( onNext = { progress -> //download progress button.text = "${progress.downloadSizeStr()}/${progress.totalSizeStr()}" button.setProgress(progress) }, onComplete = { //download complete button.text = "Open" }, onError = { //download failed button.text = "Retry" } )
American drivers spend an average of 293 hours a year behind the wheel. According to McKinsey & Company, in 2018 40 percent of them said they would change car brands for better connectivity. The drive to feeling connected increases every year, and strongly influences the world’s biggest industries.
At Intent, we’ve been looking at this automotive revolution for a while, and actually have worked on some car solutions so, obviously, we have our favorite car apps for iOS. I’ve decided to do a quick survey among friends, acquaintances, and colleagues inside and outside the company to find out which apps are rockin’ people’s phones. This resulted in a list of 5 apps most of us use almost every day. Wanna know who won our hearts?
Waze is the world’s largest community-based traffic and navigation app. They proved that when it comes to perfect navigations it’s exactly how their website says — “nothing can beat real people working together”. Waze is this perfect kind of collective consciousness that gets you alerted on everything that’ happening on the road — accidents, traffic jams, police patrols, or road hazards, and it happens in real-time. Not to mention that the maps are being constantly updated.
Another thing people love about Waze is that you can effortlessly sync with your friends via Facebook and when driving to the same destination coordinate everyone’s arrival times and check how they’re doing on the way.
Oh, almost forgot — with this app you can literally save your money by navigating to the cheapest gas stations on your route. How freakin’ cool is that?
And they have a carsharing app too!
Seriously, I love Waze.
Btw. Waze has 90mln users monthly in 185 countries
Imagine you’re hitting the long road with someone who:
Yes, my friends. Such a driving partner exists. And it’s called Audible. And it’s great for short rides too!
Btw. The longest audiobook ever is “50 Lectures” by Takaaki Yoshimoto (Japan) and it lasts 6,943 minutes (115 hours and 43 minutes). Challenge accepted?
Driving with friends and family on board is sweet but let’s be honest — sometimes you just want them to shut the f❤❤k up and you’ve every right to feel to it. Instead of saying something that will make you look like an asshole, you say (using this spontaneous voice of yours): “Hey guys, I’ve just discovered an endless source of great podcasts, you need to hear some of them right now!” and put on some nice podcast via Overcast before they answer. An easy and peaceful way! They’re not offended and you get to listen to what YOU want — is that a win-win situation or my glasses are just blurry?
Also, people that don’t like driving alone and/or feel lonely in a car will have great use of this app too — a lot of different people, topics, and opinions are just one touch away. Almost like Tinder, but without creeps!
Btw. Please NEVER Tinder and drive!
I strongly believe there’s no proper car ride without a sing-a-long and believe me with other inFullSingers by my side — iHeartRadio is the best app that will help you to climb on the top of your vocal skills (read: scream your head off).
But seriously, iHeartRadio gives you unlimited streaming music, thousands of live radio stations, a lot of podcasts, and playlists crafted for any moods or activities. You can search by music genres, artist radio stations, and also create your own playlists, of course. There’s so much audio content here my head hurts!
Sometimes you’re just too overloaded with stuff to do that you forget where the hell is your car parked. Don’t worry — there’s a kind soul that will guide you through the mysterious and sometimes even multi-level mazes of parking areas and the spiderwebs of streets. Apple Maps automatically detect where you’ve left your car, and help to keep your stress level low.
1 in 7 American drivers has forgotten where they parked their vehicles and have spent a collective 200 years looking for them.
Interested in AndroidAuto apps too? Don’t miss this article! Also, make sure to take a look at our car apps statistics. If you feel inspired to build an automotive app of your own, don't hesitate to request a free quote via the contact page or drop us an email.
Cover photo by Alessio Lin on Unsplash
Scrum. This mythical thing I’m sure you’ve at least heard about. There is also a pretty fair chance that you already know that Scrum is a framework for developing and delivering all sorts of products. That it has events, roles, values, and artifacts. If you don’t, you definitely should. If you do, you probably don’t. Trust me, if you’re about to take a PSD certification you’ll find out soon enough.
There are three main Scrum certificates — Professional Scrum Master, Professional Scrum Product Owner, and Professional Scrum Developer. It might be a little tricky when choosing the right one for yourself. One might wonder why even bother taking any other exam when you can just go with a Scrum Master title? The bottom line is that PSD or PSPO is not worse than PSM. Each has its own area of expertise and each is equally valuable. Developer’s exam focuses not only on Scrum’s theory but also requires strictly development-related knowledge like Test-Driven Development and Continuous Integration. So, if you’re a developer and you’re not planning to be a Scrum Master anytime soon, taking a PSD exam is more recommended. It will give you the skills to work efficiently as a professional in a Scrum-led project.
First and probably the most important rule is: STICK TO THE SCRUM GUIDE. There is no way around it. The Guide is short enough to get to know it in just a few readings, but you will probably need more than that to truly remember every detail. I would also recommend reading it in your native language at least once to make sure everything is clear. Also, don’t get me wrong — there are tons of different sources out there. Most of them are free and good. Reading them might be profitable as far as you can relate to every information you read to the Scrum Guide content.
PSD also requires knowledge that is specific to the developers’ world. That includes:
If you have any doubts about any of those subjects, I recommend filling all gaps before taking an exam.
Later, after the reading is done, you should proceed to practice. There are two online preparation tests I’ve been doing. First is the official Open Assessment. It contains solely legitimate questions that will most likely appear in the exact form on the exam. The second option is the Scrum Quiz provided by Mikhail Lapshin that covers the most important aspects of Scrum theory. When to know you’re ready? I had a simple rule. If you pass the official test with a 100% score five times in a row, then you most likely know enough to pass the exam. Take your time — mastering those quizzes will definitely pay you back.
The idea of the exam is rather simple. First, you create an account at scrum.org. Then you need to buy a password key for the PSD certificate. The cost, as of August 2018, is $200. When you’re ready you enter the password and the exam begins. There are 80 multiple-choice and true/false questions. Time-box is 60 minutes. You’ll need at least 85% to pass the exam which gives at least 68 positive answers. You get the result instantly after finishing the exam.
The good thing about the exam is that you can take it wherever and whenever you please. Thanks to that you can (and definitely should) make certain preparations. First of all, have a Scrum Guide by your side at all times. Best if it’s printed so you can quickly look-up things you’re not sure of.
Secondly, you might be tempted to google things as nobody is watching you — it’s not an entirely bad idea but you must know that almost always you won’t find exact answers to exact questions, and looking for others will be a waste of your precious time.
The system gives you a great feature that lets you mark questions you would like to come back later. Use it. Mark questions you’re don’t know an answer to and leave them for the end. The exam gives you less than 1 minute per answer so time is essential here.
What is most important in passing the PSD certification exam is that you are familiar with the type of questions you will be asked. There is a certain idea behind them which in short sounds like “Scrum is the best. It will cure all your problems and make your life a paradise.”. Seriously, that’s the key. Also, there won’t be too much time for contemplation so make sure you buckle down to preparations. Mostly to the official Open-Assessment as you will tackle the same questions during the exam. Lastly, don’t worry! The exam is fairly simple so you’ll be just fine! :)
430*10= 4300 ohm = 4.3 kOhm!That was easy, right? Of course, you are not the only one thinking that remembering all of these colors and values is a no-go. So a bunch of great people came up with an idea of a resistor color code calculators. You can find it here. Also, check out AppStore and Google Play for some awesome apps doing the same thing. They may also be handier. SMD components, as well as reading their values, will be covered in another blog post of this series. Stay tuned! So we’ve got potentiometers and fixed value resistors. These are the most widely used types of components, which regulate resistance.
contract NumberContract {
address private contractIssuer;
uint private number;
modifier onlyContractIssuer {
require(contractIssuer == msg.sender);
_;
}
function NumberContract() public {
contractIssuer = msg.sender;
}
function setNumber(uint newNumber) onlyContractIssuer public {
number = newNumber;
}
}
Events are inheritable members of contracts. When they are called, they cause the arguments to be stored in the transaction’s log — a special data structure in the blockchain. These logs are associated with the address of the contract and will be incorporated into the blockchain and stay there as long as a block is accessible. Log and event data is not accessible from within contracts (not even from the contract that created them).
contract NumberContract {
address private contractIssuer;
uint private number;
event NumberSet(uint number);
modifier onlyContractIssuer {
require(contractIssuer == msg.sender);
_;
}
function NumberContract() public {
contractIssuer = msg.sender;
}
function setNumber(uint newNumber) onlyContractIssuer public {
number = newNumber;
NumberSet(newNumber);
}
}
Solidity supports multiple inheritance by copying code including polymorphism. All function calls are virtual, which means that the most derived function is called, except when the contract name is explicitly given. When a contract inherits from multiple contracts, only a single contract is created on the blockchain, and the code from all the base contracts is copied into the created contract. The general inheritance system is very similar to Python’s, especially concerning multiple inheritance.Function visibility: external While in Solidity almost all types of function visibility (private, public, and internal) are intuitive and similar to these in Java, one is different. A function can be declared as external which means it can be called only from other contracts and by transactions. Calling it internally is impossible. Function modifiers: pure, view, payable When a function is declared as pure, it cannot modify or even access the state (variables, mappings, arrays, etc.). It’s the most restrictive modifier but it is the most secure and saves the most gas when applied. The view is slightly more allowing modifier. It basically acts the same as pure but allows access to the state (but it still cannot modify it though). When we want a function to be able to receive Ether together with a call, we declare it as payable. It allows for money transfers, deposits, and basically handling money in every way needed.
contract NumberContract {
address private contractIssuer;
uint private number;
mapping(address => uint256) public availableWithdrawals;
modifier onlyContractIssuer {
require(contractIssuer == msg.sender);
_;
}
modifier hasPositiveBalance(address user) {
require(availableWithdrawals[user] > 0);
_;
}
function NumberContract() public {
contractIssuer = msg.sender;
}
function deposit() public payable {
availableWithdrawals[msg.sender] =
safeAdd(availableWithdrawals[msg.sender], msg.value)
}
function withdraw() public payable hasPositiveBalance(msg.sender) {
uint256 amount = availableWithdrawals[msg.sender];
availableWithdrawals[msg.sender] = 0;
msg.sender.transfer(amount);
}
function getAmountToWithdraw() public view returns (uint256) {
return availableWithdrawals[msg.sender];
}
function safeAdd(uint256 a, uint256 b) internal pure returns (uint256) {
uint256 c = a + b;
assert(c >= a);
return c;
}
function setNumber(uint newNumber) onlyContractIssuer public {
number = newNumber;
}
}
for (var i = 0; i < a.length; i++) { a[i] = i; }
will enter an infinite loop if the "a" array is longer than 255 elements (the iterator will wrap around back to 0). This is despite the underlying VM using 256 bits to store this byte. You should just know about this and declare "i" as uint instead of var.
Operator’s semantics
Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0. Precision of the operation is also determined in this manner — literals are arbitrary-precision, other values are constrained by their types.Mapping Mappings, unlike maps in Java, don’t throw an exception on non-existing keys. They just return the default value depending on the key type (when keys are integers, 0 will be returned). What’s more, there is no way to check if an element exists (like contains() in Java) — when 0 is returned we don’t know if a key was added to the mapping with value 0 or is it the default value being returned because there is no such key in the mapping. There’s also no built-in method of extracting a key or value sets from a mapping which means iterating over a key set is not possible.
protocol LocationFetchterDelegate: class {
func locationFetcher(_ fetcher: LocationFetcher, didUpdateLocation location: CLLocation)
}
final class LocationFetcher {
weak var delegate: LocationFetcherDelgate?
//Class implementation goes here
}
This solution has a few problems:
final class LocationFetcher {
let location: Observable<CLLocation>
}
As we can see, problem #1 is gone. We have one immutable property location which emits location updates and no component can modify it. Our program not only more deterministic but since we don’t need a specific reference to the delegate, we got rid of the additional protocol as well! Let’s see how subscribing to updated would look like:
let locationFetcher: LocationFetcher //Assume exists
locationFetcher.location
.observeOn(MainScheduler.instance)
.subscribe(onNext: { print("new location: \($0)") })
.disposed(by: disposeBag)
This solves problems #2 and #3. As we can see, RxSwift allows us to specify on which thread we’re receiving the updates, as well as multiple objects, can subscribe to a single stream to get updates via simple DSL-like API.
![Elon Musk about the future [infographic]](https://withintent.com/app/uploads/2020/04/1kxBrIdeeKTu7OLo9OSCX1g.jpg)
System listens to the presence of a person → Person near by the door (with smartphone) → System detects presence → Person launches the application → Person unlocks the door via the app → System verifies permissions → System unlocks the doorOur solution:
System listens to the presence of a person → Person near by the door (with iPhone) → System detects presence → Person presses the gate opening button on the door → System verifies the permissions → System unlocks the doorPlease, notice how comfortable it is. No waisting time for getting the phone, launching the app, and interacting with the app to open the door. It’s as simple as one button click. How safe is our solution? Please, keep in mind that the level of security against unauthorized use does not have to be very high here — the purpose is to prevent people who should not cross the building’s gate, but it won’t be a barrier for a person who previously possesses an iPhone with granted access to the gate. That’s why our solution is suitable for managing access to a building, but it should not be used to control access to housing. Here, we focus on the convenience of use with a reasonable level of security. Prerequisites:
$ sudo apt-get update $ sudo apt-get dist-upgrade $ curl -sL https://deb.nodesource.com/setup_9.x | sudo -E bash - $ sudo apt-get install -y nodejsThe above sequence guarantees the latest versions of the packages, and then we install the latest version of Node.js. To check whether the operation was successful and what Node.js version we have, run the command:
$ node --versionThe next step is to install the Node.js libraries that are used in the application and these are:
$ npm install uuid
$ npm install node-cache
$ npm install rpi-gpio
$ npm install rpi-gpio-buttons
$ npm install request
$ mkdir /home/pi/gateguardDownload the ZIP-ed source code from GitHub and unpack it, and then move *.js files to the newly created folder:
$ wget -O gateguard-rpi.zip https://github.com/inFullMobile/gateguard-rpi/archive/master.zip
$ unzip gateguard-rpi.zip
$ cp -r gateguard-rpi-master/* /home/pi/gateguard/We still have one more thing to configure, but we can’t do it until the app in the cloud is setup — it is about a generated URL address of our application, which will be included in the code on PRi, so that RPi can connect to it in the cloud. Raspberry Pi is almost ready… so it’s time to launch another element of our system — a service in the cloud, which will be responsible for coordinating communication between the iPhone and RPi. Two more elements of the system require an Xcode environment (preferably the newest one, currently Xcode 9.3) and if you do not have it yet, please install it from the Apple AppStore store (https://itunes.apple.com/pl/app/xcode/id497799835?mt = 12), then launch and complete the installation. The cloud app will be deployed on the Heroku platform, where we can host our application for free for development and education purposes. As the first step, I suggest setting up an account on the Heroku platform, within which our application will be deployed and maintained. Go to heroku.com and create an account (if you do not have one already). Then we will need the Heroku Command Line Interface (aka Heroku CLI) installed on the computer. We’ll use it to deploy the application. To install Heroku CLI, follow the instruction: Heroku CLI Installation. As the application is written with the Vapor framework (Swift on board), please install Vapor Tool Box which will support the app: Vapor Tool Box Installation. In the next step, download the application code from the repository. To do this efficiently, use the Git client: $ git clone https://github.com/inFullMobile/gateguard-cloud.git Let’s prepare our project for deployment with Heroku CLI commands:
$ cd gateguardcloud
$ rm -rf .git #it removes current git version control files $ heroku login #once asked, provide your username (email) and password
#create new git local repository
$ git init
$ git add .
$ git commit -m “Initial commit”We can now deploy our application to Heroku servers:
$ vapor heroku initas a result, you will be asked some questions and you may answer as I did:
Would you like to provide a custom Heroku app name?
y/n> n
Would you like to deploy to a region other than the US?
y/n> y
Region code (us/eu):
> eu
https://pacific-lowlands-45092.herokuapp.com/ | https://git.heroku.com/pacific-lowlands-45092.git
Would you like to provide a custom Heroku buildpack?
y/n> n
Setting buildpack...
Are you using a custom Executable name?
y/n> n
Setting procfile...
Committing procfile...
Would you like to push to Heroku now?
y/n> y
This may take a while...
Building on Heroku ... ~5-10 minutes [ • ]and finally
Building on Heroku ... ~5-10 minutes [Done]
Spinning up dynos [Done]
Visit https://dashboard.heroku.com/apps/
App is live on Heroku, visit
https://pacific-lowlands-45092.herokuapp.com/ | https://git.heroku.com/pacific-lowlands-45092.gitRemember generated domain for your cloud app for later use (in my case it is https://pacific-lowlands-45092.herokuapp.com) It is a good moment to return to the code on RPi and configure the correct URL address of our service in the cloud. To do this, reconnect to RPi via SSH and open the file /home/pi/gateguard/cloud_module.js for editing then enter the correct address of the service on Heroku (code: line 35). In my case it looks like this:
uri: ‘https://pacific-lowlands-45092.herokuapp.com/register-token'We need two more unique identifiers for Bluetooth communication, and you can get them by doing a 2× command:
$ uuidgenIn my case, it has been generated UUIDs:
93384AB6–9EB1–4AF2–90FB-F88ABB6F79AF
4E98BE1C-F8D9–46AD-9D08-C0AAA7DFEE7A
this.bleServiceUUID = '93384AB6-9EB1-4AF2-90FB-F88ABB6F79AF' this.bleCharacteristicUUID = '4E98BE1C-F8D9-46AD-9D08-C0AAA7DFEE7A'Are you ready to launch the program on PRi? 10… 9… 8…
$ nohup sudo node /home/pi/gateguard/gateguard.js > /home/pi/gateguard/gateguard.log &where the nohup command will guarantee the work of the program in the background as we disconnect from the RPi, while sudo is necessary for our program to work on permissions allowing it to access BLE and IO ports of our microcomputer. All logs thrown by our program will go to gateguard.log file.
$ git clone https://github.com/inFullMobile/gateguard-ios.gitand open the project in Xcode. Before running on the iPhone, set the correct URL address of the app in the cloud, what can be done in the project’s source file HttpClient.swift — change the address assigned to the constant:
// That's my URL address! Use yours ;) static let gateGuardHost = URL(string: "https://pacific-lowlands-45092.herokuapp.com")!Now configure the correct UUIDs for BLE service and characteristic in the BLEService.swift file (remember to assign appropriate UUIDs to service and characteristics — the same as in sources of PRi app):
static var serviceUUID: CBUUID {
return CBUUID(string: "93384AB6-9EB1-4AF2-90FB-F88ABB6F79AF")
}
static var newTokenNotificationCharacteristicUUID: CBUUID {
return CBUUID(string: "4E98BE1C-F8D9-46AD-9D08-C0AAA7DFEE7A")
}Ensure that Bluetooth on iPhone is ON! Now you can launch the application on your phone. Congratulations! You did it! Our GateGuard should now work as expected — test it with alternately Bluetooth switched ON and OFF on the phone, and you will observe the result of the action in the form of flashing or glowing LEDs and the operation of the relay, which connected to the electro lock will unlock the gate to the building. For your information, I’ll explain the LEDs behavior:
onSubscribe(maxValueSize, callback) {
console.log('BLE characteristic subscribed')
shared.subscribedToCharacteristic = true
this.valueDidChangeCallback = callback
}
Generation of authorization token is done by the code:
const tokenId = Math.floor(Math.random() * MAX_TOKEN_ID) const token = uuid()Transferring token to the cloud app is done this way:
registerTokenInCloud(tokenId, token, completionCallback) {
console.log('register token in cloud service')
if (!this.requestInProgress) {
console.log('http request')
const _this = this
this.requestInProgress = true
request(this._requestOptions(tokenId, token), function(error, response, body) {
console.log('http response')
_this.requestInProgress = false
if (!error && response.statusCode == 200) {
console.log('New token registered on cloud service with success')
completionCallback(true)
} else {
console.error('Error while registering token in cloud service: ' + error)
completionCallback(false)
}
})
}
}
_requestOptions(tokenId, token) {
return {
uri: 'https://gateguard.herokuapp.com/register-token',
method: 'POST',
json: {
"id": tokenId,
"token": token
}
}
}
Another step is the validation of the token:
onWriteRequest(data, offset, withoutResponse, callback) {
console.log('Authorization request from mobile phone')
this.greenLedManager.off()
var dataParts = data.toString().split('|')
const tokenId = dataParts[0]
const token = dataParts[1]
var cachedToken = null
try {
cachedToken = shared.cache.get(tokenId, true)
if (token.toUpperCase() == cachedToken.toUpperCase()) {
console.log('Token is valid! Opening the gate...')
this.greenLedManager.on(led.LEDModeEnum.solid, shared.ELECTROLOCK_ON_DURATION)
this.relayManager.on(shared.ELECTROLOCK_ON_DURATION)
} else {
console.log('Token is invalid - access to the gate denied!')
this.redLedManager.on(led.LEDModeEnum.solid, shared.ELECTROLOCK_ON_DURATION)
}
callback(0)
} catch (err) {
console.log('Error: ' + err)
callback(1)
}
}
Electro lock controlling is implemented in relay_module.js.
Opening the gate is happening here:
this.relayManager.on(shared.ELECTROLOCK_ON_DURATION)
private func scanForPeripheral() {
guard self.isElectronicKeyActive else { return }
self.centralManager.scanForPeripherals(withServices: [CBUUID.serviceUUID],
options: [CBCentralManagerScanOptionAllowDuplicatesKey: NSNumber(booleanLiteral: true)])
}
and successively
func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
guard error == nil else { return }
guard let service = peripheral.services?.filter({ $0.uuid == CBUUID.serviceUUID }).first else {
return
}
peripheral.discoverCharacteristics([CBUUID.newTokenNotificationCharacteristicUUID], for: service)
}
func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
guard let characteristic = service.characteristics?.filter({ $0.uuid == CBUUID.newTokenNotificationCharacteristicUUID }).first else {
return
}
self.storedCharacteristic = characteristic
peripheral.setNotifyValue(true, for: characteristic)
}
Once the peripheral device is connected and the gate’s button pressed, it generates new authorization token (unknown for iPhone’s app) and requests for it. The token is sent to RPi app right after being taken from cloud service.
self.bleService.tokenDidRequestCallback = { [weak tokenService, weak bleService] (_ tokenId: Int) in
tokenService?.getToken(with: tokenId) { (_ result) in
switch result {
case .success(let token):
bleService?.respond(withToken: token)
case .error(let error):
let errorMessage = String(describing: error)
print("Error: \(errorMessage)")
}
}
}
post("register-token") { req in
guard let id = req.json?["id"]?.int, let token = req.json?["token"]?.string else {
return Response(status: .badRequest)
}
try self.cache.set("\(id)", token, expiration: Date(timeIntervalSinceNow: Constants.tokenDuration))
return Response(status: .ok)
}
The second is implemented this way:
get("token") { req in
guard let id = req.query?["id"]?.int else {
return Response(status: .badRequest)
}
var json = JSON()
guard let token = try self.cache.get("\(id)") else {
return Response(status: .noContent)
}
try json.set("id", id)
try json.set("token", token)
return json
}
As you can see, all pieces of the system talk to each other via BLE and HTTPS. Details of implementation you can always find in provided repositories.
That was huge fun for me to build that system and I hope you may find it interesting too.
The goal of CanonHackathon was to prove that video projectors can be used not only for watching movies.Teams came up with different ideas. Above you can see the team that created an interactive art installation made out of 3 projectors and Arduino and a plant. Another team created a project that helped people to connect a lot of projectors together in an easy way.
repositories {
maven { url 'https://maven.infullmobile.com/public' }
}
compile 'com.infullmobile.android:infullmvp-kotlin:1.1.14' testCcompile 'com.infullmobile.android:infullmvp-kotlin-basetest:1.1.14'
allprojects {
repositories {
...
maven { url 'https://jitpack.io' }
}
}
Include the following dependency:
compile 'com.github.AmeerHamzaaa:TNImageView-Android:0.1.2'Create an activity layout so it looks like this:
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<ImageView
android:id="@+id/slideShowImage"
android:layout_width="100dp"
android:layout_height="100dp"
android:clickable="true"
android:src="@drawable/ice_cream"/>
</RelativeLayout>
Now let's initialize a TNImageView:
class MainActivityView @Inject constructor() : PresentedActivityView<MainActivityPresenter>() {
@LayoutRes override val layoutResId = R.layout.activity_main
val slideShowImage: ImageView by bindView(R.id.slideShowImage)
override fun onViewsBound() {
TNImageView().makeRotatableScalable(slideShowImage)
}
}
Our result:
private fun skewBitmap(src: Bitmap, xSkew: Float, ySkew: Float): Bitmap {
val xCoordinates = 0
val yCoordinates = 0
val matrix = Matrix()
matrix.postSkew(xSkew, ySkew)
return Bitmap.createBitmap(src, xCoordinates, yCoordinates, src.width, src.height, matrix, true)
}
So now we can skew our ImageView
data class ResponseInstaByTag(
@field:SerializedName("data")
val data: List<DataItem>
)
data class DataItem(
@field:SerializedName("images")
val images: Images
)
data class Images(
@field:SerializedName("standard_resolution")
val standardResolution: StandardResolution
)
data class StandardResolution(
@field:SerializedName("url")
val url: String
)
2. Define API service interface:
interface InstagramApiService {
@GET("tags/{tag}/media/recent?access_token=YOUR_ACCESS_TOKEN")
fun getPicsByTag(@Path("tag") tag: String): Single<ResponseInstaByTag>
}
3. Initialize HTTP client Retrofit. The whole main module should look like this:
@Module
public abstract class MainActivityModule {
private static String BASE_URL = "https://api.instagram.com/v1/";
@MainActivityScope
@Provides
static Retrofit providesRetrofit() {
return new Retrofit.Builder()
.baseUrl(BASE_URL)
.addConverterFactory(GsonConverterFactory.create())
.addCallAdapterFactory(RxJava2CallAdapterFactory.create())
.build();
}
@MainActivityScope
@Provides
static MainActivityView providesMvpView() {
return new MainActivityView();
}
@MainActivityScope
@Provides
static InstagramApiService providesInstagramApiService(Retrofit retrofit) {
return retrofit.create(InstagramApiService.class);
}
@MainActivityScope
@Provides
static Scheduler providesScheduler() {
return Schedulers.io();
}
@MainActivityScope
@Provides
static GetPicturesByTagUseCase providesGetPicturesByTagUseCase(Scheduler scheduler,
InstagramApiService instagramApiService) {
return new GetPicturesByTagUseCase(scheduler, instagramApiService);
}
@MainActivityScope
@Provides
static MainActivityModel providesMvpModel(GetPicturesByTagUseCase getPicturesByTagUseCase) {
return new MainActivityModel(getPicturesByTagUseCase);
}
@MainActivityScope
@Provides
static MainActivityPresenter providesMvpPresenter(
MainActivityModel model,
MainActivityView view
) {
return new MainActivityPresenter(model, view);
}
@MainActivityScope
@Binds
abstract Context bindsContext(SampleMvpActivity activity);
}
4. Fetch images from Instagram:
class MainActivityPresenter @Inject constructor(
private val model: MainActivityModel,
view: MainActivityView
) : Presenter<MainActivityView>(view) {
private var disposableApiService: Disposable? = null
private val tagName = "sky"
override fun bind(intentBundle: Bundle, savedInstanceState: Bundle, intentData: Uri?) {
loadPictures(tagName)
}
private fun loadPictures(tag: String) {
disposableApiService = model.getPicturesByTag(tag)
.subscribe(
{ imagesList ->
val links = imagesList.data.map { dataItem -> dataItem.images.standardResolution.url }
presentedView.startSlideShow(links)
},
{ handleError(it) }
)
}
}
5. For starting slideshow we can use Interval operatorObservable.interval(delaySlideshow, TimeUnit.SECONDS. It will run loadImage() method every 3 seconds. Please pay attention to that we first load a picture and after we make a skew transformation on it. Why? Because if we'll not transform picture, we'll lose the previous state of a transformation. Add this code to MainActivityPresenter
fun startSlideShow(urls: List<String>) {
val delaySlideshow = 3L
disposableTimer = Observable.interval(delaySlideshow, TimeUnit.SECONDS)
.observeOn(AndroidSchedulers.mainThread())
.map { getNextPictureUrl(currentIndex, urls) }
.flatMap { url -> loadBitmapByUrl(url) }
.map { bitmap -> skewBitmap(bitmap, skewX, skewY) }
.subscribe(
{ bitmap -> presentedView.showPicture(bitmap) },
{ handleError(it) }
)
}
private fun getNextPictureUrl(urls: List<String>): String {
if (currentIndex >= urls.size) currentIndex = 0
return urls[currentIndex++]
}
private fun loadBitmapByUrl(url: String): Observable<Bitmap> {
return Observable.create<Bitmap> { emiter ->
Picasso.with(context).load(url).into(object : Target {
override fun onBitmapLoaded(bitmapParam: Bitmap, from: LoadedFrom?) {
emiter.onSuccess(bitmapWithTransformation)
}
override fun onPrepareLoad(placeHolderDrawable: Drawable?) {}
override fun onBitmapFailed(errorDrawable: Drawable?) {
emiter.onError(IllegalStateException("Bitmap loading has failed"))
}
})
}
}
6. Show loaded and transformed pictures on a screen. Add this code to MainActivityView:
fun showPicture(bitmap: Bitmap) = slideShowImage.setImageBitmap(bitmap)7. Always remember to dispose of disposables in a Presenter class to avoid memory leaks:
override fun unbind() {
super.unbind()
disposableApiService?.dispose()
disposableTimer?.dispose()
}
8. Connect Chromecast to the projector. In your phone go to Settings -> Connected devices -> Cast -> Select your Chromecast.
So now we have a slideshow on almost any 3d object in our room.
import UIKit
let printerOperation = BlockOperation()
printerOperation.addExecutionBlock { print("I") }
printerOperation.addExecutionBlock { print("am") }
printerOperation.addExecutionBlock { print("printing") }
printerOperation.addExecutionBlock { print("block") }
printerOperation.addExecutionBlock { print("operation") }
printerOperation.completionBlock = {
print("I'm done printing")
}
let operationQueue = OperationQueue()
operationQueue.addOperation(printerOperation)
import UIKit
class MonoImageOperation: Operation {
var inputImage: UIImage?
var outputImage: UIImage?
init(inputImage: UIImage) {
self.inputImage = inputImage
}
override public func main() {
if self.isCancelled {
return
}
outputImage = applyMonoEffectTo(image: inputImage)
}
private func applyMonoEffectTo(image: UIImage?) -> UIImage? {
guard let image = image,
let ciImage = CIImage(image: image),
let mono = CIFilter(name: "CIPhotoEffectMono",
withInputParameters: [kCIInputImageKey: ciImage])
else { return nil }
let ciContext = CIContext()
guard let monoImage = mono.outputImage,
let cgImage = ciContext.createCGImage(monoImage, from: monoImage.extent)
else { return nil }
return UIImage(cgImage: cgImage)
}
}
import UIKit
class ViewController: UIViewController {
@IBOutlet weak var imageView: UIImageView!
override func viewDidLoad() {
super.viewDidLoad()
let image = UIImage(named: "image-1.jpg")
let monoImageOperation = MonoImageOperation(inputImage: image!)
monoImageOperation.completionBlock = {
DispatchQueue.main.async {
self.imageView.image = monoImageOperation.outputImage
}
}
let operationQueue = OperationQueue()
operationQueue.addOperation(monoImageOperation)
}
}
import Foundation
class AsyncOperation: Operation {
public enum State: String {
case ready, executing, finished
fileprivate var keyPath: String {
return "is" + rawValue.capitalized
}
}
public var state = State.ready {
willSet {
willChangeValue(forKey: state.keyPath)
willChangeValue(forKey: newValue.keyPath)
}
didSet {
didChangeValue(forKey: oldValue.keyPath)
didChangeValue(forKey: state.keyPath)
}
}
}
extension AsyncOperation {
override var isAsynchronous: Bool {
return true
}
override var isExecuting: Bool {
return state == .executing
}
override var isFinished: Bool {
return state == .finished
}
override func start() {
if isCancelled {
return
}
main()
state = .executing
}
}
import UIKit
class AsyncImageDownloadOperation: AsyncOperation {
var downloadedImage: UIImage?
override func main() {
let defaultSession = URLSession(configuration: .default)
guard let imgUrl = URL(string: "https://unsplash.com/photos/M9O6GRrEEDY/download?force=true") else { return }
let dataTask = defaultSession.dataTask(with: imgUrl) { (data, response, error) in
if let error = error {
print("Image download encountered an error: \(error.localizedDescription)")
} else if let data = data, let response = response as? HTTPURLResponse,
response.statusCode == 200 {
if self.isCancelled {
self.state = .finished
return
}
let image = UIImage(data: data)
self.downloadedImage = image
self.state = .finished
}
}
dataTask.resume()
}
}
Sia uses encryption and erasure coding to ensure that files are private and remain available even if hosts go offline. The uploading process is as follows. First, the file is striped into chunks of 40MiB. Reed-Solomon erasure coding is then applied on each chunk, expanding them into 30 pieces of 4MiB. Erasure coding is like an M-of-N multisig protocol, but for data: out of N total pieces, only M are needed to recover the full 40MiB chunk. This ensures a high level of redundancy, much greater than traditional replication. Each piece is then encrypted with the Twofish algorithm. It was one of the five finalists of the Advanced Encryption Standard contest, but it was not selected for standardization. Nonetheless, this algorithm is considered very secure. Finally the pieces are sent to hosts to be stored. Currently, no host receives more than one piece of any given chunk. For example, host 1 might contain the first piece of chunk 1, chunk 2, chunk 3, etc., and host 2 might contain the second piece of the same chunks. This ensures that if host 1 is offline, you can still download pieces from every chunk. Even if host 1 is not offline, but merely slow, this scheme prevents you from being bottlenecked by the slow host.
1. Brass Golem is where we are at the moment with our proof-of-concept, in alpha testing now. This current version of Golem is only focused on rendering in Blender and LuxRender, and although it will be useful to CGI artists, we consider CGI rendering to be a proof of concept primarily, and also a training ground. Brass Golem should be frozen within 6 months after end of crowdfunding period and a full battery of tests. Even though we do not expect that Blender CGI rendering will create enough turnover to justify all the work we have put into the project, this will be the first decentralised compute market. 2. Clay Golem is a big leap from the Brass milestone. Clay milestone introduces the Task API and the Application Registry, which together are going to make Golem a multi-purpose, generalised distributed computation solution. Developers now have the means to integrate with Golem. This advance, however, may come at the cost of compromised stability and security, so this version should be considered an experiment for early adopters and tech enthusiasts. Prototype your new ideas and solutions on Clay. 3. Stone Golem will add more security and stability, but also enhance the functionalities implemented in Clay. An advanced version of the Task API will be introduced. The Application Registry will be complemented by the Certification Mechanism that will create a community-driven trust network for applications. Also, the Transaction Framework will create an environment that will allow Golem to be used in a SaaS model. 4. Iron is a deeply tested Golem that gives more freedom to developers, allowing them to create applications that use an Internet connection or applications that run outside the sandbox. Of course, the decision to accept higher-risk applications will still belong to the providers renting their compute power. Iron Golem should be robust, highly resistant to attacks, stable and scalable. Iron will also introduce various tools for developers that will make application creation far easier. Finally, the Golem Standard Library will be implemented.
- simple correctness: checking of the result, eg. proof-of-work, - redundant computation: ie. a few providers compute same part of the task and their results are compared, - computing small, random part of the task and comparing this part with the result sent by the provider, ie. comparing the colour of few random pixels in rendered picture, - analysis of output logs.
import CoreBluetooth
class MiService: NSObject, CBCentralManagerDelegate, CBPeripheralDelegate {
lazy var manager = CBCentralManager(delegate: self, queue: DispatchQueue.main, options: nil)
}
Note: MiService class will serve as a container for all Bluetooth-related logic and all methods and properties listed in snippets below should be added to it.
CBCentralManager is designed to communicate through delegate methods listed in the CBCentralManagerDelegate protocol. It has one non-optional method — centralManagerDidUpdateState(_:) — and that’s where we need to start. It’s called whenever the Bluetooth module in an iOS device changes its state — e.g. when you turn on or off Bluetooth in the Settings app. Additionally, it’s called just after the manager has been initialized. The state value that we want — in order to proceed — is .powerOn (so make sure to have your Bluetooth activated). When a manager is in that state, it can discover peripherals and connect to them.
func centralManagerDidUpdateState(_ central: CBCentralManager) {
if central.state == .poweredOn {
manager.scanForPeripherals(withServices: nil, options: nil)
}
}
var discoveredPeripherals: [CBPeripheral] = []
func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {
print(peripheral)
discoveredPeripherals.append(peripheral)
}
var miBand: CBPeripheral?
func connectToPeripheral(at index: Int) {
manager.connect(discoveredPeripherals[index], options: nil)
}
func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) {
manager.stopScan()
miBand = peripheral
peripheral.delegate = self
peripheral.discoverServices(nil)
}
func centralManager(_ central: CBCentralManager, didFailToConnect peripheral: CBPeripheral, error: Error?) {
print(error)
}
The result of the connect operation is returned through one of the two methods from CBCentralManagerDelegate protocol: centralManager(_: didConnect:), in case of success, or centralManager(_: didFailToConnect: error:), in case of failure. Assuming everything went well, we can stop scanning for nearby devices and save the connected peripheral in a variable for convenience.
Next, we should make our MiService implement CBPeripheralDelegate protocol, so it can become a delegate of the chosen peripheral and receive notifications about its state changes.
func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
print(error ?? peripheral.services)
peripheral.services?.forEach { service in
peripheral.discoverCharacteristics(nil, for: service)
}
}
Once we have a list of available services we can discover their characteristics. Discovered characteristics are available under services’ characteristics property, after receiving a call to peripheral(_: didDiscoverCharacteristicsFor: error:) method.
func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
print(error ?? service.characteristics)
service.characteristics?.forEach { characteristic in
if characteristic.properties.contains(.read) {
peripheral.readValue(for: characteristic)
}
if characteristic.properties.contains(.notify) {
peripheral.setNotifyValue(true, for: characteristic)
}
}
}
There is, however, one last setup step we need to perform. Reading a characteristic’s value is an asynchronous operation, so to receive the actual value we need to implement peripheral(_: didUpdateValueFor: error:) method from CBPeripheralDelegate protocol.
func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) {
let valueBytes: [UInt8] = value?.map { $0 }
print("New value for: \(characteristic)")
}
When you run your application and connect to your band, you should see these kinds of logs:
New value for: <CBCharacteristic: 0x1c40bf620, UUID = 00000007-0000-3512-2118-0009AF100700, properties = 0x12, value = <0c0b0000 00070000 00010000 00>, notifying = YES>The bolded part is the new value of a given characteristic. This particular log entry describes the characteristic, which holds information about the number of steps and meters covered and kilocalories burned today. However, when analyzing these bytes, it’s important to keep in mind that the majority of today’s digital devices use little-endian byte ordering, which means that the least significant bytes of a number are on its left side. Each of the aforementioned values is stored on 4 bytes: steps count on bytes 1–4, meters on bytes 5–8, and kilocalories on bytes 9–12. So e.g. to read a number of steps we take bytes 0b, 00, 00, 00 as UInt8s.
<0c 0b000000 07000000 01000000>Then we cast each to UInt32, shift numbers left bitwise by subsequent multiples of 8, starting from 0 and finally sum everything. I’ve created a simple extension, which does just that:
extension UInt32 {
static func from(bytes: [UInt8]) -> UInt32? {
guard bytes.count <= 4 else { return nil }
return bytes
.enumerated()
.map { UInt32($0.element) << UInt32($0.offset * 8) }
.reduce(0, +)
}
}
So if you want to extract steps count inperipheral(_: didUpdateValueFor: error:) method you can do it like this:
let stepsCount = UInt32.from(bytes: Array(valueBytes[1...4]))
func measureHeartRate() {
guard let miBand = miBand,
let hrControlPoint = miBand.services?.first(where: { $0.uuid.uuidString == "180D" })?
.characteristics?.first(where: { $0.uuid.uuidString == "2A39" }) else { return }
miBand.writeValue(Data(bytes: [0x15, 0x2, 0x1]), for: hrControlPoint, type: .withResponse)
}
After that, your band should start blinking with a green light on its backside, which means, it’s actually measuring your heart rate. The measurement usually takes a few seconds and after that, you should receive its value in Heart Rate Measurement characteristic update notification (assuming that, you have registered for its notifications).
We’ve all been there. You just found some new cool game that is going to make your way home less unbearable. You run it and…
Cool Game Would Like to Use Your Location popup says.
“Well, okay, but why?”
Cool Game needs your location right in the subtitle.
“Alright, that explains a lot. But fine — I’ll give it a shot” you think and hit Allow.
Cool Game Would Like to Access Your Photos.
“What? It’s a game! Why would you want that?!”.
That’s about the point when you get annoyed enough to go back to Home Screen and delete the app. Lots of people do.
The first interaction with the app is extremely important. Display multiple pop-ups asking for different permissions to user's sensitive data without proper explanation and you might find your user among the 23% of people who deleted the app just after first use. To prevent that from happening I listed some simple guidelines which you should always follow.
Bombarding the user with multiple popups is never a good idea. Especially immediately after the first launch. That makes the app seem intrusive. Users want to feel their privacy is respected and one way of doing so is creating a reliable and honest onboarding process.
Clearly educating why the app needs certain permissions builds trust. Users should understand that if they want to use a certain feature they need to provide certain data.
Another way is asking for permission in a context. It’s in most cases more effective because of onboarding caries one significant risk. Users need to make a decision up-front and even with proper education, they might not be sure if they want to use the feature requiring permission.
On the other hand, asking for granting the app gallery access during the process of sharing a photo eliminates that risk because the user already made the decision. They want to send the picture and in order to do so, they know they must press Allow. Plain and simple.
But what if the user doesn’t agree? Well, they must face the consequences ;) No, really. If the user denied permission that is critical to the app, there should be a clear explanation of why permission is necessary. You can always provide a button transferring to settings where users can re-allow it, but it might be risky on iOS as there are no official guidelines and the app can be rejected by Apple during the process of publishing the app to the AppStore. Also don’t try to overcome the denied permission — it was a user’s conscious decision and he has to live with that. It is still a good option to remind users that they can always change their mind although the iOS app can ask for certain permission only once and digging through settings is very poor UX. It’s a long, unintuitive process and there is no way to guide the user through it.
Permissions might be tricky but when handled with caution they might build reliance and trust. Just remember — ask nicely and you shall receive!
With the recent surge in Bitcoin’s price, the public is getting more and more divided as to its future. Is it a bubble that’s going to pop at some point or is it going to get widely adopted? Will it leave millions of people with broken dreams and terrible financial losses or is it going to replace traditional currencies?
Even the most renowned and experienced players in the financial markets are getting confused and changing their opinion on this issue. While this debate is getting the most attention in the crypto-world, there are more things happening that aren’t getting as much spotlight. For example, more than 1000 teams are now working on their own blockchain-based cryptocurrencies. They are all aimed at revolutionizing how we do financial transactions, data storage, healthcare, computations, communication, and much more. Today we are going to take a closer look at two of them to see how they can improve our lives.
One of the main drawbacks of Bitcoin is its lack of anonymity. If you have a computer that’s powerful enough, you can trace back every transaction ever recorded, and e.g. calculate how much money every wallet holds. NAV Coin is a cryptocurrency which prevents that by enabling private money transfers. It also aims at becoming a default method of transferring money with fast transaction times and low fees. A single operation takes 30 seconds and costs 0.01% NAV or 5 minutes for 0.5% NAV if you opt for a private transfer.
At its foundation, NAV Coin makes use of the 2048-bit version of the RSA algorithm capable of scaling up to 4096-bit with ease. It has been widely studied, tested, used, and not broken since its inception in 1977. This is the main factor that differentiates this currency from its main competitors like Monero and ZCash who opted for creating their own solutions (CryptoNote and zk-Snark respectively) which are fairly new and not tested nearly as much.
To make transactions truly anonymous, NAV Coin became the first cryptocurrency to operate on a dual blockchain — the additional one breaks the connection between a sender and a receiver as stated in their white paper:
The main technique that we have employed is to use a second blockchain we call the Subchain.
Instead of sending NAV directly to the receiver, the wallet encrypts the receiver’s address and sends the transaction to one of the addresses provided by the randomly selected processing server. When this server receives this transaction, it creates a transaction of arbitrary size on the Subchain which it sends it a randomly selected outgoing server.
This Subchain transaction has the receiver’s address and the amount of NAV to send encrypted and attached to it. When the outgoing server receives the Subchain transaction, it decrypts the data, randomizes the transaction amounts and sends the NAV to their intended recipient from a preloaded pool of NAV that is waiting on the outgoing server.
After the outgoing server has sent out the randomized NAV to the intended recipient, the incoming server will join together any NAV which has been processed and on the next transaction cycle send it to the outgoing server to replenish the preloaded pool of NAV for future transactions.
The consequence of this is that we have broken the transactional link between sender and receiver on the Nav Coin blockchain by routing the transaction information through the Subchain. The NAV sent to the recipient are not in any way connected to the NAV that are received.
Moreover, the NAV Coin team wrote a detailed article about how anonymous transactions work under the hood.
The NAV Coin team is currently working on a number of improvements to their cryptocurrency, e.g. further simplifying and securing the wallet and the transactions, cold staking, or enabling people to build Anonymous Decentralized Apps on top of the existing dual blockchain system. However, the most game-changing feature might be the NavTech Polymorph. It’s a partnership with Changelly exchange that will allow people to use NAV Coin’s dual blockchain system to perform anonymous transfers using any cryptocurrency supported by the Changelly platform (at the moment there are over 80 of them). Users will be able to make private and anonymous transactions also using currencies that do not support privacy by themselves. Moreover, coins can be exchanged on the fly which means that you can anonymously send someone e.g. Bitcoins on their Litecoin wallet.
Most of the world’s wealth is stored electronically — financial records, real-estate records, medical records, etc. However, they are being kept in centralized databases so we have to trust somebody to store them, and also they can be hacked (and they have been multiple times this year alone). Factom is a collaborative platform to preserve, ensure, and validate digital assets that aim at resolving these problems. It places data in its own structures, which are shared and secured over a distributed hash table (much like torrent files).
It enables people and businesses to use a mathematically provable “notarization” service. It also has built-in layers of redundant security that other blockchains do not offer. The Factom Blockchain anchors itself into the Bitcoin blockchain (and others) to take advantage of the security of Bitcoin’s hash rate. The layering effect of security ensures the immutability of its blocks.
Factom is most easily understood as a protocol that provides unlimited books of blank paper. Users of the protocol can take a book, label it with the title of their choice, open the book, and write on a page. When that page is submitted to Factom it cannot be altered or deleted. Nobody can back-date a page. All the data written into the book is preserved in the order it was presented to the Factom protocol.
Factom guarantees security of the records by three different methods:
During an interview Factom’s CEO Paul Snow described three major use cases that are already being implemented thanks to partnerships with the Department of Homeland Security and the Gates Foundation:
1. We are working with the DHS [Department of Homeland Security] to provide audit trails for data collection on U.S. borders. Certainly, our technology will ensure sensors are secure against those that would tamper with them. Our technology will also provide audit trails that ensure other parties that the data collected is properly disclosed when required, the integrity has been maintained, and that data held back as irrelevant is provably irrelevant (not collected within some timeframe, or at some location).
2. We are working with the Gates Foundation to ensure medical records are maintained, and available to parties providing care in developing countries to individuals that may have been treated by many different organisations in the past. This application has to be available when needed, transportable to remote locations without Internet access, secure, private, and require little in hardware and human resources.
3. We are working on data management applications to ensure that mortgages can be processed faster, cheaper, and within the current regulatory framework. This involves auditing and tracking data collection from many different parties over time about information covering every aspect of a mortgage. Income verification, property history and maintenance, taxes paid/owed, payment histories, property surveys, zoning, etc., all produce many documents that must be reviewed in the course of issuing and maintaining a mortgage.
The third use case would have been particularly useful during the 2008 housing crisis when banks were buying each other and had to merge huge amounts of data which resulted in thousands of documents being lost. That alone cost banks billions but can be easily prevented in the future thanks to Factom. At the time of writing this article, there are over 140 mln records, 11 mln entries, and 110,000 anchors on the Bitcoin’s blockchain which shows that it’s already being used heavily.
Factom created two types of cryptocurrency. The first one, Entry Credits, is used to pay for the data stored on the blockchain (1kb = 1EC) and can be exchanged only for the second one — Factoids, as it is not publicly traded on any exchange. The Factoid, on the other hand, is more traditional (if you can say it about any cryptocurrency) — coins are being used to secure and maintain the blockchain. The exchange rate between the two coins varies to maintain the price of 1 EC at $0.0001.
The process of adding data to the system consists of 10 minute-long blocks. At the beginning of each minute, every server takes responsibility for a subsection of the existing chains. When a user submits their entry to the system, one of the servers adds it at the end of the appropriate chain (to speed up the process of searching for the requested entry, they are grouped in chains so that when you’re looking for a particular one, you have to only search through the entries that relate to the requested one in some way).
After that, all of the servers validate the new state and add the new entry to their copies of chains. At the end of the minute, all servers confirm that they hold the same data and reveal a deterministic secret number (Reverse Hash which is a successive pre-image of a long hash chain). The collection of Reverse Hashes are then combined to create a seed to reassign responsibility for chains among the servers for the next minute.
This process is then repeated 10 times. After the 10th minute ends, the system randomly selects the server that is going to write the anchor into the Bitcoin blockchain by performing a transaction that stores all the needed hashes.
As we can see from the two examples provided above, blockchain and cryptocurrency can resolve many real-world problems. These are only a few of the most interesting projects involving blockchain. It’s still a very fresh and quickly evolving technology, so it’s very likely that in the future we’re going to see many innovative applications that no one even thought of yet.
Continue reading about altcoins in the second part of this article
Pamela is currently a CTO at Woebot, a friendly chatbot project that teaches Cognitive Behavioral Therapy techniques to help people regulate their mood and energy levels. Previously she worked in both Google Mountain View & Google Australia, doing developer relations for the Maps API and Wave APIs. In 2010 she founded the GirlDevelopIt SF chapter, which is a non-profit organization teaching women how to code. They host a wide range of technical classes and workshops including beginner classes and more advanced topics.
Khalia Braswell is a user-experience engineer at Apple. She’s also created INTech Camp for Girls in North Carolina, which the main goal is to inspire girls to do innovative tech projects. To date, INTech has reached hundreds of minority girls through hosting dedicated camps. In 2016 she got to the 30 Under 30 list by the Charlotte Mecklenburg Black Chamber of Commerce, the 10 Black Female Leaders in Tech to Watch by Hackbright Academy, 6 Young Black Women Making a Difference in Tech by New Relic and The 10: These Black Women in Computer Science Are Changing the Face of Tech by The Root.
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.
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.
![Elon Musk about the future [infographic]](https://withintent.com/app/uploads/2020/04/1kxBrIdeeKTu7OLo9OSCX1g-768x768.jpg)
