Success Path
Everything you need to implement IoT for remote monitoring

Draft Designs for ThingWorx Applications

To design ThingWorx applications to connect and monitor your products, first learn about your users' needs. Research what data is most important and how users will interact with the applications. Then sketch a first draft. 

Gather UX requirements for ThingWorx applications

User experience (UX) requirements will help you understand how users will interact with your ThingWorx applications. They define what an application will look like and how the user interface (UI) will work. We recommend that a solution architect and UX/UI designer work together. 

To gather UX requirements, do research by talking with experts in your organization. Also, find out who your users are. Talk to the people who will use the data from the application. Find out what data is most important to them and how they’ll search for it in the application. Document this research. 

There is not a single way to document UX requirements. Yet, different requirements will result in different UI designs. Requirements may also affect the performance and security of the application.  

The research for your UX requirements should answer the following:

  • Who will use the ThingWorx application?
    • What language(s) do they speak?
    • Users may include people in your organization and customers, but have varied roles.
  • What will they use the application for?
  • What data is most important to users? Relate this to your business use case(s). 
    • Data styles may include actionable, informational, historical, and payload data.
      • What type of data is collected informs how ThingWorx processes this data and how to display it.
    • What kind of data displays will be most useful?
    • What data can be collected from the edge that will help meet use cases? 
  • How will users interact with edge devices? Are they only viewing data or also causing interactions with the devices? Interactions may include:
    • Remote sessions
    • Software content management
    • Executing applications or scripts at the edge
    • Requesting file uploads or downloads
  • How will users go looking for information? For example, will they type in a search field, use a drill down menu, navigate a tree-type hierarchy, etc.?
  • Does information have to be aggregated for a set of assets?
  • Do you need to generate any reports for the larger asset or is data more important relative to a single asset? 
  • What levels of visibility and permissions will different users need?
  • What metadata around assets need to be captured?   
    • Organizational-type information such as owner and manufacturer of the device 
    • Regional information such as region, country, location, address, and geolocation (does it move or is its location static?)
    • List of contacts regarding the asset
    • Other grouping of Things such as product lines
  • Do you have plans to increase the number of products connected over time?
  • Will the kinds of data that you’re monitoring change over time?
  • What security requirements will affect the user experience and/or the UI design?
  • What alerts will the application have and how will users interact with them?
    • What happens after an alert goes off? 
    • What processes might the users need to follow afterwards?
  • What other systems may be in the ecosystem that would be valuable to integrate with?
  • Required administrative mashups in addition to viewing/interacting with edge devices:
    • User management
    • Asset management 

Recommended Resources

Define ThingWorx user groups

Once you document UX requirements, next define user groups. This will clarify what different types of users can see and do in the application. For example, one person may need to look at data but will never make changes in the application. Another person may need full access. These two types of users are in different user groups. 

Document the visibility (what they can see) and permissions (what they can do) for each type of user. Be as accurate as you can. If users have too much access, they could see confidential data they should not have. If users have too little access, they may not be able to see the data they need. 

In ThingWorx Composer, you’ll create groupings at 3 levels: 

  1. Organization 
  2. Organizational unit 
  3. User group 

Different user roles drive what different types of permissions need to be given. For visibility, is it based on a Thing’s organization, location, region, product lines, or other attributes. A user role is an intersection of visibility and permissions. For instance, a user role could be a support engineer (run time permission) for eastern Europe (visibility). Make sure that your user groups and organization units are scalable. 

There are 3 forms of permissions you can adjust: 

  • Visibility permissions state what Mashups and/or dashboards a user can see. Assign visibility permissions at an organization or organizational unit level. 
  • Run-time permissions state what services a user can execute and what properties they can access. Assign run-time permissions at the user group level. 
  • Design-time permissions state what a user can modify and access in Composer. Assign design-time permissions at the user group level. 

ThingWorx offers built-in user groups for administrators, developers, and users. Depending on your needs, these may be enough to start with. You can set up more user groups, invite users, and make changes to visibility and permissions later. 

Recommended Resources

Create first draft of the UI

Design a wireframe, or a first draft, of the user interface (UI) of your ThingWorx application. The goal of the UI is to make it easy for users to get the information they need when they need it. 

A wireframe is a low-fidelity, early-stage design. It provides direction to the developers who will build the application. It also shows how users interact with the application. A wireframe often contains a grid of empty boxes that represent elements on a screen. To make a wireframe, you can use a tool like Balsamiq or Axure or draw it by hand. 

Focus on what is most important for functionality. Look back on requirements and user research. Instead of filling up the screen with widgets, we recommend that you leave blank space. The fewer elements users see, the easier the application will be for them to learn and use. 

In your wireframe, include the following: 

  • Elements on the screen 
    • Use empty boxes to represent the navigation, titles and labels, blocks of text, graphs, images, buttons, etc. 
  • Priority and relationships 
    • Arrange and connect elements to reveal which items are most important. 
  • Interactions 
    • For interactive elements, note how elements respond when a user clicks or taps on it. 
  • Flow 
    • Outline which screen leads to the next if there are many. 
    • Show whether the application delivers alerts. 
  • Preliminary copy 
    • Include words in your design that convey what each element is and does. For example, a heading may say “battery life,” or a button may read “view all machines.” Words can change later in the design process. 

Do not include colors, images, or other styling choices. You’ll make those decisions later.  

Remember that wireframes change and evolve over time. Later, you’ll review, test, and improve upon your early-stage design. 


Did you find this helpful?


Product Documentation

Find step-by-step instructions and information about using the ThingWorx Platform and ThingWorx applications in the Help Centers.

Ask the Community

Visit the PTC IoT Community to get product assistance, share ideas, and browse information about using ThingWorx.

Technical Support

Log a case with eSupport using your Service Contract Number. Don’t have it? Ask the Community.

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.