Build Your ThingWorx Solution for Manufacturing

  Download Success Path IMPORTANT: When saving the file, in the Print window please do the following:
Destination or Printer: select Save as PDF
More Settings: In the Options, be sure the boxes Headers and footers and Background graphics are selected.
Recommended Steps
Overview: Build Your ThingWorx Solution for Manufacturing

Draft Application Designs

Begin exploring what your Industrial IoT application should do and how users will interact with it. Then sketch a first draft of your application. Your goal is to ensure your application is useful, usable, and appealing.

01. Gather application requirements

Application requirements specify what your Industrial IoT application needs to do.

To maximize the usefulness of your application, explore what your end users (employees working in the plant) need from it. We recommend a software engineer, systems integrator, or product owner collaborate with a UX designer to conduct basic research. If you don’t have a UX designer, a developer typically fills this role.

Your research should answer questions like:

  • Who will be using the application?
  • What are their goals? What tasks must they accomplish?
  • What are their pain points and challenges in their daily jobs?
  • Who do they work with to accomplish important tasks?
  • How does their physical environment affect how they do their jobs?
  • What hardware will they be using for the app (desktop, mobile, tablet)?


If possible, visit the factory or environment in person to learn about your users. Observe them in their work setting and interview them about their needs. Aim to study a representative sample of users.

Your research should reveal a long list of requirements possibilities for your application. Prioritize which items are most relevant to solving the business problem specified in your use case.

02. Gather UX requirements

User Experience (UX) requirements specify how the user will interact with your IIoT application (interaction design).

Among other elements, the UX requirements will outline how the app displays information and how the user interface will function.

To gather your UX requirements, review your user research and imagine how those users will interact with your application. For example, if your end user is responsible for monitoring battery life on a set of machines, your UX requirements would answer questions like:

  • What’s the best way to display battery information? A progress bar, a percentage, or another visual representation may be the right choice.
  • Does the user need to be alerted when battery levels are too low?
  • After checking battery life, what will the user need to know or do next?
  • Does the plant manager need different information than the controls engineer?


There are a variety of ways to document UX requirements. Be sure to focus on who will be using the application, what they’re using it for, and the features and functionality that will meet their needs.

03. Create initial wireframes

Wireframes are low-fidelity, early stage designs. They provide direction for the developers building the application and convey how users will interact with it. Wireframes often contain a grid of empty boxes that represent elements on a screen. They’re typically designed using tools like Balsamiq or Axure, but they can also be hand-drawn.

Wireframes typically include:

  • Elements on the screen: These empty boxes represent the navigation, titles and labels, blocks of text, graphs, images, buttons, and more.
  • Priority and relationships: By arranging and connecting various elements, wireframes reveal which items are most important.
  • Interaction: For interactive elements, wireframes note how the element responds when the user clicks or taps on it.
  • Flow: If there are multiple screens, the flow outlines which leads to the next. If the application delivers alerts, wireframes will indicate this.
  • Preliminary copy: The words in the design will help convey what each element is and does. For example, a heading may say “battery life,” or a button may read “view all machines.” These words can change later in the design process.


Wireframes do not usually include colors, images, or other styling. Those aspects of the design will be decided later.

Depending on the hardware you’re using to run your Industrial IoT app—desktop computers, tablets, or other displays—you will have limited screen space. Instead of filling the screen with widgets, prioritize what’s most important and leave blank space. Review your requirements and user research to decide what’s most important. The fewer elements the user sees, the easier your application will be to learn and use.

Remember that your wireframes will change and evolve. Later in the project, you will review, test, and improve upon these early stage designs.

04. Design user groups

Now that you know how users will interact with the application, outline your user groups. User groups restrict what workers can see and do in the application. For example, a machine operator may need to view X, Y, and Z screens, but will never make changes to them. An administrator, on the other hand, should have full access to the application. Thus, these two types of users would belong to different user groups.

Review your list of potential users. Then determine which types of users should have permission to access which information within ThingWorx.

Keep in mind:

  • Balance permissions carefully. If you grant users too many permissions, they could see confidential data or mistakenly delete pieces of the application. If you grant users too few permissions, they may be unable to access an important screen.
  • In ThingWorx Composer, you will create groupings at three levels:
  1. Organization
  2. Organizational unit
  3. User group
  • There are three forms of permissions you can adjust:
  1. Visibility permissions dictate what Mashups and/or dashboards a user can see. Visibility permissions are assigned at an organization/organizational unit level.
  2. Run-time permissions dictate what services a user can execute and properties they can access. Run-time permissions are assigned at the user group level.
  3. Design-time permissions dictate what a user can modify/access in Composer. Design-time permissions are assigned at the user group level.
  • Adapt as needed. You will likely need to make changes to your user groups and permissions over time.

ThingWorx offers user groups for administrators, developers, and users: Depending on your needs, these user groups may be sufficient to start with. Later in the process, you will set up the appropriate groups and invite users to ThingWorx.

Recommended Resources

Did you find this helpful?


Previous Step

Manage Organizational Change and Compliance

Next Step

Document Your Integration and Connectivity Strategy

ADDITIONAL RESOURCES

Product Documentation Find detailed technical documentation on Creo+ in our Help Center
Ask the Community Visit PTC's Creo Community to get support Peer-to-Peer, from our product management and assistance teams. Share ideas, give feedback and browse the wealth of information on using Creo+
Technical Support Need help from our support team? Log a case with eSupport using our Case Logger or find an answer using our new Creo Admin Troubleshooter tool. 

Contact Us

Have a question? Submit your contact information and we’ll reach out within 1 business day. You’re never obligated to purchase or commit.
Get in Touch