
Many moons ago, in my early years of software development, I was obsessed with minute visual details. I would spend hours experimenting with gradients, shadows, rounded corners, and effects. While I still appreciate the impact this has on the final product, I’ve come to realize that design flourishes are just a minor part of the overall design process, and one that can eat countless hours without proper self-discipline.

Nowadays, when I design an application, I try to intentionally avoid focusing on visual polish until the end of the process. Typography, color, animations, and polish are still essential – they are what give your product its own unique feel and branding. But design is so much more than polish, and if one focuses too much on it they may do so at the expense of the more critical components.

My mockups are now mostly grayscale and with a default font. This allows me to focus on the key aspects of design:

* What is the primary purpose of each page?
* How should a user flow through your application?
* What are the primary and secondary calls to action for each page?
* How can we make it easy for a user to know what they should do next?
* How can we improve the onboarding process for a new user?
* How can we make an experience that works as well on a mobile device as on an ultra-wide monitor?

I still enjoy the polish phase of the design process, but nowadays I am far more aware that it is just that – polish.In my software development evolution, I've transitioned from obsessing over visuals to focusing on design's core—usability and user flow. Initially captivated by the aesthetics of gradients and shadows, I now understand these elements as mere finishing touches. Adopting a simpler approach with grayscale mockups, I prioritize the user's journey, from their initial interaction to seamless navigation across devices. This shift hasn't lessened my enthusiasm for visual polish but has deepened my commitment to creating intuitive and accessible applications.

How we keep costs low


Software development has a habit of being expensive, but with the right planning it doesn't have to be. There are several techniques that can be used to keep costs low and development speed high. When these techniques are used, the result can be a win for both the client and the consultant.

### Designing software is hard

A project manager has the unenviable task of figuring out what their software needs to do - a process that can often feel like divinity. 

In an ideal world, project managers can reach out to users to understand their needs, but this process is fraught with problems. It can be hard to separate  valuable users from the noise, and users have a habit of requesting features without considering the value they will offer or the cost required to implement them. Finally, it can be hard to a user to understand what they need - or how they will use a tool - without having it in front of them. These factors typically lead to unnecessary features when determining the needs of a program.

![Traditional development](/assets/costs-low-1.png)

### Learning from startups

Startups are no stranger to the problem of software bloat, but their limited financial runways have resulted in a rather clever solution - the minimum viable product (MVP). 

An MVP is the simplest solution to a problem. It can behave as a foundation for future development or even just a testing platform to validate the idea. MVPs do not typically focus too much on the core technology; they often even take advantage of other third party solutions to do much of the work.

### Build, Test, Repeat

The key to a successful MVP is testing and measurement. Once the initial version is launched, the product now goes from a theory to a testable model. This is the point where you can reach out to your users and see which ideas worked, what was better on paper, and what to focus on next. Development takes an iterative approach - build, measure, plan the next step.

This iterative process is how we try to keep costs low. By breaking the development process into an ongoing series of features, we spread development costs over a series of more manageable contracts. At the end of each contract, the client has a usable tool; one that can be distributed to users, measured, and reviewed to determine the best step forward. Clients are not stuck paying for features that will not be used, and the development timeline is structured more around the client's needs and the true requirements of the tool.

![Iterative development](/assets/costs-low-2.png)

### Lower costs mean more flexibility

Breaking a project up into chunks does more than keep costs low and development speed high - it also gives clients more freedom. The cost of maintaining and developing a project goes up as its complexity increases, so by starting small we also reduce the associated costs, such as hosting fees and maintenance contracts. Breaking a project up also gives clients flexibility to schedule the development flow around their budget and schedule. Most importantly, it lets users engage with the tool before it reaches final form. This could be as simple as using the tool internally, testing it out with beta testers, or even selling it from an early stage.

Breaking projects down into multiple tasks reduces the risk of overspending, which is why we are big fans of the technique. At the end of the day, we would rather have a happy client that has paid us less than an unhappy client that has paid us more but feels they have overspent on their project. 


Big projects should be broken into smaller chunks

Launch early and keep costs low


Planning is the most important step of a project, and we believe it’s where you should spend most of your time. At Empathy, we routinely spend more than 50% of a project's time in the planning stage. 

We didn't always do it this way, but after years of building software we've found the following benefits:

## 1. You will likely find a more elegant way to solve your problem

