Crafting Software User Experiences That Matter

Creating a visually appealing and user-friendly interface is no longer just a bonus – it's a necessity. User Interface (UI) design plays a pivotal role in determining the success of any software or application. UI design is the first point of contact between a user and an application. A well-crafted UI not only captivates the user's attention but also enhances the overall user experience. Over the past 20 years that we have been in the business of making software products for companies all around the world if there is one common theme that we’ve found that is: UI matters. If the market needs a certain software then the only deciding factor for the success of a software to fill that need is the quality of it’s UI - it’s as simple as that.

We recently asked our design team and their friends in the industry to come up with suggestions and thoughts about UI/UX and here’s a summary of those:

First Impressions Matter

Just like meeting someone for the first time, users form quick impressions about software based on its interface. A visually appealing and intuitive UI creates a positive first impression, setting the stage for a satisfying user experience. This came from a sales lead of one of our clients. And from her experience, the first few minutes when she demos the software she has always found the right UI/UX to make or break a sale. “It’s not so much that the software needs to be beautiful to look at”, she added, “although that’s important, what becomes important after a few clicks is how intuitive it feels and if my prospect can relate with the flow of work that the software is showing”. There’s even some research proof around this, in a study, Forrester found a significant correlation between improved sales and UI/UX improvements, over hundreds of software projects in their study.

User Engagement and Retention

“But at a basic level, the goal is to get new customers familiar with whatever the product’s core functionality is—the feature that they came for—so they can quickly reach their ‘aha’ moment. Then, based on their usage, introduce them to another feature, and then another, and so forth.”

— Ryan Matthew, neuronux.com

A well-designed interface keeps users engaged and encourages them to explore the software further. It directly influences user retention, as users are more likely to stick around and use an application regularly if the interface is user-friendly and enjoyable.

User engagement and retention was a common topic from designers and founders we talked to. Someone referred to a recent article about how UX and user retention is directly linked. It talked about how even the reputedly boring B2B software can sell itself with the proper UI/UX.

Enhanced Usability

An intuitive UI simplifies the user's interaction with the software. By following design principles that prioritize user needs, designers can ensure that users can easily navigate through the application, accomplishing tasks efficiently and without frustration. Enhanced usability was what everyone pointed out. It’s obviously the most important outcome of any great UI/UX.

Basic rules of UI design

Our design team came up with some basic rules of UI design that they feel every software should be mindful of. Here’s the list:

Put the User First

Empathy is the cornerstone of effective UI design. Understand your users, consider their diverse experiences, ages, and abilities. Familiar designs and practices contribute to a seamless user experience, ensuring that your software is accessible to a broad audience.

Constant Feedback

Implementing feedback mechanisms within the interface is essential. Users should receive validation for every action, helping them correct mistakes or stay focused on their next steps. Respectful error notifications contribute to a positive user experience.

Respect Users' Time

Time is precious, and users appreciate interfaces that respect this. Onboarding processes should be concise, especially for experienced users. Minimize data entry and avoid redundant prompts, ensuring users can swiftly accomplish their goals without unnecessary delays.

Airbnb interface is a great example of respecting user’s time. Here’s a screenshot of the interface after a search for places in Paris. In one single screen they’ve managed to put in pretty much everything the user will need to do the sort and filter the place they are looking for: price, looks, locations relative to each other, reviews.

Consistency is Key

Achieving a balance between innovation and familiarity is challenging but rewarding. Consistency in design elements such as prompts, buttons, colors, and fonts creates a cohesive and user-friendly environment. Users should feel a seamless transition across different sections of the software.

Don't Overload the User

Simplicity is a guiding principle in UI design. Avoid overwhelming users with excessive information on a single screen. Provide clear indications of navigation paths, enabling users to explore deeper into the application without confusion.

User interface design is more than aesthetics – it's about creating meaningful and efficient interactions. By adhering to principles such as putting the user first, offering constant feedback, respecting users' time, maintaining consistency, and avoiding information overload, designers can shape interfaces that not only meet user expectations but exceed them. In essence, user interface design is the bridge between users and the functionality of software, and by building a strong bridge, we create experiences that users will not only appreciate but will keep coming back for.

We’ll end this with a little comic we did a long time back in Bengali. Here it is, and the words in Bengali mean: “Someone’s bad software is another person’s full-time job.” The look on the guy’s face tells you how frustrated he is with his software, but he has no way but to slog on with it as it’s the only tool he has to get his job done. This is probably the most important part of good UI/UX: a good design is helping our fellow humans be happy. You can’t have a better rationale than that to improve your software interfaces!

Why should you use an agency to build your software?

In today's fast-paced and highly competitive business environment, companies need to continuously improve their operations and processes to stay ahead. One way to do this is by leveraging technology and software to automate and streamline various functions. However, not all businesses have the in-house expertise or resources to develop and maintain software solutions on their own. This is where software development agencies come in - they offer a range of services to help businesses create, implement and maintain software solutions that meet their specific needs. In this blog, we will discuss the benefits of using a software development agency.

Cost-effective

One of the biggest advantages of using a software development agency is cost savings. Hiring and training an in-house team of software developers can be costly, time-consuming, and risky. By outsourcing software development to an agency, businesses can save on salaries, benefits, training, and infrastructure costs. Surveys show the cost-effectiveness of using an agency in low cost software destinations such as Bangladesh but even if you are not going offshore using an agency close to you will bring down your costs by reducing your HR commitments along with the cost of operation.

Expertise and Experience

Software development agencies have a team of experts who have extensive experience in developing software solutions for different industries and use cases. They have worked on various projects and have the necessary skills, knowledge, and tools to create effective solutions quickly and efficiently. They also keep up-to-date with the latest trends and technologies in the industry, so businesses can benefit from the latest innovations and advancements. By hiring an agency in essence you are getting access to their entire skillset and expertise on a need basis, a great example is how we help our software customers with a design team when they need to create visualization of their ideas - the design team comes in for a short time to turn the ideas into mockups and specifications that the software team can use as their guide. The cost to the clients is minimal, yet the benefit is a dedicated design and product team that only giant companies can afford.

Faster Time to Market

Software development agencies have streamlined processes and workflows that enable them to develop and deploy software solutions faster than an in-house team. They have experience working on different projects and can quickly adapt to changing requirements and timelines. This means businesses can launch their products or services faster and gain a competitive advantage.

Scalability

A software development agency can scale its resources and expertise based on a business's needs. This means that as a business grows, the agency can provide additional resources and support to meet the increasing demands for software development services. Similarly, if a business needs to downsize or reduce its software development needs, the agency can adjust its resources accordingly.

Focus on Core Competencies

By outsourcing software development to an agency, businesses can focus on their core competencies and strategic initiatives. This means that they can allocate their resources and attention to activities that are critical to their success, such as product development, marketing, sales, and customer service. Software development becomes a supporting function rather than a core competency.

Using a software development agency has many benefits for businesses looking to develop custom software solutions. It can help businesses save on costs, access expertise and experience, launch products faster, scale resources as needed, and focus on core competencies. Businesses should carefully evaluate their software development needs and choose an agency that can meet their requirements, deliver high-quality solutions, and provide ongoing support and maintenance. By doing so, they can reap the benefits of technology and stay ahead of the competition.

Outsource with confidence: 7 Essential Practices for Software Development Success

In the fast-paced realm of technology, the decision to outsource software development can be a game-changer for your business. Whether you're brimming with a brilliant app idea or seeking to revamp your existing one, outsourcing can provide the expertise and bandwidth you need without the hassle of managing an in-house development team. Bangladesh, where we are based is a major hub for outsourced software development projects, and there are really good reasons to outsource here. So over the past 20 years of working with companies from all over the world, we’ve picked up some good tips and tricks about how best to run an outsourced software project. Before embarking on the quest for the perfect development partner, it's crucial to familiarize yourself with the best practices that can shape a successful outsourcing journey. Here are seven key principles to guide you through the process:

