En E-Commerce Site gëtt net liicht lancéiert. Mir wëllen datt et effektiv ass, schéin, mat enger aussergewéinlecher Interface, eng Zuel vu Verkaf fir seng Konkurrenten ze rivaliséieren. Bref, Herrlechkeet, Gléck a Schéinheet no laanger Aarbechtsstonnen.
Awer loosst eis kloer sinn, all dës Punkte beaflossen haaptsächlech den Design, Marketing a strategesche Aspekt vum Beast, awer ee Punkt deen net iwwersinn sollt ass seng Leeschtung. Firwat ? Leeschtung ass en onverzichtbare Bestanddeel vun der Benotzererfarung.

Dir sollt wëssen datt d'Performance vun engem Site staark d'Perceptioun vun engem Service beaflosst an dofir d'Benotzererfarung ugebueden. D'Performance beaflosst och d'Transformatioun, d'Erhéijung vum Ëmsaz an dofir d'Rentabilitéit vum System..
An do ass et néideg op den techneschen Aspekt vum Problem ze gräifen.
Als UX Designer vu Beruff ze sinn, wäert ech net behaapten déi absolut Wourecht ze halen, awer ech mengen et ass néideg a wichteg fir op d'mannst dësen Aspekt a säin Impakt op Ärem E-Commerce Site ze verstoen. Wësst datt dësen Artikel vun engem vun eisen techneschen Experten guttgeheescht ass!
Leeschtung huet eng Schlësselroll. Leider ass dëst e Punkt deen dacks ze spéit (um Enn vum Projet) ugeschwat gëtt. Wéi och ëmmer, et ass schlau fir op all Etapp driwwer ze bleiwen. Et soll wéi follegt passen:

Medien (Desktop an Handy, Tablet)
Méiglech Verbindungen (Wifi, 3G oder am schlëmmste Edge)
Eis Ëmwelt (Plaz, limitéiert Zäit, Stress Zoustand, Behënnerung).

Zum Beispill, Facebook bitt verschidde Versioune vu sengem Service fir duerch seng Adoptioun an opkomende Länner ze briechen.
Et ass also néideg datt all Member vun Ärem Team seng Wichtegkeet, säin Impakt op de Projet bewosst gemaach gëtt. Wat den "gemaach" (gemaach) vun der agile Method ugeet, musst Dir Är Leeschtungseigenschaften upstream definéieren fir se op d'Prioritéitsdeeler vun Ärem Service / Site anzesetzen.
Awer wat sinn dann d'Haaptcritèrë fir ze erfëllen? Hei sinn se:

1/ D'Geschwindegkeet vun der Äntwert

Näischt schlëmmer am Joer 2017 wéi méi wéi 3 Sekonnen op enger Säit ze waarden déi net lued wéinst enger Ufro déi ze laang ass, HTML Säiten ze gelueden, Biller ze schwéier oder en Design deen ze komplex ass ...
Dir sollt dat wëssen d'Längegkeet vun engem Site kann e groussen Impakt op d'Indexéierung hunn. Google kann Äre Site ënner dem akzeptablen Schwell vun 2 Sekonnen maximal schätzen fir eng korrekt Indexéierung. Et kann Iech also komplett aus Sichmotoren ausschléissen.

Awer keng Indexéierung, keng Visibilitéit, keng Visibilitéit, keng Clienten ...

Äre Site däerf kee Punkt vun der Perdition ginn. E schnelle Site erfëllt seng Clienten a well se méi dacks konsultéiert gëtt, fördert se seng Positionéierung a Sichmotoren..
En Artikel vum Nati Slalom spezifizéiert datt all honnert Millisekonnen bis zu bal 1% vum Verkaf verléieren. Op alle Fall erlaabt eng gespléckt Luede Iech ze weisen datt Äre Site als éischt lued ier Dir déi ganz Säit weist.
Hei ass eng kleng Tutorial Optimisatioun vun de Säiten, déi vu Google ugebuede ginn.

2/ Service Laascht widderstoen