Chances are you've built up a process over the years that you have conducted business, and you want your software to follow the same path. 

Planning gives you a chance to think deeply about your requirements and try to find a more elegant solution. A lot of complex processes started off simple, but as your business grows and your client base expands, your processes grows in complexity to meet every edge case.

When you are creating new software to solve your needs, you have the ability to rethink your process with an up-to-date understanding of your requirements. Doing so often allows you to find a different, more elegant process that accomplishes the same goals. Diving deeply into your processes is extra useful because...

## 2. Your most complex features may not be your most used features

It's common to enter a project knowing that your software will need to support a large number of features, or that some components will be extremely complex. 

![How long it takes to build](/assets/planning/how-long-to-build.png)

In practice, however, it's common for the bulk of an application's usage to take place in a few key components:

![How often it gets used](/assets/planning/how-often-used.png)

Knowing which parts of your process are used the most gives you a number of options for how to proceed:

- In some cases you may have the luxury of launching a product with a limited feature set, resulting in a quicker launch date and lower development costs
- If you need a complete feature set at launch, you may be able to address your less critical requirements using [third-party tools](/posts/prototype-on-services)
- There may be ways to integrating your new software into your existing processes, allowing you to launch new implementations of your key requirements earlier and build the remaining feature set iteratively

## 3. There is less cost associated with experimenting

It's rare to have an idea that remains unchanged from concept to final form. Even the best ideas benefit from experimentation and user feedback. The more built up your product is, the harder and more costly it will be to throw your old ideas out and try something new. 

During the planning phase, the cost associated with experimenting with alternative solutions and getting user feedback is the cheapest it will ever be. It's far easier to sketch a new concept or try an idea on a third-party tool than to implement a new program.

## 4. Work done during planning gets reused

Planning and design are closely related - in fact, the majority of design work in our projects actually gets done during the planning phase. The mockups that come out of our planning phase have many of the key elements of design - the site's navigation, page structure, action items, and flow.

Our 'design' phase is really focused on polish - colour, typography, iconography, animation, and all of the little things that make a product feel good. A good design should start before any code is written.

{/*Here's an example of what our mockups looked like during the planning phase for Green Globes:

![Green Globes Planning Overall](/assets/planning/gg-planning-overall.png)

And here's a closeup of one component of the site:

![Green Globes Planning Closeup](/assets/planning/gg-planning-closeup.png)*/}

Your planning work may also include prototyping concepts with third party tools. In some cases, you may find that these prototypes are good enough to meet your needs, saving you from having to move beyond the planning phase.

## 5. Good planning leads to good MVPs

Good planning is essential when building a [minimal viable product](/posts/mvp). 

A good MVP should cover the essential requirements of your product and no more and should not hold you back as you build it up into your final form. There's nothing worse than launching a limited MVP that doesn't do everything you need and that slows you down as you try to turn it into a full-featured product. You want your MVP to be light, but you don't want it to have a weak foundation that cripples your final product. 

Good planning allows you to design an MVP that works with you instead of against you as you evolve it into its final form.

## Planning saves time

The time spent planning a project can sometimes feel like wasted time, but it's key to launching a product on time and on budget. The work put in at the start pays dividends when the coding work begins.


The most important step in the creation process comes before the code

Planning is the most important step


One of the incredible benefits of building for the web is that it’s very easy to understand how your customers use your products.

This is something that is baked into how people use the internet, because most interactions a user will have on your product requires a back-and-fourth exchange with your servers. Compare this to a more traditional industry such a retail, where companies have to go out of their way to collect data on customer behaviour - entering partnership with retailers, installing tracking hardware, and filtering the results to find the data that is relevant to their product. The comparative ease with which we can measure online behaviour is a real strength of software, and we believe that it’s very important to take advantage of it.

Being able to understand how your clients use your products can - and should - change how you build them. It rewards rapid iteration and experimentation. You are no longer obligated to guess exactly what your customers need; instead, you can come up with a hypothesis, build a good enough version of it, and see if customers adopt it in the way you expect. If they do, you can refine it and continue to build it up. If they don’t, you can scrap the idea before it becomes too costly or too familiar to your existing users.

