I'm creating a mobile web application for debates. There is a public discussion between two people displayed on a "card", with buttons to tell the other person they made a good point, and to add a new reply. There are also tools related to the user's team, 'flag for importance', private comments, and tagging (text input tags, like Stack Exchange uses). There are probably more tools to come in the future.

I want to create a strong separation between the internal tools (just your team) and the external tools (seen by the other person in the convo). Obviously you wouldn't want to accidentally send a comment meant for your team to the other person. Below are three options I've come up with:

Three tool button configurations.

  1. The first one puts the external tools outside of the conversation, but sacrifices some screen width (in my more detailed mockups it is just 50px). It would be easy to make this work on desktop, and add more tools in the future.
  2. The second one puts the tools on the bottom of the conversation card to save width, but is close to the reply button and it might be more difficult to add tools in the future.
  3. This one places a "team" button in the upper right of the card, which brings up a menu when clicked with all the team tools. Not sure how I feel about hiding these tools behind a menu, because we want to encourage people to collaborate often.

So, am I approaching this problem in the right way?

  • What is the Yes !
    – Mervin
    May 15, 2013 at 17:02
  • 1
    "I agree" or "good point". There will be an icon, but that is the sentiment. May 15, 2013 at 17:06
  • How stable are feature sets for team-internal and public user actions? How often and how quickly should these actions be triggered? May 15, 2013 at 18:53
  • @DeerHunter It's important for the actions to be easy to trigger. As easy as it is to retweet/reply, you should be able to comment or tag. Features are expected to grow, but not immediately. Those three on probably going to be what we launch with. May 15, 2013 at 20:39

1 Answer 1


I think you need to segment public information from internal team information in two very different views. The more visual cues team participants can have, the better. Public comments should only be possible throough the public view and internal comments (or other tools) only on the team view. That woy your team participants always know where they are posting. You don't add cognitive load - you remove it.

Implement it with an easy flip button at the top saying "Switch View" combined with a header saying which view your currently at. Add different themes to different views which support the recall of which view is which. I would avoid internal team tools on public views if I could.


download bmml source – Wireframes created with Balsamiq Mockups

  • Instead of "Switch view", there should be a pointer ">Team" or "<Public", and switching should be done by swiping right/left. Just my 2 cents to make the other view discoverable. May 15, 2013 at 20:50
  • I really like the strong separation here, but the user might want to be looking at the public conversation when they leave a team comment. That was my reasoning for putting those tools in the same view. May 15, 2013 at 21:02
  • @catmealsnap This design doesn't constrain looking at posts from the public, but to comment publicly, you need to be in the public area - even if you're a team member. May 15, 2013 at 21:12
  • @DeerHunter I totally agree. The easier you make the switch, the better. Swipe, relabel, shake or even twist to landscape mode - whatever technique your users prefer you implement. May 15, 2013 at 21:15
  • @BennySkogberg maybe I am looking at this mockup wrong, but it appears to me that clicking the button changes the entire view, a la: ilovecolors.com.ar/wp-content/uploads/css-card-flip-webkit/… May 15, 2013 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.