1. Define Your Reasons for Outsourcing

Before diving into the outsourcing pool, introspect on the reasons driving your decision. Ask yourself, "Do I really need to outsource?" Clearly identify the factors pushing you towards this choice and create a reference list. This introspection will serve as a compass, steering you through the outsourcing process, and aiding decision-making. Ensure that your project is suitable for outsourcing, particularly when specialized expertise, additional support, or time constraints are significant factors. A great read along these lines is this post about finding the right balance for outsourcing parts of your software projects.

2. Choose the Right Partner

Selecting a reliable outsourcing partner is paramount to the success of your project. Look for a company with a stellar reputation and a proven track record of delivering results. While peer recommendations and reviews are invaluable, delve deeper into compatibility. Assess whether the partner's work culture aligns with yours, and if their working hours and communication methods suit your preferences.

3. Look Beyond Cost

While cost efficiency is a driving force behind outsourcing decisions, it should never be the sole consideration. Prioritize the quality of the end product during the selection process. Ensuring that you receive a high-quality solution is essential, even if it means investing a bit more upfront.

4. Thoroughly Scope Your Project

A detailed project scope is the cornerstone of successful outsourcing. Use this as a trial project if you're in doubt about a potential partner. Provide a comprehensive project scope to align everyone's expectations and establish a procedure for handling additional work outside the initial scope. Prevent project delays caused by incessant feature additions and requests.

5. Establish Robust Communication Channels

Effective communication is the backbone of any successful outsourcing venture. Implement strong communication channels to facilitate seamless interaction with the development team. While multiple channels like Slack, email, messengers, Skype, telephone, screensharing tools, and issue trackers may be available, designate a primary channel for efficiency and clarity.

6. Stay Actively Involved

Outsourcing doesn't imply a hands-off approach. Stay engaged with the development process by checking in on progress regularly. Understand the team's requirements for resources and provide necessary input to keep the project on track. Take ownership of the process for optimal results.

7. Embrace Task Management Tools

Regardless of your project's scale or complexity, task management is non-negotiable. Implement a project management or task management system to monitor development progress. This helps you track tasks, understand the pace of development, and identify potential roadblocks in collaboration with your outsourcing partner.

Outsourcing software development can be a strategic move for meeting your company's needs, but success is not guaranteed without a thoughtful approach. This list serves as a foundational guide, emphasizing the importance of selecting the right partner and establishing processes that enhance the likelihood of successful outsourcing. Explore our additional tips and tricks for selecting software vendors to further refine your outsourcing strategy.

Software: it's not for you, it's for your customer

The Crucial Art of Understanding Your Customer

In the dynamic landscape of software product development, there's a cardinal rule that often separates the triumphs from the tribulations: understanding your customer. The adage, "Your software is not for you, but for your customers," echoes through the corridors of startup wisdom, serving as a guiding principle for those seeking to navigate the complexities of bringing a digital creation to life.

The Costly Mistake of Losing Sight

Whether you're steering the ship as a startup founder or collaborating within a seasoned product team, losing sight of the end user's needs can prove fatal. It's akin to embarking on a journey without a map; the chances of reaching your destination diminish with each step taken in the dark.

Market Research: Illuminating the Path

Diving headfirst into comprehensive market research is the first beacon of light in this journey. It involves not just studying market trends but engaging directly with potential users. Understand their pain points, desires, and expectations. What keeps them up at night, and what would make their lives easier? These are the questions that form the basis of a foundation strong enough to withstand the tests of time.

Embracing Feedback: The True North

Feedback is the lifeblood of progress. Yet, many developers and founders shy away from it, fearing criticism or divergence from their original vision. This hesitancy is where the downfall begins. Embrace feedback, even the harshest critiques, as they are the keys to unlocking a product's true potential. Users, after all, are the most authentic judges of a product's usability and relevance.

Recognizing and Overcoming Biases

In the quest to create groundbreaking software, acknowledging and overcoming biases is paramount. As creators, we bring our own experiences, preferences, and assumptions to the table. However, these might not always align with the diverse needs of the target audience.

User-Centric Design: A Paradigm Shift

User-centric design is more than just a buzzword; it's a paradigm shift in approach. It involves stepping into the shoes of the end user, understanding their context, and designing a product that seamlessly integrates into their world. This shift challenges preconceived notions and ensures that the final product isn't a reflection of the creator's preferences but a solution tailored to the users' real-world challenges.

Personas: Bringing Users to Life

Creating user personas is a powerful technique to personify the abstract concept of your "customer." It goes beyond demographics, delving into the motivations, frustrations, and aspirations of fictional characters who represent your target audience. By crafting these personas, you build empathy and gain insights that can shape a product into something users don't just need but truly want.

The Process: Tried and Tested

As the saying goes, "To know thy customer is to know thyself." The journey of understanding your customer isn't a linear path but a mosaic of interconnected steps. Here are some key stepping stones:

1. Conduct User Interviews: Schedule one-on-one interviews with potential users. Listen actively, ask probing questions, and seek to understand the intricacies of their daily lives.

2. Utilize Surveys: Surveys are a scalable way to gather information. Craft well-thought-out surveys that touch on pain points, preferences, and user expectations.

3. Iterate Based on Feedback: Your product is not a static entity but an evolving one. Be prepared to iterate based on user feedback. Every critique is a valuable opportunity for improvement.

4. Test Prototypes: Before the full product launch, test prototypes with a select group of users. This provides real-world insights without the risks associated with a wide-scale release.

5. Leverage Analytics: Once your product is in the hands of users, leverage analytics tools to track user behavior. What features are popular? Where do users drop off? Use this data to refine and optimize.

A Warning Against Complacency

The ever-changing landscape of technology demands perpetual adaptability. Understanding your customer isn't a one-time task but an ongoing commitment. As markets evolve and user expectations shift, staying attuned to your customers ensures that your product remains relevant and impactful.

In the symphony of software product development, understanding your customer is the melodic refrain that resonates through every stage. It harmonizes market research, feedback, and user-centric design into a composition that strikes a chord with users. Embrace this cardinal rule, and your venture will not only survive but thrive in the dynamic and competitive realm of software innovation. After all, success in software development is not just about lines of code; it's about understanding the hearts and minds of those for whom the code is written.

Managing a multi-cultural remote software team

Remote work is the new normal, and managers need to be prepared to lead their teams in this new environment. And in today's globalized world, multicultural teams are the common remote teams. Cultural diversity is common in onsite teams too but the issues of miscommunications because of cultural issues are much more complex in remote teams. With the rise of remote work and the desire for flexibility among younger generations, managing a team from different cultural backgrounds has become one of the biggest challenge for managers. And this is an essential skill that all managers are picking up.

Since Kaz is a software development agency based out of Bangladesh and we work mostly with software companies based in the US or Europe. So the very nature of our work leads us to the remote cross cultural issues. And this not a new thing for us because of the recent rise of remote work. We’ve been participating in remote software teams for the past 18 years, and over that long time we’ve probably seen all the things that can go wrong in such cross culture, cross language teams and have devised strategies that solve those issue (or at least reduces to chances of them arising). We’ve also come up with a little poster for expressions in English that doesn’t translate well, that we sometimes give to our customers’ project managers as a cheat-sheet! So, today’s post is a summary of some of our best tips around this and that useful “cross culture expressions to avoid cheat-sheet”.

Understand that there is problem

