it-swarm.com.de

Was sollte ein UX-Designer über CSS wissen (für ein Vorstellungsgespräch)?

Ich habe am Freitag ein Interview für die Rolle eines UX-Designers. In der Stellenbeschreibung heißt es "HTML- und CSS-Kenntnisse erforderlich". Obwohl ich die Grundlagen von HTML und CSS kenne, habe ich noch nicht programmiert. Auf welche potenziellen Interviewfragen sollte ich mich vorbereiten und was soll ein UX-Designer in diesem Bereich wissen?

Wie viel Codierung benötigt die Rolle eines UX-Designers normalerweise?

16
Tara

Ich habe nicht codiert

Dann würde ich sagen, dass Sie keine HTML- und CSS-Kenntnisse haben. Das ist kein Deal Breaker. Aber ich möchte lieber, dass Sie ehrlich sind und dann versuchen, sich während des Interviews durch einige CSS-Fragen zu täuschen. Zustand "Ich verstehe die Grundlagen und bin gespannt darauf, mehr zu lernen, habe aber noch keine Front-End-Entwicklungsarbeit geleistet.".

Können Sie einige der möglichen Interviewfragen teilen?

Sie könnten überall sein. Ich erwarte nicht, dass Entwickler syntax-perfekten Code in ihren Kopf schreiben, daher würde ich eher Fragen stellen, die eher auf Meinungen als auf spezifischen Syntax basieren. Ich darf fragen:

  • Welche Elemente von CSS3 gefallen Ihnen am besten?
  • Haben Sie mit CSS-Übergängen für Webkits gearbeitet?
  • Was ist Ihre Standardmethode für den Umgang mit IE?
  • Welche CSS-Frameworks haben Sie verwendet? Was hat dir an ihnen gefallen/nicht gefallen?
  • Hast du von OOCSS gehört? Was ist deine Meinung dazu?

Dies sind jedoch keine Fragen, auf die Sie in wenigen Tagen Antworten finden können. Diese zeigen alle Ihre tatsächliche Berufserfahrung (oder deren Fehlen).

wie viel Codierung benötigt die Rolle eines UX-Designers normalerweise?

Es gibt keine typischen Fähigkeiten für UX-Designer. Dies hängt ganz von der Art des UX-Teams ab, in dem Sie sich befinden, von den Fähigkeiten der anderen Teammitglieder und von den persönlichen Vorlieben/Wünschen der UX-Manager.

Ich persönlich bevorzuge die Zusammenarbeit mit UX-Designern, die auch das erstellen können, was sie entwerfen. Aber in größeren Teams ist sicherlich Platz für alle Arten von Rollen und Fähigkeiten.

Viele UX-Teams berühren niemals Code. Viele UX-Teams erledigen alles, einschließlich HTML-CSS und JS.

17
DA01

Wenn Sie keine HTML/CSS-Kenntnisse haben, seien Sie auf jeden Fall ehrlich. Wenn Sie etwas lernen möchten, geben Sie dies an. Unterstützen Sie dies mit ein wenig Recherche.

und zeigen Sie, dass Sie Ihre Fähigkeiten in diesem Bereich proaktiv verbessern, wenn dies der gewünschte Job ist.

Es ist großartig, Ihre Ideen und Designs in Prototypen mit repräsentativen Benutzern testen zu können. Möglicherweise benötigen Sie zunächst Hilfe von Entwicklern. Sie können jedoch zunächst mithilfe von Imagemaps einfach Klicks durch Ihre Skizzen/Drahtgitter erstellen und dann nach und nach Dropdown-Listen, Optionsfelder und andere erweiterte Interaktionen vom Typ Jquery hinzufügen lernen.

Es ist schön, diese Dinge selbst ausprobieren zu können, ohne auf die Verfügbarkeit von Entwicklerressourcen angewiesen zu sein. Sie möchten so viele Hindernisse wie möglich beseitigen, um Ideen vor Menschen zu bringen, damit Sie so schnell wie möglich Feedback erhalten.

