This is a multi-discipline question - a question about collaboration between CPU algorithm developers and User Experience designers.

The software is similar to (but not exactly) a mobile image editing application.

The algorithm developers can make a lot of customization to their algorithms, some of which may benefit the overall user experience, some may degrade it.

The following are just basic examples of what decisions can be reached by collaboration: (these are NOT my questions)

  • Ask the user before spending some CPU milliseconds on processing (generating) some results. (X between 100 and 10000 msecs)

    • Reasons for asking:
      • If the user didn't want the result, the user will be annoyed by the lag / pause / battery-burning.
    • Reasons for not-asking:
      • More options means more cluttering of the UI.
      • The user might not know the purpose of the options at all.
        (Yes, this happens all the time.)
      • If the user is going to always want the result, the user will feel annoyed by repeatedly answering "yes".
  • Generate the result at a lower image resolution, for faster display.

    • Reason for lowering resolution: Faster display makes user happier
    • Reason for not lowering resolution: Internally, the algorithm must eventually re-run the algorithm at the full resolution, if the user wants to keep (save) the result.
  • Using visual effect X instead of visual effect Y (for example, sliding in)

    • Reason for choosing one over another:
      • X may be faster (more snappy) because it is less CPU intensive
      • Y may be more impressive to the user
      • On the other hand, some users might not like Y at all

Suppose the algorithm in question is about 10 - 100 times more complicated than above.

From the perspective of the algorithm developer, it is impractical to explain 100% of what happens inside the algorithm. Instead, there is need to limit discussion to the aspects that are relevant to the overall user experience.

Furthermore, the discussion must be limited to a shared vocabulary that is understood by everyone on the team - both UX designers, algorithm developers and maybe the testers and documentation writers.

My question is:

How does the algorithm developer determine what aspects of the algorithm is relevant to UX, and what vocabulary to use?

This question is unrelated to the other question:


  • It matches the question title but not the description
  • The UX in question is not "green"
  • The environment is Agile and is friendly to communications and reviews
  • Still, there is a need for making communications and reviews more effective and to-the-point.

Other relevant points:

  • There is no dedicated front-end prototyper in the team.
  • Algorithm development is handled separately from application development.
  • Wireframe design is reviewed by everyone. After review, UX converts it into visual design.
  • Visual design goes straight into application development.
  • When application development is finished everyone reviews the result.
  • We do have a "anti-prototyping" mentality. Perhaps we aren't prototyping correctly - but when we do prototypes we often find it grossly missing the point.
    • "Prototyping" means completely different things:
      • Prototyping the algorithm?
      • Prototyping the application?
      • Prototyping the wireframe or visual design?
  • Algorithm development has a long development cycle measured in months, not weeks.

1 Answer 1


If the "algorithm developer" is empowered to define what the sphere of influence is for UX then it may be hard reach the optimal collaboration for UX. Normally UX would drive what the algorithms need to achieve.

Collaboration in this situation can be centred around a strong, shared understanding of the users goals and context. User Centered Design provides a framework for this. Note the discovery and communication of the user goals and the associated user stories is primarily the job of UX.

Product management is key stakeholder in UX. Firstly they need to understand the return on investment (ROI) in UX. Where product is not consumer facing there does need to be some clear ROI outcomes for UX work. e.g. efficiency, lower training costs, more accuracy, sales based on recommendations. They also need to be on-board with the user centred design, not just producing "feature lists". If product management is done in a waterfall long-cycle manner, then UX needs to get ahead of this product management cycle, and feed into and guide the requirements. UX would need to be done in a somewhat waterfall manner, with artefacts and research that would influence marketing department.

If there is a long lead time between the algorithm requirements being firmed-up and delivery of the algorithm, then just enough of the UX discovery and design must be done ahead of specification of required algorithms. If not then it will always be a case of "putting lipstick on a pig".

By comparison in a full Agile environment once there is a solid shared understanding of these goals and stories, then a full team design engagement takes place to figure out how to best service the users requirements. Algorithm options should feed into design of varied solution options, and even provide inspiration for novel approaches.

Where algorithms can be configurable, best practice is to test with different configurations. Do note that test does not necessarily imply "prototype". Many companies are constantly testing with live products example of different Google tweaks being tested . No fundamental reason why a mobile app can not acquire settings and transmit anonymous telemetry (with user permissions of course)

  • At my organization, product requirements are still in the realm of the marketing department, because our products are first sold to purchase-decision makers at the customer organization, and then distributed to the customer organization's workforce. I can see that the long development cycle of algorithms is a bottleneck (the time from feature request to algorithm delivery can be as long as a whole year, because purchase-decision makers often require "2 or more 9's" of algorithm accuracy, etc.) It is notably not consumer-oriented.
    – rwong
    Commented Nov 10, 2014 at 7:06
  • Not uncommon scenario. Agile engineering with "waterfall product management" needs a different engagement. Answer still UX engagement with stakeholders - just that stakeholders are product management, and in this case are not Agile. I've edited answer.
    – Jason A.
    Commented Nov 10, 2014 at 9:35

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.