This is important. Specially in the software world. We sometimes hear things like: “At the end it’s all code, and the language of code is the same so there will be no problem”. Although at the fundamental level that is very true, but to get to that stage of work and collaboration the remote teams still have go through layers of communications. That communications is typically in a language that isn’t a first language for at least one side and sometimes for both sides. And that’s where the start of the problem happens, and layer on top of that the cultural difference and the fact that cultural context changes the meaning of many expressions and mannerisms - you have a problem. So it’s vital for software managers to understand that there is a problem and it will need active strategies and process to solve that problem.

In this context, it is essential to recognize that cultural differences can lead to misunderstandings and conflicts. As the speaker in the video explains, even seemingly simple things like expressions about time can have very different meanings in different cultures. For example, in some cultures, "just now" might mean "in a few minutes," while in others, it might mean "sometime in the future." Without understanding these differences, miscommunications can easily arise, leading to frustration and conflict.

Create culture awareness in the team

To address this challenge of cultural difference and the need to work around such difference, it is important to invest in cultural awareness and sensitivity training for managers and employees. This might involve providing resources such as books or online courses on cross-cultural communication, as the speaker in the video did. It might also involve hosting workshops or training sessions led by experts in intercultural communication.

One key aspect of this training should be the importance of context in communication. As the speaker explains, even when two teams are using the same language, differences in context can lead to misunderstandings. For example, a phrase that might be intended as a compliment in one culture might be interpreted as criticism in another culture. Understanding these differences requires a deep appreciation for the cultural norms and values that shape communication styles in different parts of the world.

Create an environment of trust

Another important aspect of managing a multicultural team is building trust and rapport among team members. When people come from different cultures, they may have different expectations about how to build relationships and establish trust. For example, in some cultures, it may be important to spend time getting to know someone on a personal level before discussing business matters, while in others, business may be the focus from the outset. Understanding these differences can help managers to build stronger relationships with team members and foster a sense of camaraderie and trust.

We’ve written extensively about this in the past, as we feel that this is one that that makes thing much simpler to solve cross cultural issues. Some of our tips can be found in this article about how to build trust in your remote team by team gelling or this one about creating the right team culture for companies with remote teams.

Find what works the best for you

It is important to recognize that managing a multicultural team is not a one-size-fits-all endeavor. Different cultures have different expectations around communication, hierarchy, and decision-making, among other things. Effective managers must be able to adapt to these differences and find ways to accommodate the needs and preferences of each team member. This might involve using different communication tools for different team members, or adjusting work schedules to accommodate different time zones.

Careful about what expressions you use

It's important to be aware that expressions that you might use in your language or cultural context might not be understood at all or even worse understood with the opposite meaning by your remote team. It is vital for team managers (and team members) to consider cultural differences when communicating with people from other backgrounds. It's also a good idea to clarify the meaning of an expression if you think it may be misunderstood. Here’s our list of common English expressions that just doesn’t cross the language and culture basriers well. We call it the expressions to avoid cheat-sheet!

"Break a leg" - This one never works. In most non-English cultures, wishing someone luck by saying "break a leg" is considered bad luck or even offensive. Actually if you think about it really weird that this expression has the meaning it has, here’s the Wikipedia post giving it’s history.

"Bite the bullet" - This expression means to endure a painful or difficult situation, but in some cultures, the literal meaning of biting a bullet can be confusing or offensive.

"Spill the beans" - This expression means to reveal a secret, but in some cultures, the idea of spilling beans may not make sense or may be seen as wasteful. I remember once one of our customers used this expression in the context of asking his team not to reveal software features anyone and the look of confusion in the team was very interesting!

"Piece of cake" - This expression means that something is easy, but it almost always fails to translate well.

"Going Dutch" - This expression means to split the bill, but in some cultures, the idea of going Dutch may be unfamiliar or seen as impolite.

"Skeletons in the closet" - This expression means to have secrets or embarrassing information, but to someone not used to the expression the idea of keeping skeletons in a closet would not make sense at all!

"Costs an arm and a leg" - This expression means that something is very expensive, but in some cultures, the idea of comparing something to body parts may be seen as distasteful.

"Cat got your tongue?" - This expression means to ask someone why they are not speaking or responding, but this one never works either for obvious reasons.

"Let the cat out of the bag" - This expression means to reveal a secret, but the idea of a cat being in a bag may not make sense or may be seen as cruel for non English speakers.

Software development with Unity

Unity is now a leader in games and any application that requires 3D visualization. It’s a platform that’s stable, has huge developer community support, great tools, very helpful documentation and an ever increasing software developer group - thus a superb ecosystem. Today’s post is an overview of this platform that we love and have been working on for several years. We’ll share our own experience along with a more generalized survey of the ecosystem for anyone thinking of moving to this space.

Unity the game engine

Unity started in 2005 with a very specific goal:

"democratize" game development by making it accessible to more developers

From the beginning the the focus has been on making a tool usable by everyone - be it in ease of use or be it in cost. And this focus has enabled Unity to achieve the great level of adoption it has now. Over the years Unity ecosystem has developed in to one of the most extensive in any programming ecosystems. Here are some of the big highlights of that ecosystem.

Multi platform support

Unity’s greatest feature is single code base that can target multiple platforms. So a developer can build an app for desktops, mobile devices like iOS or Android, Consoles like PS4 or Xbox, AR/VR devices, etc. all with the same code base.

Easy to use and learn

This is Unity’s biggest thing - it’s just simple to use. Within a very short time any software developer can have the environment setup and ready to create really complex games. Unity leverages on existing programming languages (C# and JS) and developer’s favourite IDEs. Thus the learning curve becomes very flat very soon. This makes the decision for trying out Unity for a software development project very simple as a test environment can be setup quickly and developers can try things out fast

Documentation, tutorials and templates

A big highlight for working on on Unity it’s support for knowledge. Developing a game in Unity is a smooth learning experience with accessible online tutorials and learning materials that Unity itself provides. This is then augmented by literally hundreds of other free tutorials and training resources from third parties. Specially valuable are the numerous YouTube channels dedicated to Unity development. It really helps an a new developer starting out her journey in the game development.

Video tutorials are particularly rich. Unity itself has hundreds of such video tutorials that go over in details of building fully working games. Apart from these tutorials and standard documentation Unity supports and continuously grows it’s library of template projects. These are backed up by even more templates from the Asset store (see below).

Awesome forums and community

Online forums are extremely strong for unity. The large community of Unity developers almost guarantees that any problem a developer runs into is already answered or can be answered very fast. Most of the larger forums are monitored by the Unity staff to support and answer questions directly from the makers of the platform. This overall support mechanism helps build the positive feedback loop of the community. Making it so strong. Unity’s own support portal: Answers.unity.com is a great example of how company supported public forums should be. Other forums include the good old stackoverflow’s Unity area, forum.unity.com

Rich marketplace for assets

The world of Unity comes with a marketplace where you can buy (or in many cases download for free) great assets (graphics, game objects, code, even full games). The Unity Asset Store is loved by game developers because it rich collections of pre-designed graphics, game objects and many more. The overall impact of having such a marketplace at your fingertips is the rapid pace of development in your project. Whenever you stuck for something - be it a new character in your game or some funky code or game logic you’ll probably find something in the assetstore to help you. This just speeds up your development by a large margin.

Flexible Licensing Model

Most projects and companies can start using Unity for free and then pay as they grow. That is the philosophy for Unity’s licensing. Most game engines are expensive have the most rigid licensing rules. This is just not the case with Unity. The Unity game engine, despite being a top platform remains at an affordable price, as compared to others. The free version has enough features get most of the common software projects and games off the ground and an upgrade to Pro version at a an affordable price brings in a whole pack of advanced features.

Analytics built in

Unity comes with built-in analytics that a game developer can use to setup their analytics. The engine is comprehensive and covers pretty much all the basic needs of analytics for discovering insights about the game and it’s usage.

With such great features it is no wonder that Unity-made applications were used by 2 billion monthly active users, with 1.5 million monthly creators! Unity is there to take over the game development space and it’s a platform to reckon with. So if you are thinking of working on a game or a software that requires 3D visualization then give Unity a spin.

Sourcing your software talents from around the world

A brave new world has arrived. A world where the age old concepts of work, workplace, office, meetings and all things related to work has changed forever. And I’m not talking just about WFH. Sure, work from home (WFH) or as some people prefer to call it “remote work” has become accepted, in some cases become permanent, but I’m talking about a much bigger thing than the acceptance of working from home. I’m talking about a paradigm shift in our way of doing work. The past two years (almost!) has forced this shift in us - in most case without us fully knowing. The paradigm shift is the idea that - work can be decomposed, spread out to talents who can do them anywhere in the world and re-composed. Any work can be split up into little blocks, and those blocks can be done by anyone, anywhere in the world and then those blocks can be put together and made into a whole.

This new paradigm works wonderfully in software work. Software development was half way there anyway, with teams spread out, tools of work (like the source control, servers) in the cloud, etc. But the pandemic just pushed the model further - specially to the skeptics (read management!). The formula for the new world in software projects is:

Step 1: Find talents anywhere in the world

You don’t wait for the talents in your neighborhood anymore. All you need to do is decide what skills you need to get the job done and then find a source for the talent online. There are freelancers and consultants available on sites like Upwork or Toptal or if you are looking for a more professional team that can take care of the whole blocks of things for you (and if need be the whole project) then you find a reputable company on a site like Clutch or you can rely on software company like us (shameless plug, but not too bad an advice).

Software is the same everywhere in the world - that’s the beauty of standardized syntaxes and compilers. So why wait? Treat the entire world’s software skills as yours to pick from - exactly like shopping from Amazon instead of your corner store!

Step 2: Bring them under your project’s virtual roof for a set period of time

The set period of time is the beauty of this new world. No longer are you tied to huge burn rates and HR overheads. You slot in the right skills at the right time and slot them out when their job is needed. If you can get the right partners and the right tools in place then it’s like magic - suddenly you have access to hundreds (if not thousands) of resources whenever you need them. It’s like being Microsoft on a puny budget!

Step 3: Get your software made!

Of course! This part is the same as before, well mostly. You will probably need to do a bit of composition with the blocks - that is bring the outputs together for the final software. In all likelihood you’ll probably do it the old style way but this too can be done in the new way of doing things and just relying on the resource cloud that you have in your hands!

The brave new world is great. The world is your oyster now. Happy software development.

Psst… if you want a great software team to help you make your software give us a shout at info@kaz.com.bd or just use box below to send us a message :)

