To build a high-quality, impactful product, we need to follow a structured design process. This involves conducting research, designing functionality, building the user interface and backend system, then refining the product through post-launch iteration.
I've divided this post into seven parts: design stages, stage snapshots, design system, design thinking time, quality matters, selective design, and team. First up, design stages.
Design stages
We can divide the design process into two phases – pre-launch and post-launch, each containing a number of stages:
Pre-launch
The pre-launch phase begins with research, which shapes the functional design. From there, team members can work on the presentation and system layers in parallel. Team members can at any time return to the research stage, and the functional design can be refined at any point in the process.
Post-launch
The aim of the post-launch phase is to iterate on the product – fixing bugs, running experiments, conducting usability tests, improving the codebase, and adding or refining features. These activities can happen in any order, depending on what the product needs at the time.
Stage snapshots
A stage snapshot captures key metrics at a specific point in a project, such as time spent, money used, or code developed. Snapshots can track progress for the whole project or for individual sections.
Comparing snapshots over time allows for tracking progress and identifying areas that need improvement. Example snapshot:
Post-launch phase percentages will increase over time if the team has the drive, incentives, and resources to refine the product. Both launch quality and functional completeness determine the level of post-launch improvement needed.
Stage activities
We can track activities within each stage – for instance, metrics for usability testing, surveys, presentation layer, system layer, and other incremental redesign tasks.
Design system
A design system is a comprehensive set of guidelines, principles, and assets, that help maintain consistency and efficiency in the design and development of the product.
It provides a unified framework for creating a cohesive and user-friendly experience across different platforms and devices. A design system could include the following:
- Design principles
- Colour palette
- Typography
- Iconography
- UI components
- Layout grid
- Spacing and sizing
- Imagery and illustrations
- Design patterns
- Interactions and animations
- Accessibility guidelines
- Voice and tone
- Documentation
- Code components
- Testing guidelines
- Version control
- Governance and ownership
- Training materials
- Onboarding materials
- Real-world examples
- Feedback mechanisms
- Brand guidelines
- UX patterns
- Content guidelines
- Browser support
- Screen sizes
- Style guides
- ...
We start building the design system after enough design work has been done to establish clear patterns. We can make adjustments as the project progresses. The system is delivered through a dedicated website or intranet.
Style guides
A style guide provides clear guidelines on how things should look, read, or be structured so that everyone creates work in a consistent and predictable way. We have multiple style guides: visual, content, HTML, CSS, Javascript, Python, Rust, and C++.
Design thinking time
I define 'Design thinking time (DTT)' as the time spent evaluating and making user interface and code design decisions throughout a project. The functional design stage provides a starting point.
Thinking about the design also happens whilst engaging in non-work activities. I often get new ideas whilst running. Recording voice notes on a watch is very useful.
UI iterations
The user interface can undergo many changes throughout the development and post-launch phases. Putting the UI on the screen and interacting with it often uncovers new ideas and unforeseen issues.
Low-fidelity artefacts such as sketches and wireframes lack detail. Many UI decisions, such as interactions, usability, accessibility, layout, sizing, aesthetics, and animation, have to be made and refined whilst building and interacting with the interface.
Functional design quality
The quality of the functional design influences how much refinement is needed during the development phase. This quality is influenced by numerous factors, including the depth and quality of research, the skill and domain experience of the designers, effectiveness of collaboration, time invested, number of iterations, and the level of detail produced.
Code design
A great deal of thought goes into designing the codebase. This includes defining the architecture, keeping the system simple and maintainable, naming things, writing secure code, optimising performance, writing comments, coding standards, and more.
DTT per role
The amount of design thinking someone engages in, as well as what they consider and when, differs widely by role and by individual. Together with their skill and domain expertise, these differences shape each person's impact on product quality.
DTT per stage
Many "good ideas" and design refinements happen whilst working in the development stage – the presentation and system layers. To get a well-crafted product, you need the right people to be working in these areas. Example stage split:
phase
Much DTT and iteration can happen post-launch, including insights that arise when the development team uses the product.
DTT score
A "design thinking time" score can be calculated for each product section, where higher scores correspond to a higher chance of quality outcomes.
Each individual is assigned skill and role modifiers. Multiply by hours worked on that section (at any stage) to get an individual score. Tally the scores to get a product section score. For example, for a 'quiz' feature:
| Hours | Skill | Role | Score |
| 100 | 5x | 1x | 500 |
| 100 | 0.5x | 2x | 100 |
| 600 |
We can also ensure that certain high-skilled individuals spend a minimum amount of time on a section.
Baseline quality
The initial quality at launch serves as the baseline for future development, shaping the number, type, and impact of improvements that can be made post-launch.
Quality matters
Product quality matters for a number of reasons – staff attraction and retention, career needs, speed and cost, and ecosystem impact.
Staff attraction
If your company does not create high-quality impactful products, it will be difficult to attract highly-skilled designers and developers. They won't be fulfilled or believe in the product, achieve personal growth, and so on.
Staff retention
If the product isn't good, many staff won't feel motivated to work on it. No joy, fulfilment, purpose, learning, growth, yada, yada. These people will be looking for an exit.
Career needs
People have psychological needs such as belief in the mission, fulfilment, purpose, personal growth, sense of belonging, supportive culture, and learning. If the product is naff, many of those needs won't be met, and people leave.
If the founder(s)' needs aren't met, then you have no company – they will pursue other endeavours.
Speed and cost
A simple, quality codebase improves maintainability, readability, scalability, collaboration, testing, performance, security, and more. It enables developers to build faster and reduce costs.
Ecosystem impact
The better the product, the greater the ecosystem impact.
Source of funding
The source of funding can impact product quality. Expectations of rapid growth can lead to less time, resources, and motivation to build, maintain, and improve the product. This harms staff attraction and retention.
Imperfekt
The idea is to get a good baseline quality when launching new functionality. Post-launch activities can improve the quality of the UI, experience, and codebase. In most areas, there will always likely be things to improve.
Selective design
For larger projects, it's not possible to have the most skilled and experienced designers and developers do everything. So we must target key areas. The most skilled/experienced team members build the core and a selection of other functionality.
Aim to cover all the main UI patterns, user flows, and the more complex areas of functionality. Keep iterating until things are at an acceptable standard. Create and refine the design system. Fix issues early.
120 main sections
This project currently has 120 main sections – Account (8), System (19), and Project (93). The right people – myself and others – do the Account, System, and selected sections of the Project functionality.
Others
Once we have built and iterated the core areas and refined the design system, we can then bring in other people. We provide these folks with functional requirements and perhaps sketches and other design artefacts.
Shared functionality
Many sections share overlapping functionality. For example, once we've completed the 'Images' module, we've also completed much of the functionality for other modules. This involves copying code, renaming things, and using shared utility functions.
Device priority order
When designing for multiple devices, we design for the optimum experience first. For this project, that's a stationary device such as a mini PC connected to one or more large screens. All design thinking goes into creating the best possible experience for this hardware.
Once we have iterated the codebase and UI, we then create the code for smaller browser window sizes on that device. We then move onto other devices such as tablet, mobile, watch, and TV. We prioritise devices based on their expected usage popularity.
Feature detection
We use Javascript to detect device capabilities such as touchscreen, camera, Bluetooth, microphone, and GPS, and enable or disable features accordingly.
Team
To build a great product, we need a great team. I've grouped the product team into five role categories: research, functional design, presentation, system, and full stack. Let's go through each, summarising what they do and skills mix variations within each.
Research
Anything that requires research. Example activities include market research, competitive analysis, accessibility research, identifying user needs, discovery research, idea evaluation, usability testing, and benchmarking. They design studies, collect the data, and communicate insights.
We have one possible role title – UX researcher – with tiered seniority levels. UX researchers can support the development team at any stage of the product lifecycle.
Functional design
UX designers perform tasks related to how the product works from the user's perspective. Tasks include understanding users, designing user flows and task completion paths, usability testing, creating sketches and wireframes, contributing to design systems, and collaboration.
Presentation roles
UI designer: works on interactions and usability, ie how the product works and behaves on the screen. Functional interface design using UI design and prototyping tools.
Visual designer: aesthetics and branding, ie how the product looks. A visual designer can create mockups in design software.
Front-end developer: implementation of the design. HTML, CSS, and Javascript.
Combinations: an individual can perform one or multiple of these presentation roles, in addition to UX design, research, and system roles.
| Role | Skills |
| UI designer | UI |
| Visual designer | Visual – aesthetics, brand |
| Front-end developer | HTML, CSS, Javascript |
| UI/visual designer | UI, visual |
| Full-stack designer | UX, UI, visual |
| Design + front-end developer | UX, UI, visual, HTML, CSS, Javascript |
System roles
Database administrator (DBA): installation, configuration, performance monitoring and optimisation, backup and recovery, security and access control, data integrity and maintenance, troubleshooting and support, high availability and scalability, automation, and documentation.
Backend developer: database administration, server-side logic and business rules, APIs for frontend and other services, security, scaling, performance, AI (machine learning and non-ML) integration.
AI: machine learning (ML) and non-ML approaches.
| Role | Skills |
| Database administrator (DBA) | Database administration tasks |
| Back-end developer | Server-side code, database |
| AI engineer | Machine learning (ML), non-ML |
| ML engineer | Machine learning (ML) |
| Back-end/AI engineer | Server-side code, AI |
| Back-end/ML engineer | Server-side code, ML |
Presentation + system roles
Some folks, myself included, work on the entire stack. UX, UI, visual, front-end, and back-end development. This could also include research and AI engineering. Others do both front-end and back-end development.
| Role | Skills |
| Full-stack designer/developer | UX, UI, visual, FE, BE |
| Full-stack developer | Front-end and back-end dev |
Full-stack strategy
Ideally, our team would comprise of mostly full-stack individuals. We use specialists when we need skills that the full-stack team doesn't possess. We can train people up.
- Full-stack designer/developer
- Full-stack developer
- Full-stack designer
A full-stack approach offers a number of benefits: flexibility, redundancy, faster iteration and decision making, no collaboration overhead, efficiency, better team communication, fast experimentation, and can help with retention (job satisfaction, variety, growth).
Someone with broad knowledge brings integrated, holistic thinking. They see how things fit together and often generate ideas that specialists won't, thanks to cross-pollination across domains.
Skills matrix
We track each individual's skills across multiple areas. Employees self-assess, and the company also maintains its own evaluation. We also track skills within each area. No '10' score – always room for improvement. Examples:
| Name | Front-end | Back-end | UX | Visual |
| Rusty Boone | 8 | 7 | 7 | 6 |
| Skill | Rating (out of 9) |
| Logo design | 8 |
| Animation | 5 |
| Icon design | 6 |
| Typography | 6 |
| Branding | 6 |
| Design theory | 7 |
| Infographics | 6 |
Collaboration
Team members can communicate freely at any time – SMS, email, phone, Zoom, project management software, discussion software, and in-person. We collaborate with external experts whenever specialised or domain knowledge is required.
Skill
The ability to perform a task effectively, consistently, and to a certain standard, usually developed through practice, training, or experience. Example skills needed for designing and developing websites and apps:
- Ability to simplify
- Attention to detail
- Pattern recognition
- Critical thinking
- Holistic thinking
- Problem solving
- Intuition
- Inquisitive thinking
- Systems thinking
- Rapid decision making
- Efficient task execution
- Creative thinking
- Integrative thinking
- Judgement
- Growth mindset
- Self-reflection
Domain expertise
Domain knowledge includes insight into the challenges, requirements, workflows, user scenarios, and use cases relevant to a particular domain. Domain expertise = domain knowledge + skills + practical experience.
Greater skill and domain expertise generally produces more numerous, higher-quality, and more impactful insights.
Deliverables
Deliverables are any design outputs shared to convey ideas, guide development, or show progress. They vary in their level of detail and realism (fidelity), ie how close the design artefact is to the final product.
| Fidelity | Deliverables |
| Low-fidelity | Sketches, paper prototypes, basic wireframes |
| Mid-fidelity | More detailed wireframes, simple clickable prototypes |
| High-fidelity | Mockups, interactive prototypes |
As a full-stack designer/developer, you can just use sketches, unless you need to communicate the design to others. Sketch as you go. You have a list of functional requirements – sketch the interfaces, eg on plain A4 paper, as you build the functionality.
Specialist and full-stack designers will need to communicate their designs to others. The choice of fidelity depends on what you need to communicate, who you are communicating with, and how early or late you are in the design process.
Summary
To build a high-quality, impactful product, we need the right people doing the work – writing the code and making a large number of design decisions as the product is built. Sketches and wireframes are starting points.
The most skilled/experienced team members build the core and a selection of other functionality. Issues are ironed out, the UI and codebase are iterated, and the design system is created and refined.
The product quality at launch is a baseline. Post-launch activities such as bug fixing, usability testing, experimentation, and iterative redesign, can lead to significant improvements.