Although design and engineering are two different disciplines, when it comes to the world of software development, the two are inextricably linked.
Good software development depends on providing value to real users. The best software development is a fully collaborative effort across an organization. For design and engineering teams that are directly building the product, this collaboration is especially important. Ultimately, the end user is the critical point at which design and engineering intersect along the software development journey—and understanding the user starts with discovery.
The Discovery Phase: Learning from Users, About Users
A foundation of user-centered design is user research. At Stride, we conduct user research for every project, with the goal of finding out the end users’ needs and pain points. Whether internal or external end users, we gather information from the people who will be using the software, through user interviews, surveys, and/or observations. In user interviews, we collaborate with the product manager on a script that serves as a discussion guide, identifying high-level categories of information that we’d like to explore with end users.
In the Discovery phase, the designer and product manager work with the engineering lead to share any questions or concerns that the engineering team wants to hear more about from end users, again keeping in mind that user research lives at a high level of context in terms of what we're building.
Some example questions we might ask end users include: Have you ever used this system before? or How do you use it? These are starting points to find out what the user’s mental model is and what annoys them about a given system, with follow-up questions based on how they answer. Sometimes, this becomes a therapy session!
Creating User Personas
One of the artifacts that arises from the Discovery phase is the construction of user personas, which represent groups of users with shared characteristics. Often, on an enterprise level, there are enough users that clear behavioral tendencies or profiles emerge around how and why they are using the software.
User personas are great stand-ins for the different individual users of the end product. They highlight common goals and pain points of the users that drive the product development—this is the principle behind user-centric design.
Having user personas provides a touchpoint to refer back to when prioritizing features, which can help streamline and verify the development process. So, what might a user persona look like? At Stride, we like to describe a day in the life of that persona, what their background is, pain points, motivators, interactions, and device usage where possible.
Remember: Products have to be useful to end users. If a product does not add value to people and make them want to use it, even a flawless build will be a failure. For software engineers, having well-researched user personas grounds the development work in reality; meaning, the product being built has real value to a real person.
Because of this, user personas can be very helpful in taking the ego out of discussions. While a client's vision gives us a starting point for a someday-feature, it's the user personas that focus the discussion on what actual users want. That validation gives confidence to engineers in what they’re building and guide decision making about how to build the best product.
On a personal level, user personas can really enhance developer satisfaction. As Arjun puts it, “For me as an individual, that user persona has this connection to users in the world…I'm able to imagine a real person somewhere—who could even be me!—using the product that I'm building, and that's a crucial connection that gives my work meaning. It makes me excited to build and improve software.”
Defining User Workflows
Another artifact that comes out of our user research is user workflows. User workflows are diagrams that describe how end users move through the entire project or through a particular feature. By mapping out what the user needs to do in order to complete a given task, user workflows take the 60,000-foot view and distill it down to something easier to scope.
User workflows also make it easier to identify any steps that we've missed along the way. Walking through a user workflow provides an opportunity for questions such as, What happens here if there is an error? or Should we have a notification here? Designers take the learnings gleaned from user workflows and add them into the wireframes as a visual reflection of the workflow.
“The best part about having a visual diagram is that it gets everyone on the same page, and everyone is speaking the same language,” Alice explains. That includes designers, engineers, and every other stakeholder on a project. But on the engineering side in particular, user workflows help developers imagine the implementation all the way through, to bring up ideas about potential architecture, areas of research, and technical blind spots, before writing a single line of code. This streamlines the development process by identifying implementation questions before they become problems.
Incorporating Designers into Agile Processes
The way we’ve set this up so far, it might seem like designers fade into the background once the user personas and workflows have been created. In some places, that’s unfortunately exactly what does happen.
But at Stride, we’ve found that bringing in designers to common agile team ceremonies, rather than segregating designers into different versions of these meetings, leads to more productive discussions and more accurate scoping—and ultimately a better overall project. Here, we touch on a few of the benefits of having designers involved in agile processes:
- Story grooming. When it comes to product development, no one likes surprises. Including designers in story grooming provides an opportunity to walk through new wireframes or design requirements and engage in discussion about tradeoffs between design and engineering choices. That helps clarify story effort and determine prioritization in a single pass, rather than waste time separately going back and forth between design and engineering.
- Standups. What's great about having designers join standups are the conversations and knowledge being shared with all team members. Arjun loves having designers in standups because he can bring up design-related blockers, request design clarification, and alert design he’s going to need a for a desk-check soon. Alice loves being in standups because she can bring up decisions she’s making, request feedback and ad-hoc conversations for post-standup, and update the engineering team what she and product management have heard from the client.
- Desk checks are meant to be quick and easy, but that doesn’t mean they’re not helpful. If anything, it’s much easier to adjust a design during a desk check than wait until something has been pushed live. For developers who might have missed something or hit a snag in implementation, desk checks can help quickly solve issues with some on-the-fly design consultation.
- Demos. Too often, we are just heads down, doing our work. Demos offer an opportunity to sit back and see the end-to-end of what we have built and to celebrate what we have accomplished. Plus, when engineering and design have collaborated through the entire product lifecycle, everyone can confidently explain the thinking that went into the final product or feature, which helps in some cases where clients might have a tendency to derail the discussion.
- Retrospectives. For designers, retrospectives offer a different venue where the design voice can be heard. If done well, it's a team-building exercise that benefits everyone and really underscores how collectively we are all improving our process.
Design and engineering working together leads to improved product, increased knowledge, and a much stronger working relationship. At Stride, we use this approach on every project because, at the end of the day, it yields a better product for the most important client of all: the end user.
Alice Toth