Top 10 Questions you must ask your software vendor

Do you have any questions for your software vendor? You should. The standard stuff like what is the size of the vendor’s team, what are their skills, how long have they been around are usually available easily at the vendor’s website, their brochure or they are more than will to just give you that information. What is more difficult to know yet vitally important for you are the answers to the not so easy questions.

Here’s our list of top 10 questions that must be asked before any software development relationship is set up with a new vendor. There are obviously a lot more, but we feel that these 10 must be asked no matter what and the answers to these should be discussed internally with your team to see if you see a good fit, to see if you agree or accept those answers or not.

1. What are the company's values and goals?

You might think this isn’t all that important for you as a customer, or it’s just some marketing blurb that you can by pass - but you’d be wrong. A software development project isn’t like many other projects around, it’s not like a simple product you buy and then you can pretty much live on your own. A software development project means a sustained relationship for a period of time (usually pretty long - remember it’s just not the development time, but all the maintenance, updates, upgrades and fixes of a software’s typical lifetime) . So what your vendor’s values are, how they see the business, what their goals are - all these matter because you’ll need to agree with them, be comfortable with them and at the very least accept them. For example if the vendor feels that their real goal is to become a giant in 5 years, then you need to think if that fits with your goal of working with a stable and small team.

A picture from 17 years ago at our old office where we had those beautiful mosaic patterns you don’t see anymore.

Sometimes alignment of values are a very good sign that things will work out in the longer term. I remember a long time back I was showing a prospective customer our old office space that had these beautiful, intricate mosaics and I mentioned that we love these patterns and we take extra care not to destroy them somehow. She just absolutely loved it and said her company was a 3rd generation owner company that valued traditions - and we knew we had a good alignment. And indeed over time that has proven to be so true, having worked with them for a long time and launching several of their flagship products.

2. What happens when you fail to deliver something?

This is the hard question that all software vendor will try their best to avoid. But you absolutely have to ask. Things do go wrong in software (actually all the time, some studies have shown that 78% of software projects fail, a recent post of ours tries to find a way software project plans can be done to avoid failure). So asking how the vendor will manage that risk is essential. If the answer to that sounds vague or if they say the impossible - “we don’t fail” then think hard if this is a good fit, dig in deeper to see how reliable that partner is. Every software project should have a disaster recovery plan - simple. If a vendor doesn’t have one or isn’t planning one then there is something wrong with that vendor.

What you should be looking for is a realistic yet confident approach towards delivery failures. There should be a risk management plan - a risk containment and mitigation approach. They should be ready to act when a failure happens, and draw on the experience and knowledge from past projects and from the team to minimize the impact to the project.

3. What happens if a team member leaves suddenly?

Software is very much a team effort where every team member is essential. Over time a team member becomes an expert of the project and its requirements. Developers grow the essential familiarity with the codebase, the features, the decisions and the compromises that make a software project work smoothly and efficiently. So when a team member leaves it puts a huge dampening effect on the overall project and the vendor must have a good plan to first manage the team so that doesn’t happen and then manage things when it does happen.

More on this theme on question 8 below and there is a reason to separate them out and ask them a bit spaced apart. You want to revisit this topic to see if the answers fit well.

4. Can you provide case studies of customers who have been successful with your software?

5. Can I speak with a client who is using your product now to get feedback on their experience?

6. How many projects like mine has your company completed in the past year?

This is pretty standard stuff - but sometimes these case studies are not shared publicly. Maybe an NDA prevents the sharing or there are some other reason why they don’t want to put these in their marketing material. So it’s essential to ask and then review these case studies. These are projects that has worked out so you should get a feel of your own project fitting in those - see if you can imagine your project being one of the case studies in the future. Ask questions that are not answered or issues that are not clear in the case studies.

7. What's the best way to reach you during and outside normal business hours?

8. Who will be my point of contact throughout the project?

Standard questions but you’d be surprised how many customers don’t ask this. You should have a clear picture about what to expect when the project is running in terms of communications. All projects will have at least one point in its history where you are desperately looking for a quick answer to a question. It could be during an important demo that you are giving to your prospective customer, it could a bug you spotted that needs a fix right away. You need to know about the contact points and be absolutely sure before any vendor is accepted.

9. How do I know that I can trust you with my data?

Data security if everything in software and it’s important you ask this question right at the beginning. There must be a very clear procedure for data security at the vendor’s site. They must have a plan and a process that ensures that the plan works.

10. How long have your employees been with your company, and how many years of experience do they have in this industry ?

This is a revisit on the team stability question of question no 3. Vitally important question and a revisit is needed to see if the answer to this fits with the answer to the other.

Good luck with your vendor hunting!

Making you software dreams come true

Now is the time

It's never been easier than now to actually develop and release your first piece of software. You can do it in spare time after work or on the weekends so you don't have to wait and delay it anymore. The technology exists to help you move things faster. The only thing that is holding you back is your fear.

 You are not alone in this. There are many people with similar fears - some of them are even afraid to post their ideas on the web because they think someone will steal it. But this just doesn’t make sense, we know first hand how hard it really is to make something good and useful so the huge moat that exists from idea to a real usable software is huge. Ideas are easy, it's the execution that is super difficult. I will argue in this post that now is the time to start - you can start with something and end up with a very different product and a different company. Remember you can always run a rebranding of the company once you know exactly what works. Here’s how you should start.

