Everything you need to implement ThingWorx Navigate for PLM data

Design the App

Learn to design and develop in ThingWorx. Gather requirements to inform the design of your custom app. Then sketch the first draft to test the design with users.

If you're implementing out-of-the-box apps, skip these tasks. You'll tailor the apps to user needs later.

Before you begin, complete these steps:

01. Prepare to design and develop in ThingWorx

To build a custom app for ThingWorx Navigate, take the time to learn to design for and develop in ThingWorx. This will help you gather essential requirements. It will also help you learn what's possible in ThingWorx.

For a smooth design process, you'll need knowledge and skills in:

  • User experience (UX) principles
  • User interface (UI) design
  • ThingWorx development, including using ThingWorx Composer to create Mashups

One person may have these skills, or they could be shared among several. If your company does not have these skills readily available, work with PTC or an experienced partner. PTC offers services and training courses to help. For example, the service "Execute ThingWorx Navigate Design Workshop" (listed in the services below) will help you determine how your app should look and operate based on your UX requirements.

Training courses are available from PTC University. Some may have prerequisites. To determine which courses best meet your needs, speak with a Training Advisor.

Here are a few courses we recommend:

Recommended Resources

02. Gather UX requirements

User experience (UX) requirements help you understand how users will interact with your app, what the app looks like, and how the user interface (UI) works. We recommend that an IT lead and UX/UI designer work together to gather requirements. If you do not have access to these skill sets, PTC offers the "Execute ThingWorx Navigate Design Workshop" linked in the services below.

To gather UX requirements, start by interviewing your users. Users are the people who will use the data from the app. Explain the business use case and ask them what data is most important to help them meet that goal. Ask users how they'll search for information in the app. It may be helpful to ask them to demonstrate their current workflow.

As you gather UX requirements, your research should answer the following:

  • Who will use the app?
  • What languages do users speak?
  • What will they use the app for?
  • What devices will they use?
  • Are there existing styles or colors to adhere to?
  • What data is most important? How often does it need to refresh?
  • What systems or devices need to connect or where is data coming from?
  • What actions do users need to be able to take?
  • 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.?
  • Do users need to generate any reports?
  • Will the app have alerts? If so, how will users interact with alerts?
  • What levels of visibility and permissions will different users need?
  • What other security requirements will affect the user experience or the UI?

As you research, document your findings to form UX requirements. You'll refer to your requirements as you create and iterate on the UI.

03. Write user stories

Write user stories before you create an initial design. For this purpose, a user story describes what a user’s goal is in the app based on their role or job.

You'll need the user stories to design the flow of the app. They will help you determine whether the design meets user needs and will be useful when you test your design. Write stories for the various jobs identified in your UX requirements so that your app is inclusive of many needs. 

Format user stories like this:

As a [person in a role], I want to [take an action or find something out] so that [desired outcome].

Example:

As a manager, I want to find production data from the last fiscal year so that I can find out if we are on track this year.

User stories should align with your use case and be real-world scenarios. Document the user stories and include them in your UX requirements. 

04. Create UI designs

Next, create your initial designs. Review your UX requirements and the business use case to lay out a sitemap or navigation for the app. A sitemap is a diagram that shows the organization of the app and what's included. It helps you establish a hierarchy of elements and get an understanding of your ideal user flow. Use the sitemap to show how things are organized and labeled.

Once you've created a sitemap, design wireframes. These are your first drafts of the user interface (UI) of the app. A wireframe is a low-fidelity, early-stage design. It 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.

Wireframes provide direction to the developers who will build the app. They also show how users interact with the app. You will be able to use wireframes to test the design with users later.

Focus on what is most important for functionality. The goal of the UI is to make it easy for users to get the information they need when they need it. Look back on UX requirements, user stories, and the business use case. Instead of filling up the screen with widgets, we recommend that you leave blank space. The fewer elements users see, the easier the app will be for them to learn and use. Focus on the user flow and user interactions with the elements. Do not spend time on colors, images, or other styling choices yet. You'll make those decisions later.

In your wireframe, include the following:

  • Elements on the screen
    • Use boxes to represent the navigation, titles and labels, blocks of text, tables, 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 is more than one.
    • 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." You can update words throughout the design process.

As you design, you'll create a sitemap and wireframes. You should also end up with a design document that outlines your design. Keep the design document up to date as you go through design iterations and development.

05. Review and iterate designs with users

Once you have wireframes that meet the business use case, you're ready to test them. Go through your user stories first. How do the wireframes perform against the user stories? Make any changes to your wireframes to solve issues that you notice.

Then test the wireframes with real users. Choose a small group of key users to review your wireframes. The key users should have a stake in the success of the app and are part of the main audience for the use case. Get their feedback and evaluate whether the UI is easy to follow.

What you're looking for:

  • The UI includes every element it needs to
  • The UI is intuitive, easy to understand, actions are easy to take
  • The UI looks and feels the way users want it to
  • The app does what is expected
  • The user flow meets the business use case
  • The UI leads users to their desired outcome (that meets the business use case)

If you need to make changes to the UI, update the wireframes and test with users again. This is a fluid, iterative process. You should feel comfortable making rapid changes and responding to feedback.

You can consider your UI design ready for development when you've met your UX requirements, it aligns with your business use case, and users verify that it meets their needs. Update your design document with any changes so that it's prepared for the developers to use later.

Did you find this helpful?

ADDITIONAL RESOURCES

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.

}