6

Pretext

Most UI frameworks or libraries (that I know of) provide components and layouts in a declarative manner with the underlying implementation as a grid with hooks for extending the functionality. This means that once you have defined a blueprint of your layout (which is a grid internally) what you can do on it later will be limited by the structure of the grid.

Question

How to explain to the architects and managers that the choice of a library or a framework should be made or evaluated after deciding what is to be done rather than first choosing the framework and then choking the UX designer with limitations of that framework (some of which may be identified in due course of engineering itself)?

Is there a study or research done on pitfalls of such approach?

Improve this question
15
  • Are you talking about web UI frameworks or something else? (Like a native app framework or cross-platform framework)
    – Nate Green
    Commented Feb 19, 2016 at 13:42
  • @nategreen I am talking about Web only.
    – gurvinder372
    Commented Feb 19, 2016 at 13:54
  • A fortunate thing about web UI frameworks is that they're (usually) pretty extensible. Either way, your architect might appreciate an argument that the UI kit should be as "decoupled" as possible from the back-end (for design flexibility and future-proofing reasons) and the manager might appreciate that locking yourselves into a path now might mean significantly more development time later, if the framework turns out to be lacking many of the components you need.
    – Nate Green
    Commented Feb 19, 2016 at 14:03
  • 1
    Isn't this more of a general programming problem than anything UX related?
    – icc97
    Commented Feb 23, 2016 at 2:30
  • 1
    @AndrewMartin At the start of any project there should be some idea of the end product works fine if there are at most 2-3 people working on it. But if there are two teams working on it - idea must be documented! or at least there has to some way for different teams to be on the same page. And it is very rare that ideas start you started with are going to stay same a considerable period of time. Framework decisions, when made based on an idea, don't take very long. So in all probability, framework decision is taken much before UX process reaches design phase (wireframe stage).
    – gurvinder372
    Commented Feb 24, 2016 at 14:15

6 Answers 6

Reset to default
5

Implicitly what you are talking about is 2 things

Corporate Commitment to UX

If company serious about UX then they will commit to

  • involve UX in early inception and evaluation
  • extend any UI libraries used to support key UX
  • rework inadequate UI solutions out of product

Action: you need to have key coordinating managers understand this. They should already understand cost-to-change and apply sufficient due diligence.

Avoid Big Design Upfront (BDUF)

Projects should not proceed until the team is very sure that all requirements, all UX, and all required technologies are well understood. And everything can definitively be created spot-on.

Action: don't do BDUF. Like communism, it sounds great but doesn't work. Learn Agile UX.

Consider three simple truths that, once accepted, dispense with much of the drama and dysfunction we typically see on software projects.

Main action I would look to do is this case is to drive through a spike (a narrow top to bottom implementation) that establishes the UI patterns for the UX area of most importance and highest risk. This would mean that very early in the project you can see if tooling supports the required UX or not. Before the cost to change becomes a blocker.

Improve this answer
5
  • Thanks, but I disagree about BDUF. I don't want to get the actual final wireframe of grid before starting, but whether a grid is required, 'rough layout of grid' and what all functions grid may have will suffice. I get your point, I am aware that requirements will always change. Can you throw some more light on how much is enough before start looking for frameworks? Thanks again.
    – gurvinder372
    Commented Feb 24, 2016 at 11:37
  • Cheers, sounds like you understand the BDUF risks, but I'll leave the point in for others. Let me put this way - if you need "some grid" how do you know "a grid" will support your UX? (1) once I got stuck with grid that would not do hyper-links! (2) personally did post-mortem a large-scale (1M+ USD) project failed because was built on top of a specific RTF component rather than connected to a component. Went well for a while but hit the cliff. With (1) we hacked it via source code in week, however (2) was a shocking design, full rewrite needed.
    – Jason A.
    Commented Feb 25, 2016 at 12:46
  • To actually answer how much is enough you'll need to figure out your risk profile. i.e. Do you really fear that component choice will leave you without possibility of a grid UI? What is the cost to change? How soon can you establish the key UI patterns? More risk, more due diligence needed. But it is pathological if the cost to change or more importantly evolve the UI tooling >= entire project.
    – Jason A.
    Commented Feb 25, 2016 at 12:55
  • can you share an example of how agile UX will help in this case? Thanks.
    – gurvinder372
    Commented Feb 26, 2016 at 10:43
  • Super question - I amended the answer to included specific action I would recommend.
    – Jason A.
    Commented Feb 27, 2016 at 21:03