Take the first step

We all have dreams about making something useful, something that solves a pain, something that makes our life that much easier. That is exactly how all the software platforms around us started. It's very easy to forget that when you are in the middle of the whole thing. But it only takes a bit of research to uncover all the stories behind today's giants. And these people weren't billionaires sitting on their money before they made their products, they were just like us, with big dreams and nothing to lose. Sure there was some hiccups, maybe huge ones, but every little mistake is just another signal for you to change your idea so that it fits with what the market needs.

Start deciding now what is it that you want to make and start doing some research about what the market needs. This way you will make sure you are not wasting your time and energy on something that has already been done or that can't be done properly because there is no demand for it. Of course the last point raises the question: How do we find new ideas? How do we know that the software I'm planning will be something that everyone wants?

What do people really want?

Sometimes it is easier to find a gap in the market. This simply means that you research what your competitors have and try to analyze what they are missing or not doing properly so that you can offer the same product with more advantages. For example, there were a lot of applications for office tasks but no one offered a solution for lunch at the office easily! And that's the niche that all the food delivery platforms filled in. Food delivery disruptors like just eat or uber eats are just ideas that came by finding the gaps in our everyday life's workflows. Take this from the wikipedia article about one of the oldest food delivery apps: :Takeaway.com was created by Jitse Groen in 2000 after he had a difficult time ordering food online from local restaurants. Initially, Groen wanted to deliver all kinds of consumer goods; however, he noticed that food deliveries had the most demand, and decided to make this the company's primary focus. This is a common story for most successful apps.

Another way is to think of something that you just hate with a passion and then come up with a solution. If you have an idea, don't wait for it to be perfect - put in the time and effort right now! Chances are likely that there are many others who share this dissatisfaction with what currently exists so your product will probably find some fans. That's all you need to keep the ball rolling - some early adopters. They will give you the ideas of what else is needed to make it even more useful. What features people will pay for, what they lack in the market. Starting from a small set features leads you to take the baby steps that lead to software that people really want. Take any successful software as an example, look up their history and you'll find that they all started with a very very small set of features and they changed, updated and upgraded all the way. Do you remember how MS Word 1.0 was? It was a disaster, a buggy software that had much less features than the leader in the field then Word Star or Word Perfect. But what MS Word did was solve the pain of remembering formatting codes and use the wsywig paradigm to make users' life easy. It wasn't perfect, but it was a start.

Software is difficult. It requires dedication, creativity and endurance to make it happen. You will have to conjure up the programming language that fits your needs, come up with features for your software, make sure everything works across devices, platforms and operating systems. But if you are now finally ready to face all these challenges - welcome!

How to evaluate software development company performance

Do you find that your software development company is taking too long to deliver a project? Do they lack creativity and innovation? Would you like a partner who can provide accountability and transparency in their work? If so, read on.

As a custom software development company that have worked with hundreds of clients all over the world we have come across all kinds of situations where multiple parties are involved in creating a software platform. The performance of each party is crucial for the overall pace and success of the software project. And we have advised our customers about how to monitor and assess performances of their vendors - including ourselves! In today’s post I will summarize some of the biggest tips we have for our customers to assess the performance of a software developer.

The basics

In order to evaluate the performance of a software development company, there are four criteria worth considering:

speed, price, quality & service

Here's how these factors stack up for one of our clients:

-Speed: Slow delivery times lead to lost revenue as well as frustrated customers. Our client has already seen an average 30% increase in productivity from the new vendor we partnered with them on this project.

-Price: You get what you pay for! The old adage applies here, however there is a big mitigating factor here - location. If you are using a vendor at a relatively lower cost location such as ourselves based in Bangladesh you have the opportunity to find a price that is lower without compromising on the quality.

-Quality: This is the the most important one. In the world of software the only thing that really matters is quality. And you could compromise on pretty much all the other factors but not on the quality.

-Service: How’s the requirement analysis, the communications during the build, the delivery, the promises kept and the promises broken? All of these go towards the service metric.

The performance measurement matrix

The performance measurement is not a linear operation. That is to say it is not a single number you are looking at. For example a company that is great at quality might be really poor at speed. Does that mean it’s a badly performing vendor? The only sane way of getting a full view of the performance is to create a matrix that goes over the issues at stake and measures each one of them against the four basic dimensions of performance mentioned above.

One thing to note before I jump into this: there are hundreds of “scientific” way of measuring performance of a software development vendor. This is a topic that is favourite with efficiency specialists, university computer engineering departments and large multinationals with huge investments in IT. If you really want to get to know some of the research work that is done in this space a great starting point is the highly academic yet useful book generalized towards engineering organization performance: Performance Measurement and Management for Engineers or if you prefer a google search will lead you to a pages and pages of approaches towards measurements. What you’ll soon learn is that there is no standardized foolproof way to do this. At the end you end up with a lot of hand wavy metrics. All the big names in software has said something or other about the futility of measuring performance in software projects! Here’s one I like a lot:

“So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects.”

— Steve McConnell

OK, now that I’ve got that out of the way, let me go over what we suggest. Our approach is pragmatic. We accept that no measurement scheme will be perfect, so all we can do is layout some basic information in a way that’s easier to visualize and let project owner do their own assessment based on that. So that leads us to the matrix I was referring to.

The columns in the matrix are the four basics - speed, price, quality & service and on the rows are the questions or issues that matter to the project or to a particular company. In this super simple method we take away the pain of running elaborate surveys, questionnaires, software line of code analysis etc. that some approaches use and use a very intuitive way of quickly getting to some feelings about the overall performance. Note that the number of rows, that is the issues, actually vary project to project, company to company. And that makes perfect sense, what matters to one project may not be an issue at all to worry about in another.

Here’s a sample matrix that we did for one of our customers recently. They had a total of 28 issues that they tracked with this, beyond the ones shows in the screenshot the rest were specific the product features, stuff like “All screens should update with animation”, etc. These made sense for this particular customer as they thought this was essential for the assessment of performance, but for many other companies such a granular level or such a narrow scope for the assessment wouldn’t make sense. That is the beauty of a simple matrix approach such as this one - it is flexible and can be adapted to the need of a specific project/customer/vendor situation.

When it comes to evaluating software development company performance, there are a number of factors that can help you determine if the vendor is working in your best interest. I’ve outlined our suggested way that seems to work very well for software projects. You can use this at regular intervals (we suggest every 6 months) to check the performance and detect signs of change. The change in scores from previous ones give you the signs of a change in performance - for the better or for the worse. Do any of these signs apply to your current vendor? If need help give us a shout at info@kaz.com.bd to learn how our team might be able to help you.

Making your software: Step 4 - Budgets and funds

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. In step 2 she went over strategies to find a software developer company who will turn her dream into reality. Then she gets good ball park estimates for making the software in step 3. Now that she has some numbers she can work on her next challenge of budgeting and financial planning for the software development.

Software development can be expensive, so a proper budgeting and financial planning is essential to make your software and launch it successfully.

Phases of software launch

There are several distinct phases in getting a software product to the market. These phases actually go way beyond the obvious software development and sometimes the founders don’t really realize all the steps and runs into difficulties with finances when that step happens. Here are some of the phases and what a founder should expect from a budgeting and finance point of view on such phases.

Design and planning

Every software product has a significant design and planning phase. If you cut this phase short you end up a poorly designed software that is hard to use or a software that took a lot more time and money to build because the developers just didn’t have enough guidance on what to make. So it’s essential to invest on the design phase. If money is tight, as it is on most startups, this phase can be less elaborate than what textbooks suggest about design and planning of software but it still needs to have some basic things done. The top focus should be a set of “mockups” of the software interfaces. These are pictures of the software screens as the user goes over common or most used features. If money is seriously short, these mockups can be just black & white rough sketches called wireframes, but that’s the bare minimum that must be done.