Waat.. ? Dir wollt dem Rihanna seng lescht Single um Chrëschtdag bestellen, awer de Server ass erofgefall just nodeems d'Bestellung validéiert gouf?
Dir sollt wëssen datt d'Kalibrierung vun engem Site souwuel a senger Serverinfrastruktur wéi och a senger Gedächtnisverwaltung eng beandrockend Unzuel u Verbindungen an Ufroe muss berücksichtegen fir net zu bestëmmte Schlësselzäiten vum Joer wéi Verkaf oder Feierdeeg ze "crashen". D'ESF E-Commerce Plattform huet sech missen upassen fir den ëmmer méi héije Kraaftbedürfnisser z'erreechen fir Laaschtpieps vu méi wéi 3500 Bestellungen pro Dag oder méi wéi 1 Millioun Euro z'erreechen. Wann Dir Är Léisung designt, Dir musst d'Zuel vun den Ufroen op Ären Datenbanken sou vill wéi méiglech limitéieren. All Verloscht vum Server kann Iech potenziell verursaachen datt Dir e grousse Volumen vum Ëmsaz verléiert.

3/ Seng Disponibilitéit

Dir kennt de berühmte Feeler 503: Service Unavailable, deen deen Iech wierklech nervt wann Dir musst verbannen ...
En E-Commerce Site entwéckelt sech permanent. De Katalog wiisst, et muss an de Faarwen vun der Saison oder aktuellen Eventer gekleet ginn. D'Gestioun vu Verbesserungs- oder Ënnerhaltaarbechten ass essentiell a konstant, awer muss eng Methodologie befollegen fir an Off-Peakzäiten ze aktualiséieren oder iwwer Failovers vun engem Server op en aneren (Laaschtbalancéierung).

4) Seng Zouverlässegkeet.

Schimmt Iech op Ärem Site deen nach ëmmer eng Sich bitt déi Skates, eng Äntwert nieft dem Plack, a Feeler an der Datebank ...
Eng Online Offer ze hunn ass gutt, awer wann Dir dëst z'erreechen musst Är Donnéeën eng Architektur léinen, déi den 12 Wierker vum Asterix wäert léinen, oder souguer e Labyrinth vu Verifizéierungssystemer mat schlecht optiméierten Algorithmen, hutt Dir eng grouss Chance. Déi wichteg Saach ass Är Léisung dauernd ze vereinfachen, ze testen an unzepassen. Am Fall vun enger Sichmaschinn oder Service, déi d'Präisser direkt fir Iech berechnen muss, muss den agefouerten Algorithmus Äntwertzäiten esou vill wéi méiglech reduzéiert ubidden, besonnesch dank parallele Berechnungen oder effizienten Indexéierung.
D'Performance vun Ärem Site muss also op verschiddenen Deeler spillen:
- Op der Server Säit fänke mir als éischt un: iwwer d'Architektur vun Ärer Léisung, d'Datemanagement, d'IS-Schicht, Är Berechnungalgorithmen, dann d'technesch Leeschtung an d'Servergeschwindegkeet, a schliisslech d'Qualitéit vun der Optimisatioun vun Ärer Datebank.
- Op der Client Säit wäert Dir garantéieren: d'Performance vun der benotzter Sprooch an den Entwécklungskader, de minimale Gewiicht vun de grafeschen Elementer, a schliisslech d'Optimiséierung an d'Vereinfachung vum Design fir ze vill Ufroen an ze komplex HTML Säiten ze vermeiden.

Loosst eis déi bedeitendst Deeler dissektéieren fir eng besser Leeschtung ...