5

You need to elicit requirements for the web app you're planning to build. This is essential part of software development.

Many projects fail because of incomplete requirements. According to this study where 8000 projects were surveyed 1/3 of the projects were never completed and half of them partially with considerable delays. The major source of problems was incomplete requirements (50%), and lack of involvment of users (12%). So it is a good idea to show your managers some stats that if they do not do requirements elicitation their project is most likely to fail.

Its 200 times cheaper to find problems before developing rather than after that. (source)

I use academic papers like this one, but you can use other web resources.

You can elicit requirements by creating a carefully selected list of questions about the future use of your app and then interview 10 people and see their perspectives and requirements. You can also do survey to complement the data from the interviews. You them make an excel table with how many users want this feature, how many want other feature. Then you list your apps requirements and start looking for a suitable framework.

Improve this answer
2
  • 1
    Thanks, good links apart but for last line. I am not talking about convincing my manager about usability testing rather explaining him why is it important to find out what you do before deciding how to do it.
    – gurvinder372
    Commented Feb 22, 2016 at 8:48
  • 1
    The sources for those links are 20 years old and a lot have happened in software development since then. Requirements change all the time and that is perfectly natural. Instead of fighting this, today many teams are following some kind of "agile" development process where reacting to constant change in requirements is expected. Also, a UI library is just a tool and should not affect the user experience that much. In fact: limitations are the source of creativity!
    – filip
    Commented Feb 28, 2016 at 12:46
3

I spent some time evaluating different grid systems and frameworks, based on my own comparison of the features offered, plus other people's reviews of them.

I think the first step would be to explain to the architects and managers that there are different frameworks on offer - some are lightweight and minimalist, others are more bloated.

So, if the system you are going to build needs to work on low bandwidth (e.g. over 3G or 4G) then a framework with a huge set of CSS and JavaScript files is going to take up a lot of bandwidth.

Some frameworks may be more responsive than others; and some may be more suited to sites optimised for mobile devices.

I would do a comparison grid of all the different functionality offered by the various frameworks, and then ask what sort of functionality is required for the system, and see which one gives the closest match, or better, as no-one knows what the future requirements may be, which one is the most flexible.

Improve this answer
3
  • Thanks for your reply. But how can I look into frameworks without knowing the user, its goals and finally what experience we want to provide him. What should I evaluate framework against, when I don't know yet what I need?
    – gurvinder372
    Commented Feb 20, 2016 at 7:17
  • 1
    @gurvinder372: By evaluating frameworks, you get the knowledge of their features, flexibility, cost, implementation details. You can do that ahead of further planning. It will not be a waste of time, as in the end you'll apply the knowledge to specific needs. Know your audience, but also know your tools.
    – lesssugar
    Commented Feb 21, 2016 at 23:13
  • I am aware that framework evaluation is always beneficial. However, it is not always possible to cover/evaluate-for specific requirements/issues which you may get later on when you get into details of what-is-to-be-done. More often than not you end-up doing a compromise or trade-off since changing a framework or library later can be too expensive.
    – gurvinder372
    Commented Feb 22, 2016 at 5:56
3
+50

@gurvinder372 - in a previous comment you said

"I am not talking about convincing my manager about usability testing rather explaining him why is it important to find out what you do before deciding how to do it."

