Design Engineers are..
skilled at both design and front-end development, and they are able to contribute wireframes and mockups as well as front-end code. Both disciplines require logic and creativity.
They help designers see new technological solutions to design problems, and they help engineers better understand the power of design.
A design engineer might focus on:
- setting up a design system
- documenting patterns
- performing workflow audits and updates
- building UI components
- writing usage documentation
- working with stakeholders spread across an organization.
Additional tasks could include establishing and maintaining a local development environment, setting up testing, and release management.
- Who are my typical customers?
- What are my customers’ pain points?
- How does the product/feature I am making fit into their life?
- What are some of their habits or behaviors?
- What are their needs and goals?
- How does this product solve their problems?
- What are the most important features for the user?
- Does our product add value and solve problems for our users?
- Will this solution benefit the business?
- How can these pain points be solved?
- Based on my user, how will the business make a profit?
- Who are my top three competitors?
The more satisfied a customer is with a product, the more likely they are to recommend it.
- Effectiveness. Does the product achieve users’ intended goals?
- Efficiency. Can users accomplish a task with minimum effort?
- Satisfaction. Does the product make people feel good?
- Will engineers be able to build the features within the time, resources, and technology available?
- How much time do I have?
- Who is on my team?
- Is there anything else I would like to test and validate before the features get released?
Questions at the intersection
- Where are your team’s collaborative pain points? Is someone constantly having to pick up the slack? Is a single person a bottleneck for a workflow or process?
- Are unhealthy team dynamics emerging? Are designers and engineers increasingly feeling unheard or undervalued for their contributions?
- Do we frequently experience feasibility surprises and amass technical debt as a result? Do we find ourselves reinventing the wheel? Are we losing time solving solved problems and duplicating code and effort?
- Who owns the work? Who is accountable? Who reviews the code? How does a component get shared? How do we collaborate on ownership?
- Is our approach too waterfall-like? Are engineers unable to start working (prototyping, validating, scoping work) until designs are finalized? Are designers having to make decisions without having requirements set?
- Are design and UI in alignment? When design brand guidelines are updated, who makes sure those changes are correctly updated at the appropriate level without creating overrides or inconsistent implementation? How do we test that something is not missing?
- Are we having a lot of unnecessary, unproductive meetings? Are we throwing time at the problem of communication gaps?
Design Technologist (validation)
How does the candidate address the game dynamic? How does the candidate approach the game from a prototyping perspective? How easy is it to change or update any aspect of the game, making it faster or slower and updating the design? How does the candidate express themselves and add their own flavor to the game, with an eye to user experience? When she was interviewing, Christine Ma, a UI engineer at Indeed who started out as a design technologist, submitted a game about a meteorite hitting the earth. Instead of dots falling from top to bottom, which is the standard wireframe of the game, she made the dots fall diagonally. There was a race against the clock to prevent the meteorite from hitting the earth. Christine’s willingness to add a narrative and introduce a better user experience was sublime.
UI engineers (implementation)
How does the game demonstrate candidates’ excellence with regard to code quality and coding practice? Is their solution scalable? How complete is the solution? Has the candidate successfully resisted the urge to overengineer the game by not adding any unnecessary technologies? Have they tested the game to make sure everything is useful and performant?
Design Leadership is
Don’t rush to make changes.
If you do, you’ll make enemies fast. Get to know each person in the team first.
- What’s working?
- What’s not working?
- What should I focus on?
- Start with values Before getting the team together, gather values from other design teams and jot down a few notes about the values you’d like to see your team consider.
- Gather your team and share your thoughts with them.
- Let each team member explain the values they identified.
Managing a Team
- Short term goals: How do you feel the project is going so far? Are there any projects you want to work on in the near future?
- Long term goals: What do you want to be doing in 5 years? What are your big dreams in life?
- About the company: What is the company not doing today that we should do to better compete in the market? What’s 1 thing we’d be crazy not to do in the next quarter to improve our product?
- Self improvement: Do you feel challenged at work? Are you learning new things? What area of the company would you like to learn more about?
- Manager improvement: What could I do as a manager to make your work easier? Would you like more or less direction from me on your work? How can I help you with your goals?
Design Reviews, Feedbacks, Standups
When they should happen: All the time! They’ll keep your team
Who should be there: The designer plus no more than 7 people
How it helps: Designers get the feedback they need to refine their work
When they should happen: Daily for large or distributed teams, less often for small teams
Who should be there: Everyone on the design team
How it helps: Your team gets the chance to sync up on projects
01. What did you do yesterday? 02. What will you do today? 03. Are there any impediments, or blockers, in your way?
When they should happen: After a project is launched or a sprint is completed
Who should be there: Everyone who worked on the project
How it helps: Your team will internalise lessons from each project
- What worked well for us?
- What didn’t work well for us?
- What can we do to improve our process?
When they should happen: After a project has gone poorly
Who should be there: Everyone who worked on the project and an impartial facilitator
How it helps: Your team will learn from their mistakes and find a way forward
- Facts: People recall events differently. The moderator can help the team agree upon what actually happened so lessons can be extracted. Establishing a timeline of events can help pinpoint where things went wrong.
- Lessons and actions: As key lessons are identified, they should be written on the whiteboard for all to see. The actions required to mitigate the problems stemming from the failed project also need to be identified, assigned an owner, and provided a clear deadline.
- After the meeting: The lessons learned from the postmortem should be emailed to the entire team, along with the action items that are to be completed.