1

My team and I are working on a project and an issue was reported during QA in which the layout gets all disjointed when the user zooms in using the browser controls. The development assigned the work to the UX department asking us to include in the wireframes / prototypes how the screens should look.

So the questions is, does UX own this or should the devs own this?

closed as primarily opinion-based by Code Maverick, msanford, JonW Jun 20 '14 at 17:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • There's no definite answer for this. It's purely based on the way a particular organization is set up and its business rules. – Code Maverick Jun 20 '14 at 15:02
  • "zooms in"? Do you mean "increases the size of the font"? That is hardly zooming, if so. something to think about – New Alexandria Jun 20 '14 at 15:46
2

First thing I'd like to say is that I'm not particularly impressed/ convinced by this kind of "who owns what" arguments. As far as I'm concerned, the end product is what matters. Everybody involved in the design and development process should be "owning" the product. Everybody should be taking part somehow into the discussion of how best to deliver the awesome product that users will fall in love.

But anyway, I understand where the arguments are coming from. And it is sometimes a politically necessary thing to do (think Jira or other issue tracking systems).

The first factor to take into account is what is YOUR COMPANY's own definition of the departments, i.e. what are the responsibilities of UX and Dev departments respectively? Is there a formal agreement or something like that which exists?

The second factor is about YOUR TEAM. How willing are you guys to own it? Do you feel like it's something UX guys should be doing?

The third factor is the CONTEXT of this issue concerning the zoom function. Is it a complicated feature/fix that requires elaboration, wireframe, visual design? Was it already defined anywhere anytime before? Or it's just a really simple development detail or bug?

On the other hand, generally speaking, the role of UX is to bridge the gap between users and the system. We are often considered the user advocate, trying to fight against implementation-centric or system-oriented models (which are real bad for users).

The obvious question now is that is it OK for you to let the Dev team solve the issue without consulting you? What if they come up with a implementation-centric solution that looks and works just really bad from a UX point-of-view?

I guess not. In my opinion, UX department would need to have a say anyway in how you would like to design to be fixed. And it's best to do it before the Dev department tries to tackle the problem, usually with their technical know-how and sometimes ignores how it would turn out for users.

In your case, the Dev is asking for wireframes, so it looks like the issue might be something they can't resolve (or so they think) without your input.

So in general, I think UX should "own" it. Having a hand on the problem first, explore it (no matter how fast it can be), then discuss with the Devs to work out a solution.

  • I guess from the UX perspective we have already defined what each screen needs to look like and how they function. The zoom in our out, we feel, should not affect that. To me personally, it should behave like it does on a mobile device when you zoom in because things are too small to read. The layout doesn't change, the functionality of the screen doesn't change ... things just become larger / smaller. In that regard I feel the UX has already provided this and conveyed that things should remain as designed. We are more or less looking for how other teams, companies handle such a thing. – IczerX01 Jun 20 '14 at 15:25
  • If everything stays the same, I guess it'd not take you guys much time to produce something visual, which can be taken by Dev as "the" spec. Then you can easily just hand the issue over to them. In my experience though, quite often the most obvious changes are actually not that trivial. Take responsive design for example. Changing the browser window size actually requires the wireframes and visual design to be adapted. So producing something for the Dev is actually also a good opportunity for UX folks to verify our design in different contexts/scenarios. – Son Do Lenh Jun 20 '14 at 15:32
  • By the way, if it were to take place in our company, UX would take it. – Son Do Lenh Jun 20 '14 at 15:35
2

It's definitely a design problem, the layout should be aesthetically and functionally as good as possible in whatever viewport it's given. Generally I'd say whoever designed the layout should give thought to how it looks at various viewport sizes, but to pigeon hole it as a UX design issue or a graphic design issue or a development issue can be overly restrictive and unproductive.

Sometimes the layout and it's transformations are vaguely specified and left to the developer to fine tune, sometimes it's an iterative process, and sometimes it's pixel-perfectly specified by a graphics designer. And sometimes it's a mix of processes and often it's a collaboration across disciplines. It depends on the team and the project (e.g. a illustrative/graphics heavy page might need to be pixel-perfectly designed by a graphics person).

Some technical tips to help with this issue: 1) use responsive layouts (media queries) to adjust the layout and element sizes, 2) let content (not popular screen sizes) determine the breakpoints, 3) use em or rem units to specify breakpoints and element sizes.

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