{"p":"","h":{"iv":"ROXSYW+cfvEbFHu5","at":"ocxplSQjdRC3tXEtB/9/wg=="}}

@lienrag

Example 2: there's discussion about adding a feature to allow people do...something.

First thing a good designer should do is ask - OK, what is it the user needs to do? Why? In what order, etc.

Then go and do a wireframe/mock-up design. And contribute that.

Even test it with some users.

Good software contributors will say "Great! I don't need to worry about how it works for the user. Thanks UX designer."

@humanetech @ArneBab @tyil @blacklight

1
Share
Share on Mastodon
Share on Twitter
Share on Facebook
Share on Linkedin
smallcircles (Humane Tech Now)

@bernat @lienrag @ArneBab @tyil @blacklight

I must say that this 2nd example implies a 'handover', where insights / big picture tend to get lost.

Ideally both designers and devs have a common understanding of the 'business domain'.

This domain entirely independent of any technical / visual implementation. It is discovered in communication with 'domain experts' (the client) and a common language is defined, so that there's no confusion between people with different skillsets and backgrounds.

1
2y
Replies