Measuring data also opens the door to new ways of developing. For example, consider the A/B test. An A/B test is an experiment in which you create a variation on an aspect of your product. You can then push this variant out to a subset of your users and measure how it affects their behaviour. If it has resulted in a positive change compared to the control group, you keep it. If it doesn’t, you scrap it and try again. A/B testing is a bit of an art form, and there is a lot to explore on this subject (we recommend starting with [Smashing Magazine’s guide](https://www.smashingmagazine.com/2010/06/the-ultimate-guide-to-a-b-testing/)). In practice, we’ve found it to be an incredibly powerful tool when trying to optimize a sales pipeline, the user onboarding experience, or another other critical subset of a tool.

*A quick note on privacy.* User tracking has gotten a pretty bad rap in the last few years, and rightfully so. If done badly, it can be a privacy nightmare and can now even run you afoul of government laws. Thankfully, all of the major companies that provide these tracking tools have embraced all of the new legislation, and it is now possible to design user tracking in a way that respects user privacy and allows customers to understand what data is being collected on them and opt-out.

User tracking is one of the great advantages from working on the web, and we encourage all of our clients to take advantage of it. A well-integrated data collection tool allows clients to design their programs based on the needs of their customers, which often results in simpler, more effective, and less costly programs.

The web offers unique opportunities to understand your users. Take advantage of it!

Measure your data and iterate on it

Purpose, flow, and intent are the most important elements of design

Design is more than a visual thing

Why we like to build prototypes on other services


![Building an application, LEGO style](/assets/saas.png)

A few years ago we were very limited by the number of non-programming tools that were available to us. But the world changes fast, and we now have a number of tools that let us build surprisingly complex applications with minimal effort.

*Airtable* and other applications are changing what you can build without touching code. *Squarespace* and *Wix* make it easy to build complex websites in a UI. *SurveyMonkey*, *Google Forms* make it easy to ask complex surveys, and some even allow for calculations and actions to be performed based on the results.

These non-programmer services have a number of advantages over a custom application.

For starters, they benefit from economies of scale. As multiple users purchase a subscription, the cost is significantly less than when building a custom application that will only be used by one organization. The subscription cost also covers hosting/operational costs, ongoing development, support, and maintenance. In many cases, the total cost of a multi-user subscription plan for most of these SaaS (Software as a Service) services is less than just the cost of hosting a custom application.

In cases where the requirements of an application can be covered by a SaaS service rather than a custom application, the SaaS option will normally be the preferred choice on cost alone. However, there are more advantages to the SaaS side than just cost.

By using a SaaS application as your minimum viable product (MVP), you can speed up development of your initial version significantly. If custom content is required, multiple non-technical people from your organization can enter content simultaneously.

Non-programmer tools can typically be tweaked far more easily and cost-effectively than custom applications, and this work can be done by a non-technical team. The skills learned when navigating these SaaS services can then be used by clients when they wish to design new applications in the future.


### What to look for when picking a SaaS

Besides being able to accomplish the functionality you are looking for, there are a few key things to look out for when picking a SaaS service:


1. Can the tool be extended through an API
2. Can you get your data out of it?

If the tool has a rich API, it can be manipulated to produce far more complex and capable applications. For example, a Shopify storefront can unlock access to an application built in Airtable. Your application can use your company’s existing authentication/login platform to handle authentication and account management/permissions. We can (and often do) build custom micro-services that act as glue binding multiple SaaS products together, and build individual features that cannot be solved with SaaS options.

Most SaaS services have the ability to pull your data out of them. This is a critical aspect to consider when choosing a SaaS service. If you are able to export all of your data, you can launch with a non-programmatic MVP and move to a custom-built application down the road without loosing any customer data.

If you are interested in using these techniques to build your own application but want a little assistance, [we’d be happy to help](/contact/)!



The most expensive solution is always custom code

Use third party tools whenever possible

Don’t be held hostage by your programmers


When you decide to build a custom program, it can be a liberating feeling. You have complete control over everything – at least, as long as you have a good relationship with your programmers. If your relationship sours, however, it can start to feel like a hostage negotiation.

# It’s not always your fault

We can all hope to have a great relationship with the programmers we work with, and most of the time this is the case. But there are situations where things can fall apart, sometimes because of matters out of your control. Maybe the relationship starts off well, but the development team become significantly busier and they can’t meet your deadlines. Maybe their rates go up to a point where you cannot afford them anymore. Or maybe the consultancy goes bankrupt or gets aquired.

So what can you do to avoid this trap?

# Be generic

There are many ways to write a program, but they all start with picking a programming language and framework. The language is how programmers talk to the computer, and the framework is the set of pre-built tools that allow them to make complex programs without starting from scratch (think table saw vs. hand saw).

Any decent programmer will have a lot to say about programming languages and frameworks, and for the most part it’s a good idea to nod your head and agree with their preferences; telling a programmer what tools to use is a great way to start the relationship on the wrong foot. However, there are a couple of things to watch out for.

In most cases, it’s a good idea to work with a language that is mature and widely used. You’ve probably heard of many of these languages – Python, Ruby, Javascript, C#. These languages all have huge numbers of skilled programmers and mature frameworks that make it easy to build standardized code.

You may sometimes be recommended a more up-and-coming programming language, such as Go, Erlang, or Rust. These languages all have their benefits, but unless your program could really benefit from them it’s best to avoid going this path; you will find that it will be harder to find skilled programmers who specialize in these languages, and the frameworks you would have to use will be less mature and will change more frequently. You should also try to steer clear of programming languages that are getting long in the tooth (ASP, Perl, .NET 4), although it’s less likely you will bump into programmers eager to use these.

Even more important than the programming language is the framework your program will be built on. A good framework should be quite opinionated with how programs are built. This makes it easier for a new programmer who is taking over a project to familiarize themselves with how everything works. Frameworks like Django, Ruby on Rails, Laravel, .NET Core, and React are quite mature and have a pretty standard way of building things.

Up-and-coming frameworks are always exciting to programmers because they are designed to work better with new technology or solve a limitation with a mature framework. What is most exiting for a programmer isn’t always best for the client, however. Frameworks need to go through a lot of trial and error and development before they develop a standardized approach to development, and during this trial-and-error phase you are far more likely to require refactoring or a longer onboarding process for new programmers. Examples of (excellent, but young) up-and-coming frameworks are Vue, Riot, and Polymer.

# Compartmentalize

The less complex your application, the easier it is for another developer to step in and maintain it. Simplifying your program may feel impossible, but it’s likely there are ways you can simplify your concept or break it into smaller programs.

It’s now possible to build multiple small programs that look and feel like one larger application. Applications can easily share a common UI thanks to new design frameworks like Bootstrap and Tailwind, allowing for a common ‘feel’ while jumping between programs. Your programs can talk to each other behind the scenes using APIs, allowing for multiple separate programs to act as one. And you can use a Single-Sign-On implementation to make sure that each of your programs can seamlessly authenticate each user, without requiring them to log in again every time they switch to another program.

Compartmentalization does come with some tradeoffs that should be considered, however. Developing a series of separate programs that work seamlessly together does take a little more time compared to building a single monolithic program. When building a system this way, it’s extra important to plan ahead to make sure you compartmentalize all of your requirements in a smart way so you do not end up with a huge cluster of individual programs. And running a series of programs can – if done badly – cost more to maintain than a single monolithic program. In most cases, however, these pitfalls can be avoided or minimized.

# Build with “no-code” tools

Compartmentalization is even more powerful when you start to take advantage of the new batch of no-code tools such as Webform. These new tools allow non-technical people to build programs using drag-and-drop interfaces, and they can be combined together to build powerful systems.

There is one big drawback when building with no-code tools, however. When you determine what your program needs to do, chances are you are designing a system in which you have complete control. And when you have to implement using a bunch of tools that you have less control over, it’s very unlikely that what you have in your head will translate perfectly. But there is probably a way to do what you want to do in a slightly different – but just as effective – way if you are willing to give up some control and work with the capabilities of these tools.

# Avoiding a hostage situation

With the right approach, it is quite possible to build complex applications with a consultancy without finding yourself bound to them for eternity. By building on top of mature programming languages and frameworks, compartmentalizing your needs into multiple programs, and embrancing no-code tools wherever possible, you can build complex programs that can be easily passed on to a new development team or even scaled up to multiple teams at once.

Build on technology that can stand the test of time. Leave guidance for your successors

Rule 1.

Planning is the most important step

Rule 2.

Measure your data and iterate on it

Rule 3.

Design is more than a visual thing

Rule 4.

Launch early and keep costs low

Rule 5.

Use third party tools whenever possible

Rule 6.

Don't make your clients hostages

Rule 2.

Measure your data and iterate on it

Rule 4.

Launch early and keep costs low