How we design enterprise software

[The] goal was not to enforce a new way of working, but to observe and codify what's currently effective and create just enough structure to aid communication, clarity and transparency throughout the lifecycle of a project, both inside and outside of the design team. — Tom Harman, Design Manager at Buzzfeed

Fuse Engineering, Product and Design from the start…The team should resemble a three-legged stool, in which each leg represents one of the three areas that helps build a product. If it's done from the start (Figure A), each function can grow in parallel and proper ratio (Figure B) as the broader organization scales. — Alex Schleifer, VP of Design at Airbnb

• Designers were using inconsistent workflows in their projects.
• There was a lack of understanding throughout the company about how exactly our team worked or even what it was we did.
• Onboarding new designers, both new employees or another designer stepping in to help during an active project, wasn't as seamless as it could have been.
• There were a bunch of undocumented or open questions that we all had assumptions for in our heads but hadn't been written down.
• Designers weren't moving as fast as they could have as they weren't exactly sure when to check in or if they had to get permission to make certain decisions.

• Align the team and document our workflow.
• Educate the company.
• Make it easy to onboard new designers to the team.
• Speed up designers starting on new projects.
• Empower designers to make decisions so they can accelerate progress.

• Is the designated design owner for a project.
• Is responsible for delivering a delightful, useful, viable solution for any given design project.
• Is not just responsible for delivering design artifacts, but also for the final product that gets shipped into our users hands.
• Is point of contact for design and typically works closely with the Product Manager, Tech Lead, Engineering Manager and Engineers.
• Owns decisions from a visual design and user experience perspective, in collaboration with Product Management and Engineering.
• Is responsible for gathering feedback from all stakeholders and ensuring what is delivered is reflective of the company's business objectives, design principles, and brand.

• A Design Project is an initiative or piece of work that has been accepted by the Design Team.
• Typically it will be an initiative to design the experience of a feature that will be built in an upcoming release, which may or may not include GUI and CLI components. The initiative may also be to conduct discovery on a future idea that we may or may not want to move forward with.
• Each project has one dedicated Design Lead but could have manydesigners working on it.
• Projects are considered "complete" once the designs are in a ready state. However it is the Design Lead's job to continue to follow up on the QA and development of the feature to users and set up any additional projects needed to improve the feature.

• Understand who the customers are that are asking for this or suffer from this problem.
• Run a kickoff meeting with cross-functional teams.
• Ensure roles are clear.
• Visualize what a successful project looks like.
• Create docs associated with this project (e.g. scope doc, wiki page to track progress and meetings, tasks and todos).

• Talk to users/customers that fit the persona and experience the problem.
• Talk to internal experts and stakeholders. Who is championing this?
• Look at how others solve this problem. Competitors or similar tools and patterns.
• Document and share what you learn with the rest of the team in the wiki so you have a shared understanding of the issues.
• Understand what technical constraints there are. Do the APIs for this exist today?

• Sketches. Wireframes. Flow charts.
• Facilitating brainstorming and design studio sessions with the cross functional team.
• Get feedback and input from design peers.
• Check feasibility. What is realistic? Work closely with Engineering and PM to align on this.

• Create a proposal that can be validated e.g. diagram, flow chart, clickable prototype (InVision, Framer etc.)
• Increase fidelity gradually with each cycle.
• Too high fidelity early on is bad as you get tied to that solution and critique often focuses on the color of a button instead of whether this is the right flow.
• Too low fidelity will affect people's reactions and feedback and they may not be able to fully grasp the full end to end design.

• Run or attend user testing sessions.
• Conduct calls with customers.
• Share work with open source community and UX research mailing list.
• Confirm with the entire team about the feasibility of the current proposal.
• Review with internal stakeholders.

• Add polish to designs. Check brand and design system alignment.
• Ensure prototypes are up to date.
• Make sure any flows or additional design artifacts make sense with revised scope.
• Update wiki to include design user stories and actions and use these to help engineers create tasks for their work.
• Ensure states are thought through and designs provided if need be e.g. error states, empty states, open source vs enterprise.
• Have detailed walk-through sessions with engineers and documentation team who will be working on the project.

• Assist and sit down with developers actively working on the feature.
• Provide quick turnaround solutions to problems that come up. Sketches or quick mocks are preferred at this point.
• Demo work in progress.
• At this point designers are likely spending 80% of their time on design and discovery for the next release.

• Create issues (tasks, bugs, suggestions) for any related issues.
• Work with Product and Analytics team to measure the impact of your solution.
• Continue to gather qualitative data with user testing and research.
• Conduct retrospectives with cross functional team.

• Your workflow needs buy in from your cross functional team, especially those you work with on a daily or weekly basis.
• Having front-end engineering involved we were able to address questions like "When is a design considered complete". To which our response was "Design is never done". Which wasn't helpful for them of course. But the discussion helped us reach a point where we could define a design as "ready" as in "ready for you to take this and build it".
• Having Product Management involved we were able to address the issue of us not being involved early enough. Or PMs not being involved enough in usability testing and UX reviews. We were able to talk more about the parts of the workflow where they really care and want to be involved more, and likewise where design would like to be involved more in the product discussions.
• Putting this in a wiki is good but certainly isn't enough. You need to continually educate and evangelize this stuff. Blog about it. Send it out in emails. In Slack. Present it to new (cross-functional) team members. Stand up at meetings and talk about it.