Categories
Software Technology

Product Design in Agile Methodology

The standard design process divides the product preparation period into various phases, which (depending on what methodology was adopted) separate interface design and its implementation. The combination of both phases and the creation of the one team working in Agile methodology allows us to save time, speed up the implementation process and improve the quality of a product’s usability. This occurs when the collaborative team is competent in both design and implementation.

Not sharing either knowledge and/or experience during the completion of tasks in both these categories may result in the preparation of an interface whose implementation will cause unnecessary problems for programmers — this is the most likely and easy to avoid the problem. Similarly, the need to modify the accepted requirements of a project (due to the change in the scope or mode of application operation) increases the number of iterations and corrections at every stage of the process.


After identifying such issues in previous projects, the importance to include people with project competencies and experience in Agile methodology in the development team is obvious. Working on UX and UI applications in the scrum formula and its appropriate synchronization with the ongoing implementation at that time guarantees an immediate increase in the success of implementation and improved quality control in the visual layer.
 
Working on UX and UI applications

Scrum methodology in product design — how it looks in practice

The length of the product design sprint is usually adjusted to the length of the standard development sprint. Using the same tools to manage tasks, each planning session defines project goals, their priority and amount in a given sprint for a given number of people in the project team (usually there are one to three teams, depending on the complexity and development of the project, with competences in analysis, UX and UI design and independent work organization).
 
The most important assumption is to plan the work of the product design team at least 1 sprint in advance to that of the development team – to which the planning and backlog grooming is most often used. Thanks to this, everyone gains a wider perspective than just their current tasks, developers gain the possibility to take an active part in the process of usability and interface design, while designers get clear feedback in the context of the feasibility of the developed projects and their usability.
 
Depending on the complexity of the project, the demo takes place with the help of a clickable prototype or presentation of individual components or views in the presence of the whole team. Tasks that have not been accomplished pass to the next sprint. The main goal is always to provide developers with the materials to work well in advance, including usability testing and gathering feedback from users and customers.
 
Product design - Espeo Software

Client-centric design process

Synchronizing the adaptation of Agile methodology to the design process and collaborative work with the development team (but with appropriate methodologies), automatically changes the perception of the entire project. The common definition of a backlog, a lively discussion about functionality and people with different competencies focused on achieving the same goal – providing the best possible quality of implementation – is definitely a recipe for success. This unusual approach allows us to focus on details and individual components of the project at hand, and also ensures that throughout the implementation the main assumptions are remembered and a wider perspective maintained.
 
The use of Agile methodology in the Product Design process also has one additional advantage, which is the need for close cooperation and frequent testing of the prototype with target users. This is due to the fact that we mainly work on the creation of a UI system that will be easily adaptable for different functional scenarios, and that concentrates on understanding users to solve and satisfy their problems and needs. This approach that focuses on users guarantees that the system we develop will also be easily adaptable in other, alternative applications should there be a need to develop them (a good example here is LindaAI).
 
One of the interesting and most effective exercises that should be used in the analysis phase is User Story Mapping – this is regardless of whether we are working on a new product, where we focus on solving real problems of users, or we are working on a new instance of an existing project, where our goal is to make sure that our changes and introduced features have a positive impact on business indicators and user behavior.

This exercise allows us to define:

  • Who is the intended user/recipient of the product?
  • What needs to be done with the product that is being worked on?
  • What is the implementation of key scenarios?
Team work in mobile application desining - Espeo Software

The whole is done with the help of whiteboard, sticky notes and the joint work of the entire team. The actions performed by the user of our application are divided into the next steps of the project so that we get accurately mapped functional paths in the product, with selected MVP, the division into releases and the ability to easily transfer data from the analysis phase to the backlog. What is more, the effects of our work can also be used to determine the conversion hopper (by identifying the most important activities on the site), control before extending the scope during work (thanks to easy migration to the backlog) and guarantees clarity in the common understanding of the product throughout the team.

Cross-functional teams

It is worth noting that project competencies between the development and design teams are purposely reiterated throughout the duration of the project. In the phase of analysis and research, the technical insight of developers is undoubtedly a great value, which at the start limits the number of potential problems. Most often, immediately after the analysis phase, the level of project work increases, so that the development team has already started with a specific number of ready and tested design solutions and that thanks to the aforementioned synchronization throughout the implementation, the designers can deliver further modules and components for implementation. The intensity of design work usually decreases at the final stage of implementation, where designers can take care of quality control. The whole cycle is repeated for each subsequent release of the product.
 
We must always be ready to change priorities. The ability to analyze the visual layer and support in improving usability often requires additions to the standard scope of work in a given sprint of time, which will be used to help the development team solve current problems during implementation. Designers and analysts very often have the widest view of the project, so their competences can naturally expand – but we should always be focused on the goals defined within the sprint.