3
Jo Packer

Mein Team muss CSS/HTML überhaupt nicht verwenden. Wir erstellen lediglich PowerPoint-Storyboards, um die Details der Funktion zu erläutern, die wir der Anwendung hinzufügen möchten.

Ich finde jedoch, dass die Designer, die CSS kennen, besser verstehen, wie die Anwendung erstellt wird. Es ist ein gewisses Maß an technischem Wissen, das einen zu einem besseren Designer macht.

Es ist nicht so, dass sie CSS machen müssen. Es ist eher eine Hintergrundsache. Wenn sie CSS kennen, verstehen sie den Browser und das Web besser.

3
Glen Lipka

Ich bin ein Webprogrammierer und ich kann Ihnen sagen, dass es äußerst frustrierend ist, wenn ich mit einem Grafik-/UX-Designer, der nichts über HTML/CSS weiß, an einem Webprojekt arbeiten musste.

Es gibt zwei Gründe: Designer, die sich mit HTML/CSS nicht auskennen, scheitern normalerweise an zwei Punkten:

  1. erstellen Sie Designs, die nicht den Best Practices entsprechen, da sie nicht die volle Leistungsfähigkeit von HTML/CSS kennen und der Meinung sind, dass ein modernes Best-Practice-Design zu schwierig zu implementieren ist.
  2. erstellen Sie Designs, die großartig sind, aber ohne viel benutzerdefiniertes Javascript kaum zu implementieren sind, da sie nicht wissen, dass HTML/CSS nicht alles so einfach ausführen kann.

Dinge, die in einem Mockuping-Tool einfach zu erledigen sind, können in HTML/CSS schwierig sein, während andere Dinge, die in einem Mockuping-Tool nicht möglich sind, in HTML/CSS trivial sind.

Ein Beispiel ist das adaptive Layout. Unter Berücksichtigung der richtigen Überlegungen zum ursprünglichen Design ist es möglich, ein Layout zu erstellen, das sich an den Browser des Benutzers anpasst (d. H. Bildschirmgröße, Maus- oder Touchscreen, Hör-/Braillezeile usw.). Diese Art von Dingen lässt sich in einem Modell nicht ausdrücken, und Designer, die sich mit HTML/CSS nicht auskennen, erstellen normalerweise ein statisches Layout und nutzen die von HTML/CSS angebotenen Funktionen nicht vollständig aus. oder sie entwerfen zu viele Interaktionen, die viel benutzerdefinierte Javascript-Arbeit erfordern und eine Zeit-/Kostenüberschreitung verursachen.

Ich erwarte zwar nicht, dass ein Designer HTML- oder CSS-Codes ausgeben kann, aber ich würde erwarten, dass er eine Webanwendung mit Blick auf Webtechnologien entwirft. Ich würde erwarten, dass sie wissen, was in CSS möglich/einfach und was unmöglich/schwer zu tun ist. Angesichts dieser Erwartungen denke ich nicht, dass es möglich ist, etwas darüber zu lernen, ohne sich jemals die Hände schmutzig zu machen, wenn man HTML/CSS von Grund auf neu schreibt.

2
Lie Ryan

Dies führt zu einem Problem mit dem Titel 'UX Designer'. Durch das Hinzufügen eines Designers zum Titel anstelle von beispielsweise UX Architect erwarten viele, dass eine Person endgültige Schnittstellen implementieren kann.

Das wollen sie in diesem Fall.

Zuvor fiel UX unter die Titel Usability and Information Architecture und dort unter Designer und Programmierer. Jetzt sehe ich UX-Rollen, die NICHT UX sind, aber effektiv Interaction Design-Rollen - das ist Visual Design + Front-End-Codierung + Benutzeroberfläche + Einige Kenntnisse der grundlegenden UX.