Architektur
D'Architektur vun Ärer E-Commerce Léisung spillt eng Schlësselroll. Wa mir mengen datt et falsch ass, wäert de Site vun enger schlechter Kalibrierung vu sengem Traffic leiden a wäert an der Zuel vu Konsultatiounen verléieren, wäert net fäeg sinn ze evoluéieren a wuessen.
Allgemeng ass d'Architektur a verschidde Stécker opgedeelt fir no Typ vun Aufgab ze spezialiséieren. Am E-Commerce ginn d'Léisungen ëmmer méi Multi-Channel. Et ass néideg d'Verbindunge mat allen Infrastrukturen, déi verschidden Donnéeën an Datenbanken ze berücksichtegen. Site, Buttek, Inventar, Clientsservice an CRM Daten sinn nach ëmmer zoue Welten déi méi effizient wiere wa se op enger gemeinsamer Basis operéiert. D'Gestioun vun den Daten gesammelt oder ze verwalten no de Kanäl leiden ënner engem Manktem u Standardiséierung.
Fir dëse Besoin gerecht ze ginn, benotze mir eng Middleware allgemeng PIM genannt, déi fäeg ass all d'Kanäl duerch en eenzege kohärent System ze gruppéieren. Dëst nach schwéier System erlaabt, eemol installéiert, déi vill gesichte Eenheet tëscht de verschiddene Plattformen a bitt transversal, homogen an effizient Gestioun: den Hellege Graal ze erreechen fir vill Marken. Dës Donnéeën, wa se gesammelt ginn, erlaben eng méi einfach a méi breet Konsumentanalyse. Schlussendlech wäert Dir dann besser fäeg sinn eng Qualitéit Benotzerrees an Erfahrung duerch all Är Markekanäl ze bidden.
D'IS Layer
Dëst si Spiller, déi Softwareléisungen ubidden, déi no den Aktivitéitssecteuren entwéckelt ginn. Dës Léisunge maachen et méiglech Informatioun tëscht Departementer ze zentraliséieren fir eng besser Gesamtvisibilitéit ze garantéieren, d'Produktivitéit ze erhéijen an d'Ressourcen besser ze managen. Et kann ERP (Enterprise Resource Planning), e Cashbezuelsystem zum Beispill, eng Logistik- a Serviceléisung, eng After-Sales Service Plattform sinn. D'Haaptverëffentlecher sinn: Sage, Cegid, Divalto, Ines, SAP ...
Är E-Commerce-Léisung muss fäeg sinn mat dëse Plattformen ze kommunizéieren an dofir muss déi gewielte Léisung fäeg sinn tëscht Ären verschiddenen Informatiounssystemer opzemaachen., Är Verkafspunkte souwuel real a virtuell.
Plattformen
Dëst sinn déi meescht benotzt Online Handelsplattformen um E-Commerce Maart, awer näischt verhënnert Iech vun Null unzefänken.

Op de grousse Konten a Multi-Kanal Ënnerstëtzung Säit, wäerte mir op Servicer wéi Hybris, Magento, Intershop, Demandware ...
Fir méi kleng Strukturen, mir wäerte méi op PrestaShop, Shopify, WooCommerce, VirtueMart leeën.

Si ginn allgemeng ënnerscheet no der Wichtegkeet vun hirer Gemeinschaft vun Entwéckler, d'Verlängerungsmoduler verfügbar, d'Technologie déi benotzt gëtt an hir Fäegkeeten fir Clientebedürfnisser z'ënnerstëtzen.
D'Wiel ass variéiert awer entscheedend. Ofhängeg vun der gewielter Léisung bréngt jidderee seng Stäerkten a Schwächen. Awer mir definéieren d'Léisung no den E-Commerce Bedierfnesser, der Struktur vun der Firma an natierlech dem zougewisenen Budget.

Konklusioun

Also wann de Start vun engem Service, enger App oder engem E-Commerce Site Iech verlockt, et ass sécherlech néideg op seng kommerziell, Marketing, Design an experimentell Erausfuerderungen ze reagéieren, awer d'Fro vun der Leeschtung bleift wesentlech. Et sollt verstane ginn datt den techneschen Aspekt vun Ärer Plattform no senger Gréisst, senger Evolutioun, der Aart vun de benotzte Kanäl, dem Budget an der verfügbarer Détachementzäit kalibréiert gëtt.
Op alle Fall rode mir Iech virsiichteg Är Bedierfnesser viraus ze analyséieren. Ier Dir op esou e Projet ufänkt, fuert Äre Projet mat Rigoritéit aus, andeems Dir stänneg tëscht Ären Teams kommunizéiert.
Wann Dir en erfollegräiche Site wëllt, da sollt et net vun enger technescher Léisung an enger rauer Projektmanagement leiden. UX-Republic wäert fäeg sinn Iech an dëse Schrëtt z'ënnerstëtzen wann Dir musst ufänken!
Glécklech Online Verkaf!

Jérôme Daburon, UX-Evangelist - UX-commerce Foundation @UX-Republik