In Espeo we use the following set of tools:

Slack as a basic communication channel inside the team (except for project meetings)

inVision as the main tool for building prototypes of interfaces and testing them with users

Zeplin as the main tool for the transfer of materials for the implementation of the development team

Summing up

The adaptation of the project team to Agile methodology and the creation of a collaborative work environment, where there is the smooth exchange of information, had a positive impact on the quality of implementation (not only in the visual layer).
 
Improving this process is the key to building a complete set of competencies in a team that is able to efficiently deliver well-prepared solutions, focused on meeting the goals set by business and solving problems faced by users.
 

See also:

Categories
Blockchain Software Technology

What is a DAO, or a decentralized organization?

A Distributed Autonomous Organization (DAO) is a combination of software and social connections. It’s able to act as a decentralized company for the benefits of its members – but no member has a controlling stake in it. My analysis of this phenomenon will be split into two parts. In the first part, we’ll focus on the benefits and risks of a decentralized organization.

What is a DAO?

In short, a decentralized organization relies on hard-coding certain important company rules, so that specific actions can be automatically carried out. A DAO relies on smart contracts to enforce those rules digitally.

Benefits of a DAO

  1. Shareholders/members of the DAO can have a very direct and immediate impact on key company operations.
  2. Cheap distribution of shares. What is a DAO benefit is that there’s no middleman. We have peer-to-peer communication between members who want to sell/buy DAO shares.
  3. Cheap distribution of dividends (directly from the decentralized organization to members).
  4. You can code many standard corporation activities in the algorithm. So, they can be executed automatically without any human intervention. Accounting, auditing, tax payment, payroll – you name it. It adds transparency to the operation, removes the risk of human error and lowers employment costs.
  5. You can also code integration with suppliers (exposed as other DAOs) in the algorithm. So, execution can work based on that interactive algorithm. If not disputed, cooperation between parties can be much smoother and cheaper.
  6. No single person (like a CEO) exists who represents the DAO. All members, even minor,  represent it collectively.

Risks of participating in a decentralized organization

  1. If you lose the cryptographic private key, or someone steals it, you also lose access to the DAO and voting rights in it.
  2. The programming code of the DAO can have bugs which might be impossible to correct. As we know, the smart contract code is immutable (read more about blockchain immutability). These bugs can result in anything, from money loss to unexpected liability incurment.
  3. Public blockchain networks (like Ethereum or Bitcoin) aren’t controlled by any single party. Their evolution can go into an unexpected direction, resulting in DAO disruption. In extreme cases, a DAO might become unusable.
  4. Most useful decentralized organizations need access to data outside of the blockchain. These data can be provided by automatic or semiautomatic centralized oracle mechanisms. To disrupt the operation of that DAO, it’s easiest to target the oracles it depends on.
  5. The algorithm can’t go beyond what it was programmed for. Hence, it can make biased or plainly bad decisions if you don’t account for every reasonable fact and circumstance. A DAO should be structured so that there’s always a human factor involved that can take back or stop automatic decisions.
  6. Parties (cooperating decentralized organizations) might not be explicitly defined in the smart contract. In case of a dispute not covered by the code (and without an automatic arbitrator) it might be difficult to resolve it in traditional legal system.

What is a DAO capable of? Stay tuned for the second part. In the coming weeks I’ll take a look at DAOs from a legal perspective. And if you’re considering blockchain for your company, but you’re still stuck on terms and crypto jargon – it may be time for blockchain training.

Categories
Blockchain Financial Services Technology

Blockchain immutability: Behind smart contracts

The Ethereum smart contract has taken the world by storm, with its wide adoption for ICOs. Smart contracts are, in essence, computer programs executed in a sandboxed environment, so one that restricts them. That restriction provides special functions and properties: the famous blockchain immutability is one of them. Let’s dive into those.

Blockchain immutability

As I wrote, one of the defining properties of smart contracts like the Ethereum smart contract is that their code is immutable . Blockchain immutability means that parties agree to the terms or “code” of the contract, that code can’t be changed by any party unilaterally.

The result of the execution of the smart contract is similarly unchangeable. Of course, that happens once the agreed-on code is executed and produces a result. The result should be objectively verified by the other party to that contract, or even by an external party. For example, this could be a regulator or observer. Only then you can be 100% certain it’s valid.

Free from external factors

The immutability of the results of the executed smart contracts stems from what I’ve mentioned at the beginning. What’s important is the context in which the smart contract is executed: sandboxes . That means the contract is free from the influence of any external factors. An environment like that guarantees the determinism of computational results.

