Whether an internal team, freelancer, or agency there are a few key elements within the journey of building great software. You’ll hear words thrown around like agile, waterfall, or a myriad of other systems. Regards of how you think about the work or the framework one ascribes, the same basic elements exist. Steps may get skipped or ignored, but I’ve yet to experience a software project that doesn’t contain the following elements.
User Interface Design
It’s important to understand the vision for the project. Rather than imagining a list of features and objectives, it’s important to focus on the customer. What is their problem, their need, and the job they are trying to accomplish. This is where you should define priorities as well. Every decision has costs, but understanding your non-negotiables will ensure you optimize for the right outcomes.
Rushing the strategic conversations will result in lack of direction and guidance throughout the process. If you know why you’re building and who you’re serving, it will keep the project on track and moving forward.
The deliverables here should include high level features, clearly defined priorities, and a outlined importance of the road ahead. The difference between a prototype, an minimum viable product, and a version 1 could mean the difference of months or even years. The path forward for each should be very different.
Imagine we’re building a house. This is where we cut out photos from house magazines, sketch out floor plans, saving money, and making sure the right people are available and onboard. There is infinite variables among 3 bedroom homes, but understanding your ultimate plans for the home will help you make hard decisions. A home built to rent-out is constructed with different intensions than one built to live in for the next 50 years.
If this were a simple website, this would be a sitemap. In custom software, the need for organization and thoroughness is much higher. We unpack all the key user decisions and make sure it’s aligned correctly.
This step is often buried within the User Experience and Wireframing portion but it can (and likely should) stand alone. The architecture decisions about how information flows and how it is organized within the system is about more than images or button placement.
The deliverables here should look something like a traditional sitemap. You’ll likely uncover informational patterns and understand the ‘depth’ required in the user journey. Features nested too deep within a system rarely get used.
If we’re sticking with the house analogy, this would be where we organize all the photos, facts, and figures we collected and start to curate and clean up. You may conduct research from others who have built similar homes and continually rearrange to optimize space or flow.
User Experience yields wireframes. We start with low fidelity versions at first then move on to move refined, high fidelity images. Depending on the needs of the project, a clickable prototype may be appropriate and will allow simple interactions with the system.
Producing over-designed wireframes can often prove distracting. It’s not uncommon for the conversation to shift into colors and aesthetic before key decisions have been make about the structure. Personally, I prefer low fidelity and under-designed. If nothing else, it helps keep your brain in check.
A lot of time can be spent in this phase. To most accurately estimate implementation, complete wireframes are the most helpful. Unfortunately, that isn’t always realistic with time and budget.
This is the blueprinting phase of the house. There aren’t walls and it doesn’t feel ‘real’, but clarity here will influence everyone’s ability to make the right decisions later.
User Interface / Design
During design, we add color and life to the Wireframes. We address things like motions, mood, and aesthetics. The use of color, size, movement, and imagery can entice and direct users appropriately. A solid Brand Guide can make this process more straightforward, but there is often plenty of room to craft an impactful digital experience.
We prefer to perform design work in smaller sprints to allow plenty of room for feedback and revisions. The design phase is typically where the work begins to reflect a closer representation of the final product, which elicits many more opinions.
Selecting the paint and light fixtures would be an appropriate comparison. While the flow and structure of the house is set, the mood and attitude can still be shaped.
Development Sprints are where the code gets written and the process starts to come together. We like to add in time for other stakeholders to be involved, but it’s mostly software engineers driving the project forward.
As the software is being written, regular check-ins help polish the product and remove barriers. We break this time into 2 week sprints so course corrections can be made. Each sprint, key decisions should be evaluated. In such a fast moving industry, spending too long without revision can lead to building something that is obsolete.
This is where hammers start swinging during the home process. Since the plan was been made, it’s time to breathe life into the actual system.
This is where the final checklists are completed and the system goes live. Things are tested in isolation through the project but during deployment is where everything should fit together as expected.
We prefer isolated deployments along the way, but large tech companies continue to preserve the illusion of a ‘launch day’. Regardless of how you position it, everything changes once production users and real data is moving through the system.
It’s time to throw a house party! It’s unlikely the house is without blemish, but it’s good enough to invite family, friends, and neighbors to enjoy.
It’s not enough to ship it. Regardless how great the software, getting customer buy-in is key. The process is often approached with a Field of Dreams mentality; ‘Build it and they will come’. That is simply not true.
Ideas or tools are dead without adoption. It’s the hardest work of all. Without it, nothing else matters.
It’s not Magic
Most of these ideas did not originate with us. They were researched and adapted based on some of the best and brightest that software engineering professionals have to offer. Books that continue to guide our thinking include:
Don’t Make Me Think.
We’ve also been fortunate enough to survive since 2012, bringing hundreds of app ideas to life. Experience has proven to be one of the greatest teacher.
Whether jumping half way into a project or starting from the ground up, it’s important to make sure subsequent steps have been respected and fully explored.
When we step into an existing project, we’ve found an adequate ramp up time is required to understand past decisions and move forward in an informed direction. Skip steps at your own risk.