Typically this phase will require 10 - 15% of your total budget for the software.

Development of the MVP

This phase is the actual software building phase. MVP stands for minimum viable product and we’ll go over the concept of MVP in a separate post. But basic idea is simple: find out what is the minimum set of features that will sell the software and make that first and launch with it. Here’s good video about MVP..

Typically as founder should plan for 40 - 50% of her total initial budget for the MVP.

Launch and marketing

The launch of the product by itself is time consuming and can come with unexpected costs. The developers may request for server certificates, special cloud setups, software licenses that a founder may not have budgeted for. On top of that the launch process itself takes developer time which adds to the costs.

The marketing is obviously a huge area to think about when you are launching a product. Nothing sells without proper marketing.

Typically launch and marketing should be around 20-30% of total initial budgeting, but note that this is one area where it’s very product specific. If a software is planned to be something based on a huge number of users then marketing itself can take up more than half of the all the money spent in a project.

Releasing the updates

The biggest mistake that founders make is not factoring in the costs of making changes to the software AFTER the launch. These changes are usually the make or break between a software that people use and one that goes into the software graveyard. After all, only after a launch does a founder really get to see what works and what doesn’t, what her users are using and what they are asking for. Based on these real data points a founder has to adapt the software, modify it or fix the bugs to quickly launch a new version (usually a series of new versions) that adapts to the need of the market. This process is iterative, it’s usually time and effort consuming and thus it’s expensive. Not budgeting for this phase means the software never had a chance to fight it out in the market. So it’s absolutely essential.

Typically a founder should budget at least 15-20% of her initial funds for this phase.

Maintenance

Maintenance is the phase of managing to keep the software live over time. This may involve bug fixes time to time, maintaining the servers, updating various components as new versions of the OS or other software is released or new security patches are put out. For mobile apps this means the continuous effort to keep up with the new versions of OS that Apple or Android guys are coming up with, each having the potential to break your software.

A founder should budget for at least 2 years of maintenance after launch in her initial planning. Very much a product specific thing, but typically over 2 years it would take up 15 - 20% of the overall costs.

Payment strategies

When the founder is planning for financials of a project there are certain strategies she can adopt for the funding and the payment to the developers. These are general tips, after all, as each project is different with it’s own sources of funding, own specific situations of payments. Here are two strategies that works well for startups.

Milestone based payments

Setting up a payment schedule with the developer based timed milestones is great for both sides. For the founder it gives certain dates where she needs to make the money available, it also gives are a quantifiable way of seeing what she is getting before she does the payments and of course more solid commitment from the developers about the dates. For the developers it’s a good way of splitting up a bigger software project and getting paid as they build it. It reduces their risk by not lumping everything up for a big payment at the end.

Phased development

The phased development strategy is where the founder just makes her final product over a set of phases. Each phase has it’s own launch, marketing and payment. This way the founder can get the product out in smaller steps, judge the market as she goes along and only commit to more payments if she sees the demand. For a developer too it’s is a good way of splitting a large project up and getting paid early. But note that if the phases are too small this might be impractical for the founder and the developer as the costs of starting and stopping the project in each phase can be a big overhead.

OK, that’s it for today on this series on getting your software made. I’ll be back soon on step 5 soon about finalizing a software partner to get software made.

Introducing new features in your released software

Imagine this: you have released your software. As with any software releases, you had cut corners, last minute compromises had to be made, features had to go out without all the bell and whistles, etc. Yet, you users loved the software, and they have started to use it. As you start getting new users, you are also starting to get requests for features you had compromised on during the release. And people are complaining a bit about the UX, there were things you had thought made sense but it’s not so obvious for your users. You now realize that you have to update your software with a new version.

The good news is that it’s a web app, so updating is just releasing a new version overnight, making sure people’s data isn’t lost and you are done. But the bad news is that your UX fixes and new features mean you’ll need to revamp how the software will be used and the interface is likely to be completely redone. It’s bad news because you know that some people will get confused with your new UI because they’ve learnt your current interface and are using it.

What do you do?

Here are some strategies that we’ve been advising our clients with and they come from working on hundreds of app releases and update.

Release often, but only at the start

“Be agile; release early; release often.” that’s the the drill. But it is strategically wise to keep rolling out features only at the beginning of a product roll out when you don’t have that many users. When your product reaches a certain size, a certain number of users, you don’t want to risk the integrity of your application with every new minor release. The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward. Frustration and anxiety enter social media quickly and suddenly, and the pressure on customer support to respond meaningfully and in time increases with every minute. Of course, we don’t want to roll out new features only to realize that they actually hurt loyal users.

So the plan should be:

Release early, release often only at the beginning of product’s life

Announce the release

You should have a list of its current users. Use that list to communicate that changes are coming so people are prepared. Plan on sending an email announcement, explaining your new upcoming plans, with dates and list of feature changes.

Create a video showing what’s going to be new and more importantly how it will improve things for your users. Remember, this not just a boring news of updated software but it’s an advertising to get your users excited about the new features. That excitement will help ease the pain of learning and adapting to the new interface or the new way of doing things. A lot of people are visual learners and this preview will make the changes feel less unknown the next time they use your software. Sometimes even a animated gif does the job well. Here’s google introducing a new feature with a very short animated gif.

Or basecamp doing a in app popup letting people know about changes that are about to happen. Trello does something similar with their “New stuff!!” fox at the top.

Have app Tours & Walkthroughs for new features

When your users use your app all day long a new update can greatly affect your efficiency. You can easily address that negative by providing a short and easy in app tour to re-teach user behavior and help users with missing or moved features. There are different types of tours, but the ones that point out and walk users through how to use a new feature and answer any common questions works the best in our experience. Gmail has a great one that you must’ve seen. Here’s one I saw recently that I liked.

The good news is that it’s easy to add these in app tours. There are several great products out there that makes it pretty easy. Try out Stonly or Intercom for a start.

Have a “I’ll try later” option

This may not be the easiest option from a dev point of view, but it would be wonderful if you can do it somehow - the option that let’s users use the old interface for a while. Very useful when your users have something urgent to work on and you come in with your all new shiny interface where nothing is where it was! Facebook has them all the time when they do their big UI shifts, but they are Facebook. But you don’t always need thousands of developers in your team to do this. Nifty tricks like having the older version still available on a server and click to redirect users to that version might suffice in some cases :)

Ask for feedback

Sometimes all it needs for your users to be OK with your changes is a simple “sorry for the changes, we welcome your feedback” message somewhere. This humanizes the software and let’s your users know that you are putting them in trouble and that you are willing to listen to them.

Remember how angry we would get every time MS would drastically change their interfaces? We learnt the new way of doing things but we were looking for some way to tell MS what then shouldn’t have done!

Anyway, software is always going to be updated, so you’ll just need a way to make those updates less obtrusive to your users. This is a fact of life! Happy software development…

A software UX design story

This is a story taken from real life. One our customers from the Netherlands approached us with a very interesting idea of a software for gamifying trainings they run. They run trainings for big corporations - stuff like corporate policy, safe working habits, HR good practices, etc. The problem was that the topics were just not interesting enough to keep the attendees engaged. They needed something that would bring in more interest and engagement from the people attending the trainings. And their solution was to gamify the training sessions. They had rough outline of what would work in their heads but nothing in form of documentations. The big challenge thrown to us was capture all the ideas they had, pin them down to software features and also think of ways to make the software usable. This led to a requirements capture and UX design story I’m about to relate…

Chapter 1: Finding the need

We held multiple sessions with the clients and their presenters to gather information about their current working procedures and business needs and singled out the three major requirements:

