Nugg Team Communication App


Nugg was a communication app to help teams stay in sync, uncover important issues, and stay energized and engaged with each other. It had a unique set of features: twitter-style messaging combined with a question and answer format, a special-sauce algorithm for bubbling important issues to the top, and a team energy-and-engagement score. 

When I arrived at the company, they had built a proof of concept, and were looking for a Product Team Lead to take these objectives and features and craft a product vision and user experience that would harness them across web and mobile.


140 character messaging combined with a question and answer format


Algorithm for bubbling important issues to the top


A measurement of the energy & engagement of a team, dubbed the "Nugg Score"

The Challenge

Although Nugg was already an alpha product when I came aboard, I recognized that very little user research or validation had been done. So the initial question I set out to answer was "Is there any appetite for this product?" I started at the beginning and validated it's key ideas and features with potential users. There were also a host of design and other problems that needed attention, like:

  • How to describe Nugg's idiosyncratic value proposition to users?
  • What is the most effective way to design the messaging stream?
  • How do we on-board teams quickly and set them up with the right questions?

Initial Research

My initial research consisted of user interviews with our target market to uncover patterns about the kinds of teams they were on and how they communicated with them. I also conducted a heuristic analysis of the existing early design. Also, to compare the differences and similarities between other team communication apps, I did a domain modelling exercise with 6 of them.

Through user interviews, I found that the problem of "staying in sync with my team" was a real one, but there was mixed alignment with some of the solutions Nugg was proposing. The idea of bubbling important content to the top showed promise across the board. A "score" for measuring team dynamics was potentially useful for hierarchical teams but not necessarily for flat ones. And the question-and-answer format resonated with scrum teams but not others. I conveyed my findings back to the leadership team.


Heuristic analysis indicated that the alpha version of the app had poor usability. Some ad hoc user tests underscored this.


Ideate & Design

Just like Twitter, the stream was the main user interface for Nugg. I spent time ideating and weighing different options for how nuggs (140-character messages) would be presented. Part of the challenge was that each nugg was an answer to a question, so that bit of context was important. And since team members could reply to each other's nuggs, the original message was a second piece of context for those replies. Initially, I tried hash tags to make the questions less repetitive and more compact.


I produced flows & wireframes for every use case and scenario. Below is depicted team creation, team editing, and filtering the stream. These were regular tested with users using paper prototypes.


Specification for micro-interactions with nuggs. Actions available were acknowledging (or "got it"), commenting, flagging a nugg as important, and opening a nugg to see the activity around it.


The alpha version of the UI was finally upgraded to the beta version below. At this point I was ready to perform a larger scale formal usability test.








Due to Nugg's idiosyncratic feature set, I felt we needed to try extra hard to clearly communicate what Nugg was about. For website visitors, I proposed a fun video that used sketches to describe our value proposition. Below are some concept drawings for the video. This idea was later dropped in favor of marketing copy.


Prototype & Test

I recruited 15 users from our target market and conducted formal usability testing and short user interviews. I gave them a set of tasks to perform. Metrics were task success, time on task and satisfaction.

Some key findings from these tests:

  • The product's unique mix of features created a barrier to adoption, because it made Nugg difficult to explain to our audience. After reviewing the website, users could not easily describe Nugg back to me. I put together a "best-of" audio reel to show these responses to the team. 
  • Representing questions with hashtags wasn't intuitive.
  • The interface felt immature and unstable.
  • Hard to follow conversations.
  • Providing presets for questions greatly expedited on-boarding.



Testing suggested that the design of nuggs needed work. I iterated through many variations.



Nugg was launched for iOS and Android devices. It was also available online as a web app.



Nugg garnered hundreds of users and enjoyed some early successes, but was not widely adopted, and the team pivoted to a new product idea called TeamFit. So why wasn't Nugg a success? 

  • Too prescriptive. The app had a very prescriptive idea of what team communication should look like. Each update had to answer a set question. Each had to be no more than 140 characters. Highly successful team apps like Slack are less opinionated and more flexible –  team members decide the content and length of their messages to one another. These idiosyncratic qualities generated the highest friction and were the most difficult for users to grasp. I learned that the best way to build a successful product was to start from the user and work backwards.
  • Short runway. Eventually we burned through most of our investment, and given our limited success, the leadership team decided to try a pivot instead of press on. If we'd had more time, we may have been able to course-correct.