Saturday, September 1, 2012

Click like an end user

I've recently had an emotional debate with developers about a design for a new content authoring product.
While we were building the UX and user flows, the developers have modeled their entities and data hierarchy, and wanted to propose a UX design that would parallel their data model and data flow.

That model, built like a nice view stack (Android style), meant that each entity would open a new view in order to be edited (With a 'back' button and a bread crumbs navigation), all due to the complexity of implementing an 'edit in place' editor for these entities.

While this solution has a very short time to market, scales well to new entity types, and looks cool, the argument that closed the debate was that the developers were not thinking like the end user.

As the end user edits hundreds of entities a day, 66% more clicks per entity and two more transitions (From one view down the stack and back up) would mean a lot more clicks and view changes, as well as would make work a lot more repetitive and tedious.

You can even describe the process, back to back:

Developer suggestion:
"Add entity, click to edit, view opens, edit, go back to view" (Repeat)
UX design:
"Add entity, click to edit (In place), edit" (Repeat)

Now multiply that by 1000s, and the difference is clear.

So next time developers come to you with the brilliant idea that might make the code be more maintainable and scalable, think about the end user as well... The last thing you'd want is that your version would be delivered in time and quality measures, but the users would hate it.

2 comments:

  1. How come developers define ui/ux flows, and not ux or product people?

    ReplyDelete
    Replies
    1. They're not defining flows. However, they have a right to have ideas, as well as an opinion. Sometimes it's good, in this case it was bad, but you always have to listen...

      Delete