Chapter 2: Brainstorming

After multiple session of individual and group brainstorming on possibilities, we landed on the idea of developing a gamified presentation eco-system that would include 3 to 5 minutes of lectures or video presentations followed by pop quizzes about the current segment. The participants can engage with quiz live from their mobile device, competing with their peers, gaining points with the goal of being among the top scorer on a live leaderboard.

We came up with four major components

Some key concepts for the components were

Editor:
Create, configure and manage Shows
A show editor
Schedule, share and manage sessions

Projector:
Host's screen:  
* Initiate and navigating a session
Projector screen:
* Showing slides including presentation part and quiz part
* Live responses from users on quiz sessions
* A Live leader board.

Controller: 
A responsive and contextual version of the projected show
Interaction with the quiz slides
Questions, comments and feedback on a slide 

Auditor
View results of a session
Generate reports

Chapter 3: Personas, Use cases and Storyboarding

The next step in our design process was to identify the personas - the typical users of the system. This exercise was done mostly within the design team with a summary session with the customer to get their feedback - we had enough notes from our original brainstorming to identify the typical users of the system.

We then moved on to defining the various uses cases for each personas where we drew up how a persona would use the system to get their job done. For example: How Tom, Dick and Harry, with different personalities will access the show in their own ways.

Instead of just writing them down in spreadsheet or document, which is the standard practice, we decided to do a more graphical representation as this would aid in faster communication of the ideas.

Chapter 4: Prototyping prototyping prototyping

Now that we had a solid idea about how the system would work, we moved on to building prototypes.

We started with horizontal prototyping capturing the global bird’s eye view of the whole system then vertical prototyping drilling down to specific features. Constantly evaluating and refining and gradually moving up from low-fidelity wireframes to a high-fidelity deliverable. 

Chapter 5: Evaluation and hand over to development

The prototypes helped us evaluate the product concept without a single line of code being written. We iterated over multiple version of the prototype by incorporating feedback from the customers and possible users of the system.

With the final version of the mockups done with a graphical prototype acting as a very clear spec document, the dev team moved in to develop the product but that's not the end of the design cycle. With feedback from real users and various stakeholder of the system, we had to to go through a few re-iteration of the design till all in the comfort zone that it was done right (enough).

Great story isn’t it?

Adapted from the original at: https://www.dpixelman.com/ by one the best man to lead our design team, Zahid, who has now moved on to newer things.

Making your software: Step 1 - A rough specification

Meet Priya

Priya is a successful interior designer. So successful that she just can’t find time to serve all the projects that come her way. She has a brilliant idea about a software solution that will be able to scale up her operation. A mobile app where many of her customers can actually do their own interior design planning work and then reach out to professionals like her to put the finishing touches to the plan. She knows it will be a great hit, but she has never worked on software project and has no idea where to start.

This series of posts is to help people like Priya. To help her walk the many steps that lead to a successful software launch. This is the story of her journey, with today’s post as the first step she needs to take - create a “rough specification” - a list of features for her software. This list of features will help her explain what she wants her software to do. She will need this for software developers who will build her app and for investors who might fund her.

A name for her product

It’s best to start with a name.

A name of the software project makes life easier, Priya will not constantly need to say “oh that software for helping people do interiors” - she can just use the name. The name doesn’t have to be final, she can stick to a temporary name and use a name that’s different later on. But it’s important to think of a name that gives a feeling of what the software will do. This thinking of a name helps to kick start the thinking for the software’s feature list work too. And, if she can think of a great name that she will use in the real product she can actually buy the domain too. Giving a name and buying a domain actually helps make the project feel more real to her.

After some soul searching Priya decides to name her software “Designly” but decides to buy the domain later as the exact domains were not available (this would be true for most names you can think of - selecting the domain name will take some imagination!)

The user goals

The next thing Priya has to do is list out the goals of the Designly: what will her users achieve when they use Designly. This list is usually called the “user goals”. By listing the user goals out first and keeping them in mind when she thinks about features she is ensuring that she makes Designly useful for her users. Here are some example user goals for Designly:

1. Users will be able to design their interiors without getting expensive professional help.

2. Users will be able to quickly try out variations of their designs and colors.

3. Users will be able to find great interior designers close to them if they need experts.

It may take a few days of thinking to come up with the user goals list. It’s best to give it the time, to think all the goals through, as some goals are not quite obvious, yet after writing out some of the goals they may come out as obvious goals. Here’s one that may make it in Priya’s list which might not be too obvious at the beginning:

4. Users will be able show their designs to friends and family and ask for opinions.

After all, a great value for a software like the one she is planning is that people can try out designs and check how others feel about the design - just as we do in real life for other things.

The user stories

Now that she has the goals listed out she has to come up with a list of how the user achieves those goals. This is usually called user stories in the software world. If she lists them out in a nice easy spreadsheet her software developers would love that. This is what their product analysts have to do anyway and she is just fast forwarding the whole process with her list and also saving a bunch of money.

Here’s a way most software developers like to write these user stories. It all comes from the Agile principles of software development, and it’s worth reading up about this a bit. This agile way of making software is the best for a startup project like Priya’s. So here’s how Priya needs to write the user stories, she should structure each of the stores in the formation of:

"As a ………………. I ………………. , so that ………………. ."

Here’s an example from her product:

"As a home owner, I want to easily try out different colors in my room’s design so that I can see what combination works best for my room."

Since there’s likely to be a whole bunch of these user stories with some of them more important than others it’s good to have them in spreadsheet with the columns laying out the structure and with additional columns that can give other information. We always tell our founders to keep it simple, it’s important to get the thoughts in place rather than worry what’s the right and the wrong way of doing things - since there is no right or wrong. Here’s an example of such a spreadsheet:

A picture or two

With the list of goals and stories Priya would be miles ahead with her software project. She would have something to talk about with software developers or investors. But one extra little effort would magnify her effort by a lot - creating some pictures. You know how it goes - “a picture says a thousand words” (btw, if you ever wondered, that line is originally from Ibsen - morphed into what it is now). In the software world pictures are needed not only because of the thousand words, but also because they might tell the right set of words. Here’s a great picture that explains this (again proving that pictures can explain things so much better! We’ve used this before in a related article that’s worth a read for Priya too: interface between technology and business).

Priya doesn’t have to do anything fancy to make the pictures. Even some hand drawn pictures of how she thinks the software might look like or interact will be a great addition to the rough specification that she is making. But we suggest a great tool that is used by professionals and non-software people around the world: Balsamiq It’s a really easy to use software that let’s you do quick pictures of software interfaces.

With a tool like balsamiq Priya can churn out some concept pictures about the software very quickly. They don’t have to follow any “software UX best practices” or anything, that’s the job of the UI/UX experts. But having these pictures does a double check on the list in the spreadsheet and also helps Priya think through how the goals and stories might actually be in a real piece of software. This understanding of the process of translating words into software interfaces, the difficulties involved and the thought process is invaluable during the actual process of making the software. It would help Priya understand the timelines, estimates and also make her very effective in giving feedback to the designers when they do the actual software interfaces. Here’s an example of how one Priya’s drawing might look like. Even this single picture would help the software developers so much to understand what Priya is thinking of in her software.

That’s it for this step. With the list of goals and stories and with few pictures of the software interfaces Priya is all done for her specification. Now she can find any software developer (the next step in her story) and explain what she needs quickly and ask them to give a price idea. I can tell you that any software developer she goes to will have a happy face when they see her rough specification ready for them!

If you want to use our template for the goals and stories, download it by clicking the button below…. Watch this space for the next one on the series that helps Priya find software developers for Designly.

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

10 Steps to Making Your Software Product

You have a great idea for a software.

You want to make it and launch it. But you are not sure how to move forward.