Kurz gesagt, in diesem Fall wollen sie einen Programmierer und Designer, der auch UX beherrscht. Dies wird immer typischer, aber Menschen, die alle drei gut können, sind sehr, sehr selten. Der Begriff UX Unicorns wurde für diese Fabelwesen erfunden. Diejenigen, die sich für Einhörner halten, sind oft talentierte Webdesigner, die ein wenig über UX wissen, also keine echten Einhörner und auch nur auf das Web beschränkt sind (bei UX geht es um viel mehr als Websites).

Meiner Ansicht nach bedeutet dies, dass mehr Projekte schneller geliefert werden, jedoch mit einer viel schlechteren Benutzererfahrung, da Sie beim Codieren durch das eingeschränkt werden, was am einfachsten zu implementieren ist.

Für meine Ansichten dazu siehe meinen Artikel über die Engineering Mindset.

2
Stewart Dean

Das UX-Konzept scheint so verwirrend zu sein, dass wir umso weniger wissen, je mehr wir darüber sprechen. Es wird fast wie Poesie: eine Frage der Interpretation, als hätten wir keine klare Vorstellung mehr davon. Es hängt alles davon ab, wie wir uns dabei fühlen.

Alles begann damit, dass UX einfach der Prozess war, die Benutzererfahrung von Anfang bis Ende in Bezug auf ein bestimmtes Produkt oder eine bestimmte Dienstleistung zu gestalten. Theoretisch ist diese Definition vielleicht gerecht. In der Praxis gibt es jedoch so viele Kategorien von Menschen mit so vielen unterschiedlichen Interessen, dass eine solche umfassende Definition nur zum Schlachtfeld werden kann.

Zum Beispiel werden einige UX-Profis sagen, dass Personalchefs das UX-Feld aus Unwissenheit erweitern oder um denselben Mann für zahlreiche Aufgaben zu bezahlen. Einstellungsmanager werden sagen, dass es die Schuld der UX-Profis ist, da sie keinen Konsens über die wesentliche Definition ihres Fachgebiets erzielen können. Und so weiter.

Ganz zu schweigen von der unglücklichen Verwendung des Begriffs "Design" im Kontext der schnellen UI-Entwicklung, bei der "Design" eine spezifischere Bedeutung hat und eine subtile, aber entscheidende semantische Bewegung ermöglicht. Am Ende vergessen wir alle, wo wir angefangen haben und sind am Ende entsetzlich verwirrt.

Wenn Sie also fragen: "Was sollte ein UX-Designer über CSS wissen?", Haben Sie das Gefühl, Sie fragen es aus Mangel an einem Bezugspunkt. Es klingt fast wie eine philosophische Frage. Sollte er/sie?

Wenn wir uns ausschließlich auf theoretische Hintergründe beziehen, können wir möglicherweise nicht antworten. Wir sollten uns auf Intuition und einen logischen Ansatz verlassen.

CSS-Codierung ist eine Frage der Implementierung, während UX eine Frage der Planung und proaktiven Planung der erfolgreichen Interaktion zwischen Benutzer und Produkt ist. Deshalb wäre die Antwort theoretisch "Nein", genauso wie wir Planung nicht mit Implementierung mischen sollten.

Im wirklichen Leben kann das Verständnis der UI-Phase auf der Ebene der CSS-Codierung jedoch Teil des Gesamtbildes sein, das ein UX-Profi berücksichtigen sollte. Andererseits kann man das Gefühl bekommen, dass ein UX-Profi ALLES berücksichtigen muss.

In dieser Hinsicht sollten wir, da es anscheinend keine traditionellen Richtlinien gibt, die besten Entscheidungen entsprechend unserem persönlichen Profil anpassen/auswählen/treffen.

Es hängt wirklich von jedem Menschen ab. Einige von uns sind möglicherweise zu sehr in die abstrakten Vorstellungen von Planung involviert und benötigen möglicherweise einige technische Aktivitäten, um sie wieder auf die Erde zu bringen. Warum nicht?

