Of describing and showing in product development

“I notice you don’t really understand what I’m talking about. Wait a minute, I’ll show you.” Often communication fails when people are forced to describe things instead of showing them. Because they are either out of reach or because they simply don’t exist in real life. Like products that are still in the development stage. That’s why designers are downright DIY experts. With a product idea in mind, they quickly build a prototype with cardboard and glue. In this way, they succeed in showing what is difficult to put into words. This is exactly what efficient product development processes need and can be achieved through deeper integration of 3D visualization functions into the PLM system.

A picture is worth a thousand words

The value added by images over pure text is something we take for granted these days in a multimedia world. On Instagram and elsewhere, text only underscores what has already been captured in the image. But how much of this self-evidence has arrived in the IT systems that support the work of manufacturing companies? In my perception, describing is still more important than showing: The majority of the screens contain characters, words, tables and sentences.

Since the spread of CAD systems, especially in PLM applications, there has been no shortage of images. Hardly any product is manufactured before it has been designed in advance as a (3D) image. The 3D model is a natural tool in product development and in times of increasing product individualization an ideal tool for communication around the product. From chairs to electric cars: across all industries, products can be individually configured online and viewed in 3D before they are ordered and produced.

Why does enterprise software still remain so text-heavy?

CAD software licenses are expensive. Companies therefore often only equip a few workstations with it. In addition, CAD software as proprietary file formats cannot be easily opened by other programs. Thus, access to 3D geometries remains limited to an exclusive club.

If this hurdle is overcome, for example with neutral 3D viewers, the question of how 3D geometry and text can best be combined with the operating UIs of the enterprise software still remains. Beyond the fanciful visions of the future concerning data handling with VR/AR à la Minority Report, there is still a lack of concepts in reality for combining information from 3D models and databases in a uniform operating pattern.

So, where do we go next?

The first step is to bring 3D geometries into the UI alongside the usual textual content. In addition to displaying and rotating, a basic function is the ability to navigate inside the model in order to view individual components in detail by selectively showing and hiding them. Functions such as entering, saving and sharing annotations on the 3D model are also helpful for effective communication within the team. Furthermore, additional Digital Mock Up (DMU) calculation functions can support certain decision-making processes. Such as a neighborhood search to analyze the impact of an engineering change. Or a model comparison to subsequently understand the scope of this change.

In the second step, geometric and textual information must be combined in the UI. This creates an integrated user interface that offers added value in terms of content. Moreover, how would it be if the 3D model in PLM applications no longer served as an illustration of the parts list but, conversely, the parts master data enriched the 3D geometries? Or if tables and textual hyperlinks are abolished and a real geometric or spatial navigation is available? Or if users can visually browse the parts inventory like in a warehouse instead of tracking down numbers in a list? Or, or, or.

We have become so accustomed to working with strings in information technology (I’m thinking of command lines, relational databases, hyperlinks and so on) that other operating patterns seem unthinkable. Here it is time to rethink and unleash the visual power of 3D geometry to communicate quickly and accurately in business processes.

In my German-language webcast on October 7, 2021, you will learn how to make 3D visualization and inspection functionality accessible to all PLM users throughout the product lifecycle and ensure seamless integration of geometric and PLM data – in one interface, without having to jump to expensive standalone viewers.

Time scheduling – The hammer of project management?

If you have only a hammer as a tool, you see a nail in every problem. Mark Twain is credited with the bon mot ” If you have only a hammer as a tool, you see a nail in every problem”. Even if it is not clear beyond doubt who is actually the author of this statement, it remains probably the most succinct formulation for “Maslow’s hammer“

So what does this have to do with project management?

When it comes to project management software, I often observe that users try to achieve a wide variety of goals with just one tool, namely scheduling. You can’t blame them, because many project management tools tempt users to do just that.

In the process, schedules are created from hundreds or thousands of daily tasks. It is not uncommon for me to also encounter tasks in question form, such as “Specification released?”, “Customer presentation done?” and so on, provided with duration, deadline and task links.

Over-detailed planning takes its revenge in the project

