Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (13)
Semelhante a Working with UX, Design and Front End Developers
Semelhante a Working with UX, Design and Front End Developers (20)
Último
Último (20)
Working with UX, Design and Front End Developers
- 2. Working with UX / Design & Front End Developers
- 4. Due to the nature of these tasks and project management concerns this often leaves specific disciplines for each phase • Scoping & Definition is done multi discipline • Specifications are written and defined by developers • Design/UX is done by designers & UX practitioners • Build is done by developers & front end developers Lifecycle Responsibilities
- 5. Each discipline focused on their own tasks with different levels of understanding on each others disciplines. • Design – Brand, Colour, Perception, Identity • UX – Interaction, KPIs, Ease of use, accessibility • Development – Build, Integration, CMS, Architecture, Testing Responsibility Issues
- 6. A key to aligning the development of a CMS project with design and UX is platform education • Reusability • Better understanding of features/limitations of the platform • Limitation of scope creep from design • Knowledge of the features to aid Design and UX • Working with FEDs to reduce unnecessary complexity Solutions
- 7. Episerver has a number of key features which are great to educate design and UX around • Blocks – (Design/UX) • A/B testing for (UX) • Personalisation (UX) • Episerver Forms (Design/UX) • CMS – Branding, Icons, Previews (Design) • But also a lack some limitation to be aware of Episerver –Design/UX
- 8. Episerver also has some things that your front end developers need to be area of which can give great benefits. • Rendering of blocks/sizes (TBC) • Icons/Previews • CMS editor stylesheets • Editor previews • Modules such as forms Episerver - FED
- 9. Blocks are the cornerstone of component separation in Episerver with some nifty features • Reusability across the website • Ability to display in multiple sizes • Renders wrapping divs for the CMS support and Dojo • Blocks previews need special attention • Structure can easily be tailored FED - Blocks
- 10. Blocks are complicated and so it’s better to define all these up front as part of the requirements the following can help • Creation of a master block matrix • Creation of an blocks design document • Agreement between all disciplines on block definitions • Requirements split down based on block Defining Blocks
- 11. One thing that allows all of these ideas to converge is reuse such as the following • Creation of a set of master block Design/UX templates for use across projects • Creation of a base build with common functionality/previewing/features • Separation of blocks in to Nuget packages • Separation of blocks on the front end (Angular controllers/sass/BEM) • Test scripting and tests can be done once and re-used Reusability
- 12. Throughout all of these points the key moral is communication across disciplines • Communicate early • Work on reusable areas across Design/UX/Dev and get buy in • Set up slack channels for easy communication • Use collaborative systems such a Invision to allow comments • KEEP TALKING! Communication
Notas do Editor
- Waterfall/Iterative/Agile all follow core principles of requirements, design/UX then implementation Design and UX are key stages of the project which occur before development
- Often projects will start off joint across discipline but it’s not feasible to always have all members of all disciplines at all points This can cause a disconnect of information between disciplines when working in isolation
- Each stage and discipline working toward completing their own goals for a project Focus can sometimes be blind to the issues that might occur in other areas UX/Design may not always understand the technology Project managers are often weary about excessive extra communication time across phases
- Reusability – Reusing design and UX components allows for quicker builds and a range of development benefits Understanding – A better knowledge of the platform and it’s limitations will allow design and UX to avoid areas that may prove difficult to implement. Limitation of scope creep – Quite often designers can add touches and flairs to designs that will prove difficult to implement which increases time. Understanding what can/can’t be done will support limiting this. Understanding Features – By understanding the features that the platform has design and ux can leverage these to show great results with less effort. FED cooperation – If design come up with over complicated designs which will be a nightmare to implement it will cause headaches at implementation. Working with the FEDs at a design will have alleviate these issues.
- Limitations Lack of theming Lack of default structure without extending
- Blocks – To be continued later Icons and Previews for items CMS editor stylesheets for overriding styles in the CMS and also rich text support Supporting editor previews Modules like forms and what can be extended
- Episerver allows you to either turn multiple sizes off or define a number of presets that apply to all blocks to allow different sizes of blocks. An example of this is on the Alloy demo with the narrow/wide/full sizes Rendering the wrapping divs can be annoying and can be turned off using some custom code Previews I always give special attention to, there may need to be custom markup for certain things (Such as text and links) which ideally should be work with a fed to support. The Structure isn’t fixed, simply extending the ContentAreaRenderer can allow us to tailor the HTML elements and their attributes which are rendered.
- Block matrix will cover name, area, supported sizes, if it has a design, if it has a ux wireframe, references to documentation/ VSTS Design document would cover all sizes/variations of each block and any responsive changes. Ideally this should allow comments and should clearly defined on which block it is.
- The master block templates for design and UX not only allow them to know up designs and wireframes fast and efficiently but also remind themselves of the blocks and features of the CMS Creation of a base build saves money at the start of a project, gives a whole set of features baked in and also serves and coding/architectural guide for developers. Nuget packages are great and separating components in to packages will allow blocks to easily be added to a lightweight base build. By separating the front end element around the blocks and components they can be added to Nuget and tested easily. Test scripting, unit tests and UI tests can be reused with minimal impact.