T he only factors that influence the result are the input data to the smart contract, and the data stored within the smart contract environment . By the latter, I’m referring to the data that was stored there when smart contract was instantiated for the first time. Or, by the previous execution iterations of the same contract. In some smart contract environments (like Ethereum) smart contracts can also communicate with each other and influence the execution of one another. However, this is still done in controlled and deterministic way.

The Ethereum smart contract’s not the only one. Other implementations

Various implementations of smart contracts seek to leverage their benefits. Bitcoin’s smart contract language (script) is intentionally limited in complexity. The logic that can be expressed in it is very restricted. On the other hand, we have the Ethereum smart contract. The set of the operations that can be executed within the Ethereum Virtual Machine is much broader. Almost any reasonable algorithm or logic could be expressed in it, though there are still limitations on the number of operations per invocation.

Going even further, Hyperledger Fabric has no restriction on the complexity of the smart contract logic or the number of operations. That means it’s very powerful. However, it it also greatly increases the risk of node consensus divergence if that power isn’t used properly. Generally speaking, the level of expressiveness is a feature of a particular implementation. It can vary, providing different levels of security and strength for particular use cases.
It’s worth knowing the consensus doesn’t have to be immediate. Depending on the implementation, it might take around 1 hour (Bitcoin) to reach the semi-final consensus, or be almost immediate (Hyperledger Fabric). That’s despite the fact that once the consensus is reached, the smart contract execution result is provable and immutable.

Controlled access

Some smart contracts need to have access to structured data from the outside of their environment . In most implementations, controlled access to that data can be provided by privileged actors. They’re able to fetch the data needed at the specified time. Then, they can provably transform the data to a format that can be processed by the smart contract. Actors like that are called Oracles. They’re an inherent part of the productive smart contract ecosystem. They don’t change the other properties of the smart contracts. Oracles also work in the same sandboxed environment as the other smart contracts. Once the data is provided, it can’t be modified and is ‘provable’ forever.

Can smart contracts function without a blockchain?

If we want to execute smart contracts with the listed properties, they need to have access to some form of history inalterability. At the least, we’d need a way to prove that the history was changed and the observed results can’t be trusted any longer.

Blockchain is one technique that gives that particular feature but there’s research being done on other techniques. One of them is DAG (directed acyclic graph) where the smart contract transactions form a graph of relations (not being part of the chain of blocks). Yet another approach was undertaken by the Corda platform. There are no blocks in Corda, and transactions are exchanged directly between interested parties in the form of cryptographically signed sets of data.

Blockchain immutability brings many advantages to various industries, and is one of the features that inspire our clients to get on the blockchain. So, the Ethereum smart contract and the blockchain platform are what we deal with every day at Espeo Blockchain. That, and much more. If you’d like to leverage blockchain immutability in your project, we’re interested! Let us know in the box below.

Categories
Finance Software Technology

Mobile App Cost Estimation: What you need to know before you start talking with your development partner

Developing an app can be a big investment, and the development process itself is usually very complex. This is why it’s important to be well prepared when you commission an app, so that you are able to get the best results, both in terms of price and quality. In this article, we’re going to take a look at the preliminary considerations that have to be taken into account when estimating a mobile app cost.

Understanding what goes into the cost of developing an app

App pricing can vary based on several factors. When contacting an app development agency for the first time, it’s important to be aware of these factors and how they may affect the pricing. These factors are: the complexity of the app, the platform, and the location of the development resources.

The complexity of the app

When it comes to complexity, we can divide apps into four categories: simple apps, complex apps, enterprise apps, and gaming apps. Complexity is the first factor that gets considered during the estimation of a price.

To begin, you have simple apps, which have a small number of different screens, and which sometimes use APIs in order to work with data. These apps do not generally support user profiles, and they generate a very small amount of analytic data. The development process for one of these apps can take anywhere from 35 hours to 400 hours depending on the amount of features that go into the final app. This type of project can be handled either by a single developer or a small team, and the app should be ready within 3 months.

Then there are complex apps, which have up to 10 different screens, and which connect to one or more APIs to retrieve data. They also make use of location data and user profiles. They may also feature in-app purchases or, in the case of e-commerce apps, a shopping cart. On top of that, complex apps are generally able to collect a wide range of analytic data and they may feature a central administrative console that allows you to monitor and moderate content. Depending on the number of features, one of these apps can take anywhere from 70 to usually 500 hours to complete and they are developed by medium sized teams.

Enterprise apps come with over 10 screens, connections to multiple APIs, and, in some cases, custom APIs. They have a robust user management system, and they are very complex in scope. The purpose of an enterprise app is to streamline internal business processes, sometimes in multiple departments of a single company. For example, an enterprise app developed for a logistics company may cover invoicing, HR, sales, warehousing, vehicle tracking, and various aspects of management. Development for an enterprise app can take anywhere from 140 hours. Here, you will need a large, experienced development team and, in some cases, more than one of those.

