This is the fourth installment in our series of Grand Design Challenges for 2025. You can read part 1, part 2, and part 3 here. Check back later this week for the final post.
Technical Problem Spaces
Designing with technology is ubiquitous to the point we just call it design. Designing for technology is a grand challenge. When designing with technology, technology is a material used to create a thing, service, or product for some subject domain or problem space. A comparative analogy is designing a chair using wood, plastic, or metal as the materials. For digital products and experiences, computers, programming languages, solution architectures, and application frameworks are the material. When designing with technology the focus is on the subject domain and problem space, not the material. When designing for technology, the material is the subject matter.
Products for technology accelerate the advancement of a technology or improve the efficiency of working with the technology. They are tools for scientists, technical researchers, software developers, designers, technicians, and operators. Better designed tools and workflows in technical domains are catalysts for innovation. Products for technology are necessary to make the target technology robust and stable. Products for technology make the technology market-ready and solution-ready so that the technology can be used to create products and services for other subject domains and problem spaces – so that technology becomes a material to make other things with.
Products for technology are complex and pose unique challenges. The good news is that existing design processes, techniques, and patterns apply. Software developers, data scientists, and quantum engineers (all exemplar of needing better tools) have the exact needs as any other user. Like other users, they too have difficulty expressing their wants, needs, and workflows, but they have an additional imposition – they will conflate their deep understanding of the technology with knowing the best UX and UI for working with that technology. They can be suspicious of the design process and reluctant to fully commit to it. They have a cognitive bias towards their existing (often self-made) tools while neglecting to realize how arduous, highly inefficient their multi-step process is. They can find it difficult to see how things could possibly be improved and are resigned to “this is just how it works.”
The other challenge is the subject matter. Suppose you are designing tools for GPU profiling, quantum computers, or machine learning data pipelines, which are deeply technical and complex subject domains. Designers must understand how the underlying technology or developer APIs work to create great products. Product discovery and design for technology-focused products are considerably more complex than enterprise apps and orders of magnitude more complicated than consumer apps.
Focal Points:
- How do deep technology teams become aware of the benefits of engaging designers and trust that working with designers to create better tooling or early in productization?
- How can we support designers understanding enough (however that may be defined) of a technology to design for it without having to have a deep technical understanding of the technology? It is excessive to force or require designers to have the same technical acumen as technologists – we want to keep designers extraordinary in design.
- How can designers be encouraged to learn more about the “material” of their craft and grow their understanding of the technology that makes their designs a reality?
- Beyond the subject matter, working with technologists, engineers, and scientists is challenging due to their personalities and perspectives – it is much different than executives and general users. How can designers adjust to working with the unique personalities and social demands of deep technology needed to guide them through the design process?
