Wolfram Data Drop

One of the challenges associated with Internet of Things (IoT) was figuring out where to put all that data. If you have dozens of connected devices talking to the cloud you've got to think about where that data lives, how to normalize it and how to grant others access to it so that it becomes useful. To resolve this issue, Wolfram Research introduced Wolfram Data Drop and I was the Lead UX Designer for this service.


Ux questions to begin with:


  • Why:
    What was the purpose behind creating the Data Drop service?

  • How:
    What parts of the underlying technology would this service use? How much additional work would be needed if this service was built over the existing technical infrastructure?

  • What:
    What would be its primary and secondary features? Would these features satisfy all the user needs?

The Challenges


Underestimating the project
I was called midway through the project to give my 2 cents and fill in any loop holes that the stakeholders might have missed while discussing the project. The idea that the team implied, was that this will be a quick project for UX and a simple web-page with bit of documentation would help. UX identified various holes in the workflow which lead to blowing up project time-line.

Incomplete implementation of underlying technology
uring meeting with lead developers and other team members it was noticed that the underlying technology or the backbone of the project was still not complete. UX was left with assuming and imagining workflows which might not hold true. This created a communication/ideation problem that needed to be solved. One way to bypass this situation was to set expectation and focus on what should be the MVP.

Target audience vs Existing audience
Incomplete development, confusion over MVP also creates a situation where the business teams could not point towards the exact target audience. Multiple discussions about if the feature was going to be a standalone product or was it going to be an add-on service made it difficult for UX to come up with persona's and user stories.



Building the Product Timeline
As part of the UX process, I conducted thorough research on general market trends, performed competitive analysis to gain a better understanding of user expectations, and conducted user interviews to understand current processes and workflows. The information gathered here later served as building blocks for the creation of User stories and Workflows.
This also allowed me to come up with a genral time line to extimate the project and ask the stakeholders what would be the be the expected timeline's for each of the projects.

User Stories

User story suggested storing data collected from online animal tracking devices into Wolfram Data Drop through their Web API. User stories allowed to set the expectations and made sure that the understanding was correct. It also helped initiating conversation and brought out ideas from everyone. This helped negotiating the concept for an MVP.

End to end Workflow

The end to end workflow provided an overview of all the pages that the user might have to go through.


Using my prior research, I created a low fidelity mockup of what would possibly be the final design for the web app.This mockup was then reviewed by the team and stakeholders, and the next step was to iterate on the wireframe by incorporating the feedback. Several such review cycles and iterations happened before the final concept wireframe was created.


Quick mock ups

Reviewed Mock up

At this point the ball is in the stakeholder's court. While we are awaiting for the review and final OK for implementation, UX collaborates with mmarketing and other business teams lay out the structure of plans and pricing. User story's and persona's help with creating the initial layout. But they are not sufficient because eventually that is not real. Talking to real users, while doing competitive analysis gives information about how users would like to use the service and what would be right cost associated with them. Plans and pricing pages need to be constructed so that the process is seamless. This process is repeated again, until the MVP is ready.



Completing the UX process
The below diagram explains the UX process. Notice how a large part of UX effort goes into analysing the requirements and making sense out of them. After the analysis various techniques such as User stories, mind maps, empathy maps etc are used in order to ideate and create journeys that will replicate what the user goes through. But this is only half the work, laying out user interface, with proven techniques will help drive business goals. During this process, UX also essembles the analytics inorder to understand how the user is using the product. If everything goes well in this part, reviewing and testing is usually simple rundown of things.


Final UX

Final Design

Low fidelity wirefames helped us focus and nail down the essentials of the user interface. These wireframes were great to initiate conversation and gather feedback from the stakeholders because the were low fidelity, the turn around time was quicker and UX was able to produce a lot more in a small frame of time. Collecting feedback at crucial junctions helped UX to come up with what was the final version of the MVP. This wireframe was then sent to the Design team to create a more graphical mock up.

Data Drop mobile wireframe

Data Drop watch app concept

Data Drop watch app concept