My experience with designers from a developer’s point of view.
I have been working in Frontend Web development with many companies for many years and I believe UI and UX designers are not involved in the development process as much as I think they should be.
I’ve been pleased with the architecture of solutions on which I work as I understand Component Structure, Client State, Testing etc, but I’m often left disappointed by the CSS and I feel more understanding and support from designers will help.
The following is my opinion from my own experiences working with designers. I have worked with some good designers who understand what developers need, but there are many more who do not (and vice versa).
I’ve grouped UX and UI Designers into the same ‘designers’ term even though they are different disciplines as I believe we all need to find a better way of working together.
The Problem
How much involvement should designers have in the development process? I have an opinion, but I’d first like to ask the following, slightly loaded, questions which I think will be answered differently depending on role and experience.
- Are designers required to have a good understanding of web standards and technologies, the difference between a browser and a native app and the constraints of a browser?
- Should designers attend stand-ups and regular Scrum meetings and are they often only represented by Product Owners or Business Analysts who only end up relaying questions and feedback?
- Should designers provide developers with detailed designs of each page at the different breakpoints and include an extra design for each popover and modal which might be needed on each page?
- Should designers create a style guide with wireframe mock-ups that developers can use to create a CSS framework with similar naming conventions to the style guide?
- Should designers consider the developers skill level and experience?
- Do designers need to understand CSS and how Flexbox and/or Grid work?
- Should designers have an understanding of open source CSS frameworks* and how to utilise their components and elements, but with a modified design?
- Do designers understand how the CSS frameworks are documented and therefore make them arguably easy to use?
- Would incorporating an existing CSS framework into the designs save time and money on projects as there are components already written with extensive documentation for the JS library/framework* in which your application is written?
- When should we style entire applications without using a CSS framework?
- Is there a stigma to using a CSS framework?
- Should designers think about how their designs will be tested and whether those tests could be automated?
- How can we make the application easier to use for users with accessibility requirements?
*CSS Frameworks — Bootstrap, Material, Foundation, Bulma etc
*JS Libraries/Frameworks — Reactjs, Angular, Vue etc
An Example
I don’t know the answers to the above questions, but I know developers will normally want to support and understand the designer’s UX/UI vision so they can reduce complexity. In my experience, designers are often not directly involved in the development process and rarely speak with the actual developer who will implement their designs. The design discussions are often held between marketing and the product owner who then passes on the designers’ ideas in Scrum meetings and backlog tickets.
Would it help if designers were personally required to present their designs to the development team to gain feedback on how they could be implemented and maintained? The following are two made-up stories where I hope to emphasise the problem (They are using an existing API for data)
A Tragedy
The product owner organised an extra meeting to present the 40 separate designs of the new 5-page admin application to the development team. Despite the Modals never being in the same place and size on 2 pages, one of the developers noted the designs use the same breakpoints and column layout as Bootstrap and used what looked like a navbar, input groups, modals and cards. A meeting action was created to ask the designer to investigate whether the existing bootstrap components and elements could be styled to meet their vision.
The designer hates Bootstrap, they’ve heard other designers complain about its dull look and how all sites that use bootstrap look the same — they said no and the developers used the 40 designs which were loosely related to the user stories and didn’t have a clear vision on the designer’s intent. The developers probably then either
- Styled each page/component individually and created something hard to test and time-consuming to maintain
- Planned a framework without the designer’s collaboration that ended up not working when the designs went off in a different direction or had too many variations on similar elements and/or the development team changed.
The designer was never available to answer questions and the stories were carried over several sprints as testers sought clarification and further development was required.
A Dream.
The product owner organised a workshop for the designers to present their rough sketches for the initial 5 pages of the new content sharing platform. The product owner also provided User Stories with Acceptance Criteria that contained no implementation detail for each sketch.
During the meeting, the designer asked the development team,
- What is the best way to implement the designs?
- Can we work together on a style guide?
- Do the designs work in both native apps and modern evergreen browsers?
- Can we create a design that gives us what we want, but makes the most of the resources we have available?
- How much compromise will be required on styling if it means we will save time and money and boost performance?
- How can we make it Testable and Accessible?
The developers and the designers looked at Bootstrap together and reviewed the documentation that demonstrated how SCSS can be used to update the standard look. The designer wasn’t overly keen on being constrained by a framework but understood the developer’s point of view and was willing to learn something new. They created a responsive prototype together in a short amount of time that didn’t look like Bootstrap and worked on a screen reader.
After the workshop, the designer read the online documentation and began work on the wireframes and style guide. The backlog tickets were added to a sprint during which the designer was made available for regular contact and worked with the developers to update the style guide whilst the features were being developed.
The User Stories were completed in good time as the major blockers on most stories were working closely together and testers had fewer queries with the designs. The result was an optimized fully tested reusable framework with e2e tests that met the designers’ vision and complied with accessibility requirements.
The developers referred to the vast array of online documentation and needed only to update SCSS variables to meet the design requirements and created documentation for the few extra custom components.
The designer isn’t required as much in further development phases and is freed up to work on other projects as the developers can follow the style guide and wireframe mock-ups.
*I’ve mentioned Bootstrap above, I don’t have a preference and it’s only because it is the most used Framework. it’s also worth noting that developers need to understand the limitation of using JS libraries that wrap CSS libraries as they could have limited touch support on mobile devices.
Change?
I’m aware the two stories above are tinged with bias, brevity and fantasy and in reality, most projects fit in-between those two extremes, but I hope Designers and Developers find a way to work closer. They often represent different parts of the business and might be in other buildings, countries or payrolls so conferencing tools that allow screen sharing is must to aid collaboration.
I’ve worked on projects where designers did attend Scrum meetings but didn’t empathise with how the developer would implement their designs and found it difficult to find time to answer questions as they had their deadline for styling the next feature. I’ve worked on other projects where the designer was a member of the development team and contributed to code. Their changes were reviewed by other developers and I feel this was the most effective setup. The designer improved their JavaScript skills and the developers understood the designer’s intent.
Overall, we need to better understand the problems each team is trying to solve whether it is UX or implementation and learn a bit more about each other’s craft. Developers are learning and using frameworks and libraries to speed up the development of repeating functionality, but I feel like the approach to design isn’t evolving at the same pace.
A few points to summarise
- Create a Style Guide / Pattern Library— it helps
- Work together to refine wireframes and the style guide
- Include the designers in the development process and Scrum teams and budget for it
- Do not design too much without first getting the developers involved for feedback.
- Allow designers to be available for regular short focused screen sharing meetings to discuss progress when styling a feature.
- Understand how the big CSS frameworks are documented and can be used.
- Investigate whether component and elements in an existing CSS framework can be styled to match the designers’ vision.
- Think about how the designs can be tested.
- Think mobile-first and how elements move and change through different breakpoints as the screen gets larger.
- Keep in mind a CSS framework can be removed when there is a style guide if it seems like too much bloat as only the CSS classes need to be re-implemented.
- And most of all… Keep the designs simple
User design is arguably more important than developer code as a poorly engineered application with a good UX and is better for the user then a frustrating UI with a fantasticality engineered codebase. But… system and code maintainability are really important when you want to make further changes so, work together, create a design framework and be prepared.