That specific argument seems like a great candidate for analogy - You wouldn't want to be stuck in a Jeep Wrangler for cross-country highway trip, and you wouldn't buy a Corvette to go off-roading. Both, conceivably, would work but it would be much better for everyone involved to start with the right car for the right trip.

Define your goals and requirements and then pick the vehicle that gets you closest to that goal - knowing that every framework needs tweaking.

You also said

"What should I evaluate framework against, when I don't know yet what I need?"

That seems to be the larger problem, it's hard to convince other people of what you need when you don't know yet.

From that point - I would look at the talent of your team and look at the frameworks that best complement their talents and capabilities, that may be another way to back into a decent solution.

Improve this answer
3
  • 1
    Looks like the only direct answer to the question. +1 for the analogy and the alternative advice.
    – jazZRo
    Commented Feb 27, 2016 at 10:46
  • Erik, i liked this part look at the talent of your team and frameworks that best complement their talents and capabilities. I think this is the most realistic and sane answer. Could you also address the meta-issue that may came out of this - BDUF (big design up front)? Or may be an example of how to look at talent in team and take decision? Thanks
    – gurvinder372
    Commented Feb 29, 2016 at 5:18
  • I've never seen BDUF (big design up front) work, from a design perspective - details are always missed - or from a development perspective - problems look too big to ever code for. Enough design up front should answer the large questions - we're designing for something video heavy, or report heavy (grids) or something that has each post being art directed - big cuts like that should help drive the direction. As for the team and talent part, ask them. What would they use and why? A lot of our team has Bootstrap experience - Foundation just wouldn't be worth the development overhead to ramp up.
    – Erik Hanson
    Commented Mar 2, 2016 at 4:50
2

The simplest way IMO is to explain the process of the creation of a product.

From a quick google images search "product design process" / "UX process"

It is best shown with a diagram:

First you think then you make then repeat

enter image description here

First you plan then you create

enter image description here

enter image description here

First you research then you design then you improve

enter image description here

Improve this answer
2
  • Thanks, but it doesn't directly answer my question. Can you elaborate on how your post helps in deciding that choice of UI library and framework should be made after the design of user experience?
    – gurvinder372
    Commented Feb 24, 2016 at 14:20
  • @gurvinder372 If you follow the diagrams that represent the work process you can show to the architects and managers that the development stage comes after the earlier stage of understanding what you want to create (think / research / concept). This means that when you start to chose the UI library, you already finished designing the user experience (or at least part of it).
    – dimshik
    Commented Feb 24, 2016 at 15:11
2

To me this is a pretty simple dependancy: User Experience design process will define which interactions the system will have to exhibit, so until that is clear, choosing a certain library would be a waste of time, because then specific interactions will require workarounds or compromises and it will just end up in the frustration of all parties involved — the team, the designers, the stakeholders, the users.

Improve this answer
4
  • 1
    Zoe, I agree. Is there a way for UX process to put some checks and balances (for the choice of library) so that all parties can avoid getting frustrated later. Thanks.
    – gurvinder372
    Commented Feb 25, 2016 at 10:19
  • Well, giving developers a complete and exhaustive list of interactions will go against agile process, because the app is evolving in cycles, right. So I wouldn't worry about that, but two things would be good to consider and share in the beginning: choice of the most flexible library as possible and a preliminary checklist of interactions (knowing it will be surely updated later). When changes in UI will build up and conflict with the current library, the frontend can be refactored again, it's a natural process.
    – Zoe K
    Commented Feb 25, 2016 at 11:09
  • Yes, that makes sense. Is there a way to tell how much (list of interactions) is enough?
    – gurvinder372
    Commented Feb 25, 2016 at 11:11
  • Depends on the app (and a device). From the top of my head, a list of elements like "buttons, dropdowns, accordions, pickers, input forms, simple data visualisations with interactive input, animations 1, 2, 3" should cover you.
    – Zoe K
    Commented Feb 25, 2016 at 11:39

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.