Aufgrund seiner Interdisziplinarität können Sie mit UX unzählige relevante Unterfelder lernen. Wählen wir diejenigen aus, die unsere bisherige Reise ergänzen. Lassen Sie uns sogar unsere Einstellung entsprechend ändern.

Wenn uns jemand fragt: "Was sollte ein UX-Designer über CSS wissen?", Anstatt sich zu fragen, was diese Frage genau bedeutet, können wir sie als solche betrachten:

Ohne die Verpflichtung, CSS-Codierung in unsere UX-Ausbildung einzubeziehen, möchte der Manager wissen, ob dies der Fall ist, dass unser bisheriger Antrieb mit dem Erwerb dieser Fähigkeit vereinbar ist.

Dann verschwindet der ganze Druck und die Frustration.

0
Mircea

Ich bin mir nicht sicher, welche Fragen gestellt werden könnten, wie viel Wissen UX-Typ haben sollte. Was ich teilen kann, ist das, was ich als Webentwickler für wichtig halte.

Das Wichtigste ist auf jeden Fall das gute Verständnis von Blockelementen (wie divs, p, table) gegenüber Inline-Elementen (wie a, span). Sie sollten wissen, wie man ein Layout auf Divs ohne Tabellen erstellt (mithilfe der Eigenschaft float). Sie sollten wissen, wann float-Elemente keinen Platz beanspruchen (wenn Sie beispielsweise in DIV1 nur float-Elemente haben und DIV1 keinen angegebenen Überlauf hat: hidden, dann wird kein Platz reserviert). Sie sollten wissen, welche Anweisungen in welchen Browsern funktionieren (oder genauer: Welche Anweisungen funktionieren in Internet Explorer X nicht ;-)). Dies ist schwierig und erfordert Erfahrung. Sie werden es wahrscheinlich in der Praxis herausfinden, während Sie X Stunden damit verbringen, herauszufinden, warum IE die Website anders anzeigt. Wenn Sie etwas Interessantes wissen möchten Effizienz, dann sollten Sie wissen, dass CSS den Ausdruck von RECHTS nach LINKS analysiert. Das bedeutet, wenn Sie schreiben

#divId a{
 ...
}

dann wird für JEDEN Link auf der Site ein Vergleich durchgeführt, ob einer seiner Parrents #divId ist. Daher ist es eine ineffiziente Art, CSS zu schreiben, obwohl die Intuition dies vorschreibt.

Sie sollten sich der folgenden CSS-Ausdrücke bewusst sein (und sich darüber im Klaren sein, dass 1 und 2 am effizientesten sind).

  1. element nach ID suchen - #divId {...}
  2. element nach Klasse suchen - .classId {...}
  3. sie können Bedingungen beitreten, z. B. ein Element mit BEIDEN Klassen 1 und 2 finden: .class1.class2 {...}
  4. sie können mehrere Elemente gleichzeitig aufnehmen, indem Sie sie durch ein Koma trennen: class1, class2 {...}
  5. sie können alle Elemente des angegebenen Typs übernehmen: div {...}
  6. sie können ein bestimmtes Element (zum Beispiel P) nur nehmen, wenn sein Bruder ein anderes Element ist (zum Beispiel H2): H2 + P {...} (dies stimmt mit <h2> <p> überein, aber nicht mit <h2> <any other element than p > <p>
  7. sie können ein Element mit einem bestimmten Attribut verwenden: a [href] {...}
  8. sie können angeben, was der Wert des Attributs sein soll: input [type = text] {...}
  9. sie können Pseudoklassen verwenden, zum Beispiel: a: hover {...}

dies deckt natürlich nicht das gesamte Thema ab, vermittelt Ihnen jedoch den Eindruck, was Sie googeln möchten, wenn Sie dies für erforderlich halten

Ich hoffe, Sie werden (auch nur ein wenig) von dieser Antwort profitieren, andernfalls ignorieren Sie sie bitte einfach :)

0
mkk