Photo by The UX/UI design context can vary depending on whether the expected end users of a given application are internal staff or the general public.
| INTERNAL (Specialised) Users | PUBLIC (External) Users |
|---|---|
Example: | Example: |
The use of the application is mandated by the user’s job or role. The end user may live and work with the one application over a significant period – without any alternatives. It may be tempting to ignore UX/UI considerations and user feedback, focusing instead on merely incorporating the stipulated functionality. | The user has the choice to use or not use the application. There may be many alternatives available. It may be tempting to prioritise look over substance, where the UX design becomes primarily focused on shallow bells and whistles while ignoring usability. |
Users likely to be subject matter specialists, with jargon and industry terms unique to the business. Opportunity to leverage industry-specific information architectures, procedural shortcuts, and concise content to increase productivity and effectiveness. Users may be more willing to learn shortcuts or more complex techniques especially when these can directly benefit their work. | Must be general enough to appeal to a wide range of users, with more diverse expectations and knowledge/skill levels. Generally not a good idea to assume too much specialist knowledge. Content needs to be tailored to lowest common denominator levels. Limited to familiar/common information architectures to maximise usability. Frustrated users will likely abandon their efforts. |
Expected user base may be quite uniform in their expectations and abilities. Less time may be needed for detailed user profiling. “In-house” users afford easier access for requirements gathering, prototyping, testing and refinement. User involvement is often mandated. Direct user engagement (co-design or iterative design) is much easier; allowing better finetuning. | Expected user base may be quite diverse (think global general public.) There may be many distinct user profiles to comprehend. Representative users may not be easy to access. Users don’t have to cooperate with surveys or provide feedback. Not easy to ask a quick question or conduct impromptu and informal AB tests. |
The application must integrate contextually and seamlessly with surrounding business processes/workflow. It must clearly improve the workflow productivity or outcome quality, and be sustainably useful over a specified lifespan. | The application is often a self-contained experience – it needs to make sense in and of itself only. Life-spans can be short or undefined. Deploy-and-forget can happen after the initial excitement wears off. |
The application is more likely to be mission critical to the business. It may be the only practical way to achieve a certain outcome. This demands a higher level of usability, accuracy and robustness. Support and help will need to be specific to a particular industry and specialisation. Generic help is less useful. | The application is less likely to be mission critical. Support and help need only be general. Too much detail can put off users. |
