3.0 Preview.png

Technology Teaser Case Study

Technology Teaser



Our client has some amazing technology that uses auto-CAD files to produce augmented reality interactions. They want to put it into the hands of their favorite customers and business partners as a demo at an upcoming conference, and they really need it to sell the concept. Getting enough excitement around it will increase demand for a complete development IDE further down the road.

 The AR part was great, but it was hard to demo.

 The AR part was great, but it was hard to demo.

maxresdefault copy.jpg


This isn't a new problem, wanting to sell the sizzle for something that's technically hard to follow. Our client requires proprietary 3D files that not everyone has available. The initial use cases don't have a lot of real-world value. We think there's going to be a broad range of proficiency in their users with 3D modeling applications.

How might we deliver an approachable and memorable experience with their platform that makes the potential value obvious and desirable?




Fortunately, there is a starting point. Some eager professionals on the client's team sent us these rough wires in balsamiq. They give us a good idea of the flow they're expecting and show a bunch of ideas that we think can really work.

Starting inputs from balsamiq

Starting inputs from balsamiq


Now can we break these down into smaller interactions and components? Let's see if they mask any critical assumptions that this design approach includes. This is where we end up with more questions than anything else, but it's critical that we understand the "why" around what we're looking at.

  1. Is the manual placement of sensors somehow useful or helpful?
  2. What drove the decision to make a difference between real products / virtual only ones?
  3. Can we eliminate this choice and present it as an option instead?
  4. How is the visualization of the sensors important?
  5. Does it set the expectation about the operational visualizations?
  6. Aren’t they going to be virtual in their readouts?
  7. What are the actual capabilities of the sensors envisioned?
  8. How is customization of size / color going to be used?

Going forward, our client will be assured that we understand their business decisions enough to speak their language about the value of each feature. They also should have enough confidence that we'll be able to answer any "why" they choose to throw at us.




Speed is an issue here, and we're at risk of producing something that can't be built because the development team isn't accessible right away. Let's start with some wires that prioritize some of those risky assumptions in the first design, and dramatically simplify the flow for our most basic users.




The roughly designed wires prompted some great feedback and got us enough feedback that the visual design team is confident in moving forward with a more refined design presentation.


The design looks great, but we still need a thorough picture of the edge cases that come up when users take all the different paths available in this design. It's a good level of detail, but some technical flow diagrams may be just the visualization we need to clarify what should happen and when. It's time to go back to the wires, and produce some detailed technical user interface documentation.

Our client is really pleased with the final results and how well the experience presents itself, but isn't sure if it will be built as originally planned. The strategy for conference content has changed during the past week and there's concern this project may not make the cut. They do think there is other work in our future, based on how well this project went.

  • Client: PTC, ThingWorx
  • Skills: Wire-framing, Lean UX, Presenting Design, User Flows, Detailed Design Specifications
  • Tools: Axure RP, Sketch, InVision