This is one of the most common situations with first time software entrepreneurs. Things can be very confusing for software products when it’s your first time. Where do you find a good software company that will make the software for you? Do you first figure out how much it’s going to cost? How do explain your product idea well enough so that the software company can get you realistic estimates? How do you ensure that they keep their promise? How do you know if they delivered a good software product? What happens after the software goes live? What happens if it needs a fix or a change? There is a whole list of important questions that needs answers before you can really make up your mind and move forward.

But where do you start?

As a software company helping entrepreneurs like you for the past 16 years we know your pains. We’ve helped many entrepreneurs turn their dreams into reality and launch their products.

We want to share our ideas and experience in this new series of articles called the “Making your software”.

The Steps

Before you do anything, you should have a rough idea about the stages you go through to get your idea into a working software product. So here goes, the life story of a typical software product - from the perspective of the entrepreneur.

Step 1: A rough specification

This is just you (and your co-founders) writing up (or even better drawing up) what you want to build. Doesn’t have to be perfect, or even very detailed but the moment you start asking software professionals questions like how long, how much, etc. they will want this from you. So this is the first step.

We’ll go through some tools you should use to get the specification done and also provide you with a template that works great for a rough spec. Read the post at: Making your software - Step 1 - a rough specification

Step 2: Find and compare software developers

This is the most important step in the story. A good software developer (like us :) ) is the key to getting your product launched. They will guide you through the rest of the stages, giving you advice about where to compromise and where not to. It’s absolutely vital that you research a bunch of vendors and find the one that fits you the best. Remember that the fit needs to be with you - a vendor can be the best skilled, most experienced, etc. but if they don’t communicate at the same wavelength as you nothing will ever get done right.

In the upcoming posts we’ll go over the basics of what you need to look for in a software developer and get you a template form you can use to survey the vendors and then compare them.

Step 3: Getting ballpark estimates

Ballpark numbers are very rough cost estimates based on the specification (from step 1) you give to the developers. This number helps you figure out costs and plan your funds. Always get ball park numbers from developers you short listed from step 2. You’d think it makes sense to ask for a number for from everyone as part of step 2, but in most cases the number will either be too much of a guess or plain wrong. To get a reliable ballpark you’ll need to spend some time with the developer to go through your concept, answer their questions etc. And obviously you can only do that with only a few.

We’ll guide you through a series of questions you should ask and things you should clarify to the developer to get a good ballpark number.

Step 4: Budgets and funds

This is the nitty gritty of how much money you’ll need and when. How you’ll get the funds and pay the developers. We’ll do a post on typical payment strategies, expected costs throughout the lifetime of the product and financial planning.

Step 5: Select the software developer and an NDA

This is where you finalize the software development partner and setup how you will work together. The actual legal contract is important, but at the end secondary - since no legal write up can replace a good working relationship. It’s extremely important to setup an operating process - decide how the project will move forward, how you’ll see the results and give feedback, the timeline, etc. The non-disclosure agreement (NDA) is your protection for the idea about the product as the software company will require you to go over the details of your idea before they can give a final costing they can commit to. There are variations to this plan, but this is typically the path most companies take.

We’ll do a post in this series with a time tested foolproof process along with a typical NDA template that does the job.

Step 6: Brainstorming/wire-frames/mock-ups

Now that you have a software developer on board and a rough specification in hand it’s time to brainstorm the idea and turning that idea into a working piece of software. You start by pinning down the features into a list, setting priorities for the features based on business importance and technical difficulties. The goal would be to target the “lowest hanging fruits” first - do the features that your customers would love the most which are also technically easy. For startups this path is the safest, with the plan of rolling out a product fast and possibility of cash flow along with early feedback from real customers.

Once you have that list of features thought out the next step would be to create storyboards - pictures of the software and how particular features would work. The software company’s designers and product analysts usually walk you through this. They do these first without worrying too much about the exact colors by drawing them up on rough sketches - pen and paper works but a software tool is better. This is wire-framing. And then they start putting colors and logos on them to create mock-ups - the pictures of the exact look of the software. How much detail you do depends on your time-line, budgeting etc. But you absolutely need to do at least some basic ones to get an understanding about the features. At Kaz we do the preliminary part of this process free. Some companies charge for this too. So this is something you have check with your vendor to decide beforehand.

In this series I’ll go over some tools we use and give you templates for the features, specifications and wire-frames.

Step 7: Final estimate and a contract

Now that the software requirements are well understood on both sides (remember, your original idea and the exact reality of the software may have changed a lot during the brainstorming!) it’s possible for the software company to commit to a price. Usually the price is close to the ballpark number (our typical error margin is +/- 30%), so it shouldn’t come as a big surprise. But it’s always possible that the idea has evolved far from the rough spec you had (which was the basis for the ballpark). This is where both sides can sit and decide how to align things. One way is to break up the product in phases, and do the deliveries in phases to fit with your budgeting. Or you could be compromising on certain features (e.g. “let’s do the facebook integration later since it will save 2 weeks of dev time”) to reduce the costs. Once you have reached a decision on the pricing you do the contract. Again the actual contract is much less important than the relationship and the understanding of the project features and priorities, but obviously you need the legal paperwork. The goal in the contract is to try achieve something that’s a win-win for the ever changing world of a software product.

We’ll share a template that has been time tested on startup projects and discuss the important things to go over during this step on finalizing the price.

Step 8: Development

This is where the actual product gets built. The part we love the most! This also the most important, time consuming and expensive part of the full activity. So you absolutely have to get things right to optimize it and make sure the project moves along at the right pace, risks are managed and a process is in place that ensures that things are done over and over.

We are super experts in this space, and after a thousands of times on the merry-go-round of software dev cycles we have very specific ideas about how it should be done right. We’ll share them along with some reporting ideas in this series.

Step 9: Marketing Plans

Without your marketing plans you software launch will never work. This is something you’ll need to do in parallel to the development work so that you are all ready to go when the software is ready. You’ll need a lot of technical help in this regard - since a lot of the marketing will be digital marketing. User tracking, social media integrations, interfacing for customer support, SEO, etc. all need the software company to help you out in this process.

We’ll share a list and a spreadsheet to track these. You should use this to coordinate with the software company and also clarify the need for help in this front with them.

Step 10: Launch

Wohoooo! This is the most exciting part. But this part needs very good planning to get right. There are all sorts of things like hosting, domain pointing, social media assets, launch activity planning, advertising assets and a million other things to worry about. Make sure you plan this before hand with the software company.

We’ll do our typical launch activity run down with you in this series and provide you a spreadsheet and a “cheat sheet” for launching your first product.

Life after the launch

Launching of a product is really just the beginning of your long journey as a software entrepreneur! What you launch first is just the version 1.0. You have to then see what the market actually wants, what you got right and what you got wrong and then roll out newer versions of the product with additions, subtractions and most importantly modifications. At the same time the marketing and sales part of the story should take center stage - since if you can’t sell the product you will soon run out of money! Along this same path is the need for maintaining the software - fixing bugs, patching the hosting server or updating a mobile app for newer versions of operation systems (e.g. “Oh no iOS 14 has changed everything and we need to fix our app for it!”).

We’ll lump up all the million things that you are supposed to do as part of your life after launch into a post and give you some templates and plans to guide you through this life!

That’s it folks! It may look super complicated but I can tell you it’s not once you learn the basics. When you have a good software partner (ahem, like us :) ) it’s even easier as most of this they will guide you through anyway. Also watch this space as we do the posts over the next few weeks. We are always here to answer any questions you might have. Just drop us a line to ask using the button below. Our startup project experts are always happy to discuss your projects!

At the end it is an exciting and intensely creative activity that I know you’ll love. Remember, if you don’t do it now, someone else will soon enough, so now is the time!

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.