The dilemma: Such plans are only pseudo precise, with many detailed deadlines calculated from activity links. Although everyone involved actually knows that in larger projects no activity is completed to the day. Nevertheless, everyone pretends that the plan is exactly right.

Also, the practice of managing resource utilization by linking all the tasks of a particular person one after the other only works well until you have to change the planning. Then the whole scheduling structure is no longer right. But the scheduling tool continues to calculate the dates mercilessly according to the network plan. The more detailed the plan is, the more time-consuming it is to make changes in the course of the project. You move one task and many others move with it – but unfortunately not in the way you would have expected. You no longer understand your own, overly complicated network plan and require a great deal of rescheduling effort for new fake precision. Some people leave the plan unchanged and start improvising instead

Use the entire toolbox

Here it is obvious to think of agile approaches as an alternative. But you don’t necessarily have to change your project management completely. Many experienced project managers say: “Agile is nothing new. With me, it’s just not a task board, but a good old open points list.” And that’s exactly the key. Plan only as precisely as necessary and as really useful. The motto here is: Better good rough planning than poor detailed planning. Even if the rough plan probably doesn’t come in as thought, it’s much easier to correct and makes the impact on the project more readily apparent.

For detailed issues, a list of open items (LOP) with clearly defined responsibilities is the tool of choice. And for anything you want to schedule in question form, checklists that are reviewed regularly as the project progresses are helpful. If not met, put an action on your LOP. And perhaps you record and monitor risks and define countermeasures to take timely and effective countermeasures. This usually puts you in a much better position for a successful project.

So: Only use the hammer for nails. For everything else, feel free to pick up pliers, screwdriver or wrench!

Consistent UX in distributed product development

Enterprise software development is largely distributed. Solutions are built on a platform, but developed separately from it; the assembly of modules and their adaptation to customer requirements takes place downstream, in other locations. This means different teams, different departments, different companies are building something that is first a product for the customer.

Users expect software that is homogeneous , that reuses operating patterns, and that provides a consistent user experience. This is a major challenge when different departments, some of them distributed around the world, are involved and everyone participating in product development brings their own perspective to the table. As described in my previous article, a basic awareness of the topic of UX throughout the company is already a good prerequisite. How can we build on this and provide even more targeted support in terms of end-to-end UX?

UX influencing is key

Craig Villamor’s presentation “Resilient Enterprise Design” had a profound impact on my view of this challenge. Craig is a Design Director at Google and was previously responsible for the design of Salesforces software. In his presentation at the 2017 Enterprise UX Conference, he uses the four pillars of Design Principles, Platform Mindset, Design Systems, and Influencing in Product Development to show how successful UX design of resilient enterprise applications can succeed.

I would like to focus here on the last pillar, influencing. What is meant here is influencing all the players involved in product creation – at CONTACT, we call them “creators”. This support is also a central aspect of the UX strategy at CONTACT. But what does this look like in concrete terms?

Making it easy to do the right thing

It is not always a good idea to keep the design framework as large as possible: Too many design options can lead to uncontrolled growth and unnecessary inconsistencies. For example, fixed layouts for pages or control elements specify recognizable operating patterns. The manageable design options should then be explained as contextually as possible, in structures with which creators work directly – for example, right in the configuration interface. Such aids can be speaking titles and short descriptions for given layout areas, for example semantic sections in a context menu. In this way, creators can make the right decisions directly without having to go through the design documentation.

Support with the right resources

Good design documentation is also relevant: Design guidelines are the framework for design decisions in application development and configuration. It is important that they are not textbook-raised, but close to the creators’ problems. At best, the documentation for each UI component includes guidance on which use cases it is appropriate for – and which it is not. Examples show how the UI component is used correctly, for example in interaction with other UI elements.

Leading by example

Creators love examples in general: What can you do with this kit? What do possible solutions look like? CONTACT’s products offer an ever-growing number of specialized applications (Task Manager, Xbom Manager, Scheduler, Variant Management, etc.) that build on the InSync Design System and provide Creators with templates or inspiration for new solutions.

So if we provide distributed product stakeholders with guidance for design decisions, support with good application design resources and create lighthouse solutions for orientation, they can more easily create compelling products with a consistent user experience.