Finally, you have gaming apps, which are characterized by the use of 3D acceleration, multiple APIs, the gathering of user data and other metrics, in-app purchases, and the use of user profiles. Gaming apps can take anywhere from 350 hours upwards to develop. Gaming apps will require a varied team of experienced designers, media creators, and developers.

cost estimation for a mobile app

The platform

The platform the app is being developed for must also be considered. However, if you are building a native application for a single platform, the cost does not vary noticeably between different platforms. In the past, you had something called the “Android tax”, which referred to the extra cost of developing for Android platforms, but this is no longer the case.

The cost difference becomes clear when you are planning to launch on multiple platforms. Here you have a choice between developing several native applications or developing a single hybrid application. The latter option is less expensive, but it is not able to offer the full experience of a native app. This can be detrimental if you have a particular set of functionalities in mind. However, if your app is not aiming for specific native features, there’s no reason to develop multiple native apps for each platform.

The location of the development resources

It’s no secret that offshoring can help you cut costsas much as 50% in some cases. However, it does come with its own problems. There may be cultural barriers, time differences, and a variety of other factors to take into account. That said, there are numerous offshore companies that have an established reputation for delivering high quality products, so if you shop around, you will be able to find the perfect balance.

request-for-proposal

Documentation

In order to get an accurate estimate and get the development team on board, you have to provide them with as much information and documentation as possible. Here are some of the documents that you should present to your development team, before requesting a quote.

RFP

A request-for-proposal will help you evaluate the responses from various developers more easily. To start, the RFP should define the project and its scope. This can include an executive summary of the project, a definition of the components and architecture of the app, and a series of questions you have for each vendor.
The executive summary should give a very brief explanation as to the focus of the app, and clearly define the various components and methods that will go into the app. Any technical detail will help the developer better understand your project. Finally, you want to have a list of questions for your developer, regarding issues such as previous projects and their ROI, the model of delivery, the quality testing tools and methodology, and other relevant factors regarding core capabilities such as development, design and quality control.

You can find a list of free RFP templates here, and there are many more to be found on the web.

Business plan

Your business plan contains a lot of information that can help the development team. While the RFP offers a detailed look at the specific product you are looking to purchase, the business plan offers a general view of your company and its vision. A business plan will help the developer see how the app fits in the bigger picture.

A business plan is usually comprised of an executive summary, a description of the company, a description of the target market, the marketing strategy, and the financial plan. The executive summary will help the developer understand the problem that your company is trying to solve, the solutions it is deploying, your unique value proposition, and your objectives. Your business plan will also likely cover your competitors, your customer acquisition strategy, and your monetization strategy, all of which are important factors that affect the final scope of your app.

Pitch Deck

A pitch deck is usually a PowerPoint presentation that is meant to provide a brief introduction to your business plan. It is best used in online or face-to-face meetings with potential investors, customers or partners. The pitch deck is meant to open the conversation and to give the prospective developer a quick understanding of what your company is about.

It should contain all the key information outlined in your business plan, but without being excessively long, including a description of your team, the problem you are addressing with your app/services, the solution you offer, the target market, the competition and your general business model.


Business model canvas.

The business model canvas is an alternative to the business plan. It was developed by Alexander Osterwalder, and it is meant to be a more agile and modern version, suitable for today’s highly dynamic business environment, especially within the tech field. It is less costly, less time consuming and much shorter than a business plan, and it covers 9 important business areas: key partners, key activities, key resources, cost structure, value proposition, customer relationships, channels, revenue streams, and customer segments.

Odds are that you either have a business plan, or you work with a business model canvas. When presenting a business model canvas to your development agency, you are helping them gain a clear understanding of how various components of your business connect and impact each other, and how you intend to maneuver your business in the market. The BMC also has your value proposition at its core, making it a key consideration in the development process.

Mobile App Cost: Key Takeaways

The cost estimation process relies on two factors: your understanding of the various cost structures and the developer’s understanding of your business, and your goals and the means of achieving them. However, the best way to get a good price and a great final product is to have as clear an image as possible of the app you want to develop and how you want to develop it.

Check out some of our best app design ideas: simple, plain and effective

If you understand the APIs, development methodology, programming languages, and project management methods that will be used in your project, you are able to better estimate pricing and timelines.

Conversely, if the developer understands your business and preferences correctly, they will be able to give the most accurate quote and deliver a quality final product that helps you meet your objectives. Avoid upfront quotes, and make sure that you include a list of the features you’d like for your app, the services you need, the platform you want to develop for, and the ideal timeline for your business.

See also: