The TableCheck approach in software development
Save time by following a design system and testing critical journeys/features with users before implementing them. Let the end-user be the North Star
Building software can be a very expensive and risky venture, especially because of how quickly technologies change in the industry. The app you build today might become already old in a few years. Therefore, to minimize the risks, it's very important to have a very solid foundation, move quickly and keep iterating and improving the product.
Let's review step by step all the concepts, requirements, and processes we are using when building new software from an engineering and creative perspective, right from the initial requirements straight down to the product launch.
Most important high-level points the software needs to fulfill
Satisfy a strong market demand
Include the company vision/goals and the investors' priorities
Be highly aligned with what the end-users need and want to use
Provide an excellent performance, bug-free accessible user interface/experience, and clear information architecture
Invest time in building clickable prototypes and validate the journeys and the core features with the users before starting development
Follow the design system guidelines
Release an MVP to production quickly
Prototype quickly to cover as much terrain as possible and find out the extra things you will need that were not part of the initial plan
Avoid premature optimizations. Validate your product in the market first
Gather feedback from the early users and keep releasing new features in small batches
Keep the maintenance and infrastructure resources and costs as low as possible
Assemble a team that is set up for success
What defines a solid foundation
Like when building a new house, before the construction starts, the right group of people must be in place, with the correct materials, tools, and plan.
The ideal squad
Every project starts with a team. Depending on the available resources, size, and complexity of the project, the team would be big or small. For a new SaaS product of medium complexity that aims to operate globally, the minimum size of the team has to be around 10 people. That's a general ballpark figure. It can be very different depending on the circumstances and the skill levels. In any case, it is recommended for the team to include the following leading roles:
Product Manager (sets the vision, goals, business trajectory, etc)
Project Manager (sets the project scope, timeline, budget estimates, etc)
Design Lead (creates the IA, wireframes, mockups, prototypes, etc)
Tech Lead (creates the dev architecture, writes the technical docs, etc)
SRE Lead (creates the infrastructure and reliability plans, etc)
QA Lead (creates the test plan, writes test cases, automation, etc)
Product Marketer/PR (promotes the product in several channels)
The rest of the team would be filled with QA/Front-end/Back-end/Reliability engineers and designers depending on the skills required to fulfill the project requirements.
If the Product Owner and Scrum Master roles are required but cannot be filled, they can be assumed by some team members with the right skills and motivation.
There are also some important points that sometimes are not talked about enough but can make a notable difference in the team efficiency:
Split the team responsibilities clearly based on skill level and personal motivations. If necessary, rotate them once in a while to keep everyone engaged and motivated
Foster a culture of ownership. Everyone in the team should be responsible for creating and owning something meaningful. Engagement is a key factor, especially in long projects
The leading roles need to proactively make sure everyone feels included in the team and their opinions are valued. They also need to be effective communicators and leaders who apply critical thinking and problem-solving skills
Team and project setup
Apart from having a solid team, there are also certain aspects before starting a new project that need to be as ready and mature as possible to avoid delays:
Infrastructure: all the code repositories, servers, testing environments, domains, 3rd party services, etc
Project management software: ticket/issue tracker, boards, documentation site, calendars, resource allocation, team communication, etc
Work methodology: the squad members should agree on which methodology to use and find the right people to handle the processes
Domain knowledge: everyone in the team needs to use a ubiquitous language (use the same names/acronyms) and have a single source of truth to learn about the domain concepts
Tech red lines: there are certain requirements that can affect greatly the final tech stack, like the need to support IE, SEO, bundle size, etc
Design system: UI toolkit, guidelines for accessibility, iconography, typography, photography, etc
The design system
One of the most important aspects of building great software is to use a proper Design System and UI toolkit. Aside from guaranteeing design consistency and communication style across apps (Web, Android, iOS), websites, Social Media, and print materials, it also makes the products more maintainable through the use of reusable components. This also provides teams with the Lego blocks to create new prototypes and test new concepts and ideas using the same common visual and technical language.
It's fine to experiment with many different ways of creating products, from organizing teams into squads to using different work methodologies. Nonetheless, the design system has to be always at the center of every new project. it's like a Bible that is constantly being improved. Adapting to the changes in the industry and providing a single source of truth for the teams in the organization. If you take care of it, it will allow you to build products much faster and with better quality.
The work methodology
Let's quickly review the key differences between the most popular work methodologies:
Waterfall: all the documentation is done in advance, including user stories, wireframes, mockups, and all the features’ variations and outcomes. The majority of the research is done upfront, estimates of the time needed for each requirement are more accurate, and this can provide a more predictable release date
Agile: it requires less upfront documentation and planning. Features are planned along the way in a more collaborative way, including frequent reviews by the stakeholders. Changes that come further down in the process are less time-consuming, painful, and costly than with waterfall. On the other hand, the release date is more ambiguous. It can also include Kanban and Scrum methodologies
Shape Up: it doesn't use daily stand-ups, sprints, or backlog. Time frames are called appetites, which are capped at 6 weeks and projects can not roll over to the next cycle. Like Agile, the scope is flexible to a certain extent
If you've been around for long enough in this industry, you have probably started your career using waterfall, then moved to Agile at some point, and after a few years, realized that there is still something missing. Perhaps Shape Up could be the answer for that missing piece in Agile. Read more about Shape Up.
At TableCheck, we have mostly Agile squads, although we are also in the early stage of exploring Shape Up. For now, these quotes from Mike Schutte and the Work is like a hill concept are something to keep in mind:
Instead of picking a direction as fast as possible and getting there as fast as possible, Shape Up encourages you to think carefully about the direction you’re going. To think critically about how you’re going to get there.
Instead of asking “how long will this take?”, you ask “how long are we willing to spend on this problem?”. The result of the latter perspective yields, I’d argue, more innovation.
Every product, team, timeframe, and requirement is different. There's no magic formula that can work for every case. Nonetheless, there are certain frameworks and work methodologies that allow more space for creativity and innovation than others. If you feel that the way your team works is not allowing you to give your full potential, then I'd suggest you have a chat with your peers and find a solution.
Whether your team uses one methodology or another it doesn't change the goal, which is to build software. At the end of the day, the team has to choose the approach that works better for them.
The ideal lifecycle of a product
Like Steve Jobs once said, and recently Addy Osmani reminded us:
You've got to start with the customer experience and work backward to the technology. You can’t start with the technology and then try to figure out where to sell it.
The best software is built by engineers who have empathy for their users.
The message here is clear: Focus on the user and the rest will follow.
If we were to start a new product today, the product and design track should be the first to focus on. The engineering track could also start at the same time to prepare the groundwork, but at some point, to start coding the real features, it would require the deliverables from the design team to start implementing them.
Product & Design track
Objectives / business discovery:
Project vision and objectives. What outcome do we want to obtain?
Business objectives and workflows
Measurement framework. Make sure analytics are in place
Team roles and stakeholders mapping
Project scopes
Spec writing: product spec. and functional spec
Prioritizing product features and capabilities to ship
Define core users and conduct interviews if needed
Define a list of focus areas
Package the requirements as sprints/projects/epics for design to work on
Sprint planning/milestones
User personas: qualitative and quantitative research by survey and by interview
Use cases/user flow
Existing user journeys and opportunities
Empathy map
Competitors and landscape analysis
Design then takes all the insights from the discovery work to start ideation, prototyping, and usability testing
Ideation:
Experience principles
UX trends/user behavior
Design scope writing and LOE (MoSCoW method)
Design sprint planning - what areas to start with first
IA and templates
Initial designs/wireframes
Usability testing:
Create non-code prototypes for testing with Figma or Maze
Conduct user testing of the mock-up and analysis result/reporting
Learn and iterate the design. Finalize test
Design Production:
Design annotation (if needed)
Package up assets for all variations
UI library - update the Design System
Engineering track
Gather the requirements from the stakeholders
Study the technical feasibility of the product
Decide the tech stack:
Front-end, back-end, and infrastructure architecture proposals
Code and discuss with the team any required POCs
Research required 3rd party solutions like CMS or analytics
Project management and scaffolding:
Setup all tech systems, infrastructure, and resources
Setup the initial project processes and work methodologies
Assign areas of responsibility to team members
Study the domain and document it
Gather required documentation from external dependencies, like APIs or legacy systems
Write flow diagrams for the complex journeys
Set the project goals (from a tech perspective)
Build a coded clickable prototype
Start with empty routes. Focus on the navigation first
Continue implementing the core journey / happy path
Avoid premature optimizations. Focus on simplicity at first
Set up the required backend
Create a database and a CRUD API (if needed)
Implement user authentication (if needed)
Systems to handle sensitive details like payment info
Deployment and release
Setup the staging, pilot, and production environments
Setup the CI deployment pipelines and the semantic release process
Test releasing to all environments as soon as possible
Setup the testing approach
Create a testing strategy together with the QA team
Have a single source of truth for integration and E2E tests
Once all the previous tasks in both tracks are completed, the project enters a development phase that can last from a few weeks to a few months or even more than a year. It depends on the number of features required to build the MVP. The important part of this phase is to avoid scope creep and drastic changes in the design or the tech architecture. If the initial work was done properly (with enough research and user feedback), there shouldn't be a need to change anything major.
After the MVP
Once the MVP is released into production, the project enters a new phase where the target should be to gather user feedback (from user testing sessions, early users, support tickets, etc) to prioritize the features and changes that need to be done next.
At this point, the team should be very familiar with the domain and the codebase. The focus should be to keep releasing new features, fixing bugs, maintaining the documentation, and optimizing the product quality in general.
Before the official launch
Once the product reaches a certain maturity (after the beta and release candidate versions), the team should be ready to launch an official version. Before launching, it might be necessary to prepare the following:
An onboarding experience
A pricing model
All the legal policies
Support documentation for end-users (mostly FAQs)
A process to handle user inquiries
A process to notify users about changes in the product
A marketing campaign (website & SM channels) to promote the launch and track its performance
When the product is officially launched, the course of action can vary depending on the company's strategy and the market response. In any case, the team is expected to continue releasing new versions to increase its market fit and user base. Going forward, there are a few considerations to bear in mind:
Plan large releases into lower-risk well-understood rollouts
Resolve new issues systematically and rigorously
Any considerable change in the product should have a design doc or RFC
Maintain kind and professional communication with your clients and take their feedback seriously
Remember that you can't please everyone - be extremely mindful when saying "yes" vs "no". Any change request should be taken very objectively. Otherwise, if changes are not well planned, the product IA and UX can be damaged
Sharing the lessons learned
Another usual activity after a product is officially launched is to share the lessons learned with the rest of your organization or even publicly, for example as an article on the company website. This can have several benefits for your audience:
Understand the challenges your team had to overcome
Learn which mistakes not to make again
Discover new techniques, processes, or approaches to doing things
Attract new talent and increase the SEO
Alternatively, if writing is not your forte, you can always do a workshop, brown bag, or presentation. The goal is the same: to share knowledge, get ideas, and keep improving together.
Conclusions
Building software can be a very intense activity but also highly rewarding, as you can make an impact in people's life. Like any other creative activity, it takes a lot of practice to refine the techniques and processes. But eventually, everyone that has been doing it long enough, starts to understand the patterns and the sensitive areas that need special attention.
Either way, if I had to choose a single aspect that could define the success of a product, I'd say that would be the determination and passion of the individuals on the team. No matter what is the methodology, the technologies, or the resources, if the team is motivated and excited with the product, that energy will overcome any obstacles. Therefore, the advice would be to choose carefully your team and make sure they are truly inspired to make something exceptional.
If you are interested to work in exciting projects, making an impact in the world and you like food, chefs, cool restaurants, and the hospitality world in general, go ahead and check out our careers page. We are looking forward to meeting you!
The following people made contributions to this blog post: Yandis Ying, Tia Pashentsava, Tuesday Gutierrez, Richard McCracken, Wahid Farid, and Calvin Leung.
About the Author
Joan is TableCheck's Front-end Engineering Manager. He specializes in building user-centered, usable, and easy-to-maintain apps and websites for diners and merchants. He is also an evangelist of TableKit (TableCheck's Design System)
Join us
We are on a mission to reimagine the future of hospitality. Working at TableCheck means becoming part of a team of passionate and driven people with one goal: to help restaurants connect with their diners