The context: I am developing this application where users can discuss about and contribute with some documents. Can think of it like an easy Document Management System. The main background technology behind forwarding and discussing documents will be email, where discussions will be implemented with the body of emails, and contributions will be implemented with attachements.

The need: I am aiming to achieve these two targets:

  1. Somehow I feel that if I design the UI "email alike", the app wouldn't be encouraging enough to contributing, undevaluing this feature with respect to the other of discussing. In other words, contributing is, at least, as important as discussing.
  2. I don't want the users to remind of email technology neither when they discuss about a document nor when they provide a document.

The question: Does it make sense somehow, or otherwise is it just bad practice, to decouple the email function into those 2 UI features (discussing + contributing), as shown by these 2 wireframes for example?

They both launch the exact same procedure but I believe they encourage the user to overtake different actions...

enter image description here

  • Email is usually handled with an email client (Outlook, Google Mail, etc.) So the user wouldn't need a UI. However if you are creating a UI for an app that communicates via email server then the user shouldn't be concerned with the technology. Design with workflow in mind rather than technology. If either comment or document is necessary then it appears validation routines and clear app messaging is the primary focus. Use the UI to indicate how the user should contribute, avoid error messaging and let the user know what is going on.
    – Ken
    Commented Feb 23, 2015 at 17:50
  • Hi @Ken, yes as you mention, the app communicates via email server. From your comment, I get that I mainly could go for the concept showed in the image, carefully handling what you state: validation and clear app explanation. Thanks. Commented Feb 23, 2015 at 18:02
  • I think something got lost in translation. The verb "to contribute" means any kind of a participation in anything. It seems like you're talking about participating in a discussion with the ability to attach files with optional comments.
    – dnbrv
    Commented Feb 23, 2015 at 18:02
  • @dnbrv, the thing is that I wouldn't like the UI to feel to the users like "OK, I can send an email regarding this document that I am seeing". I'd better have them feel like "I'd like to comment this document" or "I'd like to forward this other document instead". It may be a subtle issue, but email look doesn't really fit what I intend to. Thanks for your comment. Commented Feb 23, 2015 at 18:10

1 Answer 1


I really like the idea! however I wouldn't decouple this into two UI features, I would combine them in a single UI like below: which conveys that both comments and contributions are equally important, this is how I have visualised it:

enter image description here

I would also add a list of recently discussed subjects along with information about what the user did (Icons). Did he comment, shared a document or both. This would help the user visualise their discussion history and perhaps act accordingly in future discussions.

In addition to the above, you could have a link to user stats which could be the first building block for a gamified process to encourage users to share and comment on documents more!

  • I really like your perspective!. Great point of view and clear explanation. Thank you very much. So you believe my approach of totally splitting is somehow bad practice (due to confusion or something), or your answer is more like an alternative point of view? Commented Mar 5, 2015 at 9:37
  • @IagoRodríguez-Quintana I think having a split UI accentuates the fact that users have to make a choice, while what you really want to achieve is to encourage users to do both (without limiting their choice of course). Having both tasks in one view coupled with gamification elements and sharing history encourages users to create a balance and become more consistent. love the idea!
    – Okavango
    Commented Mar 5, 2015 at 9:51
  • You're really forcing me to double-think my former approach. Thanks for that!! Looking deeper into the differences of both proposals I would say: totally splitting forces to decide prior and then focuses exclusively on that selectecd task (emphasizes that there are 2 ways of contributing); and shared focuses first in encouraging contribution and then the decision (doesn't point out so clearly the 2 ways but could perform better since it doesn't force to decide). The other extra features you mention are great and we are dealing with them in the app. I really appreciate your discussion. Commented Mar 5, 2015 at 11:59

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.