What to do during the Implementation phase

Question

Once it's time to turn a prototype into a concrete, usable, and ready-for-release product, I find that the role of UXers quickly becomes idle. Developers tend to swat away any meddling once they put their fingers to the keyboard. Designers hold in their hands self-laminated designs that, in their eyes, are the immovable representations of our vision as a company. Project managers are now eager to cut the ribbon and push for development to complete as quickly as possible.

The problem is, until the next project begins, I've been finding myself twiddling my poor lil' UXing thumbs.

All the while a small set of problems arise: Developers create something that isn't quite how it was imagined by the team during our brainstorming session. Designers become frustrated when last-minute revisions muddy up their spotless layouts. Management is contemplating why such an involved process was needed to arrive at this point, proposing to trim down the design process next time while effectively overlooking the true source of this newfangled efficiency exhibited by the development team.

I'd like to intervene, but how? How do I prevent the implementation of the design thinking process from becoming a runaway train? and how can I supervise it efficiently without stepping on toes or breaking hearts?

Answer 1

Every designer can empathise with alot of the problems you're having.

Implementing the designs properly

Problem

"Developers create something that isn't quite how it was imagined by the team during our brainstorming session. Designers become frustrated when last-minute revisions muddy up their spotless layouts."

Here are some activities to help these problems which I've always felt were essential in the development phase. Personally, I do find that a non-trivial amount of my time is spent ensuring the design is implemented well...

Design walkthroughs

As a developer picks up a new feature to implement, and before they start working, schedule a brief walkthrough and discussion of the designs they are about to implement.

This allows you to explain parts of the design that may have intricacies which could be missed in the design docs. This is great because a developer gets an opportunity to ask questions about the design that they might simply make an assumption about otherwise.

Some may refer to this as a 'handover'.

Desk checks

Midway through development of a feature (or at another appropriate milestone depending on the size of the work), schedule a time for the developer to run through their work with you. This isn't so formal, it's just a check-in. This will let you spot any problems or misunderstandings whilst the work is being done.

Make yourself available

This is really easy if you sit with/near the developers. Questions come up all the time. What I've found is that sometimes it's easier for others to make an assumption rather than to ask, particularly if it relates to a lesser prioritized part of the designs like the visuals (as opposed to functional requirements). If they can turn around and quickly ask you to clarify something, then of course they will. If they need to pick up the phone or write an email, the likelihood decreases.

If you don't sit directly with them, pop over occasionally and make yourself available, even if it's just to say hey. If you're remote, then just keep your communications up with them in whatever form you can.

What to do during development

Problem

"I find that the role of UXers quickly becomes idle."

Usability testing

Of course prior to development, and whilst you're in your early design phase, you would have done your user research including testing of some design iterations, and (as you've said) some hi-fi prototypes, with users.

But now as things start coming together, it's a good idea to go out and test the tasks a user is able to complete with the 'in-development' software.

You might ask why this is needed, and truthfully, there are many companies whose culture and processes are not friendly to the idea of updating the designs once development work has started, but ultimately the later a problem is found the worse it's going to be for everyone. Which is why it's suggested to test iteratively through the entire design and development lifecycle. If a company has truly embraced agile or lean development then they won't be concretely fixed to their original plan.

Management / stakeholder involvement

Problem

"Management is contemplating why such an involved process was needed to arrive at this point, proposing to trim down the design process next time while effectively overlooking the true source of this newfangled efficiency exhibited by the development team."

I've found this to be the case when management / a stakeholder is not brought along for the ride.

Workshop and testing participation

If it makes sense, and generally it does, insist on management being part of early workshops where ideas are brainstormed, research findings are presented, stories are elaborated etc, so they can see the process for themselves. My assumption here is that you're facilitating these and they'll see it as part of the design team's contribution to providing value, but also that they'll see problems being worked out and that a solution doesn't just 'appear'.

What's really useful is if you conduct some of your usability testing in-house, allow them to observe the testing for themselves so they can see the valuable insights coming out of that process and all the work that goes into a session. This can be in-person if they can help you write notes (don't overwhelm the user though, max 1 additional person), or, remotely via camera/microphone beamed to another room or online.

Showcases

As pieces of the final product fall into place, it's a good idea to showcase progress to a wider audience including the product owner, any internal users etc. This may or may not directly involve you facilitating this showcase, but it's an important part of avoiding surprises and rework later.

Include not only the work recently developed, but how the research and design effort informed the solution that's been developed.

Answer 2

I work with UX designers to ship new products so I can tell you what I like to see from a designer during implementation in three categories: supporting, learning, and inspiring.

Support implementation

Put the dev team on your side. Make them feel like you're not just dreaming up new stuff but you're actually helping them ship faster product:

• Clean, well-organized and well-communicated specs. If you want implementation to look like your product, you need to have your spec together. It needs to be easier for engineers to look it up than to make it up, otherwise they'll probably just eyeball it and see if anyone notices.

• Think about edge cases (and spec if necessary). Commonly forgotten in the initial spec:

  • How does your design work on small screens? On iOS or Android, how does it look like in landscape? Or on tablets?
  • If your product is translated in multiple languages, will the translated text fit in the space allotted? How will it work in right-to-left languages?
  • Accessibility: how will it work for keyboard users or blind users?
  • Zero-states and overflows: if you have lists, what do they look like when empty or when they are too long?
  • First-time user experience: not always needed, but sometimes you need to explain to users key parts of your interface.
  • Error states: when operations fail, either because the user didn't fill out everything they were supposed to, or because the network or the tech failed, how are things supposed to look?
  • Motion and sound design: what kind of motion should be used for transitions? Should there be any sounds to accompany them?
  • Illustrations and delightful moments: if the user will need to wait for a while, why settle for a boring spinner if you can have something whimsical and fun? Do your error states need to be drab? Make a fancy 404 page...

• Be very, very available. If a developer asks you a question, chances are they are blocked on it. Make yourself available to unblock them or they will improvise and neither of you will like the result.

• Frequently review in-progress work for polish issues and document issues as soon as you see them. Assume that nobody else but you will notice that the implementation is off-spec — misaligned elements, wrong color values, wrong margins or font sizes, missing drop-shadows, etc. Ask to look at alpha versions as soon as they're available; when you see something wrong, use the team's issue-management system (whatever feeds into their workflow) to document precisely what you saw and what you'd have expected to see instead.

• Pick your battles and be comfortable shipping a slightly imperfect product that will be updated later. This may be the hardest, but it's super important. You don't want to let the user down by shipping an unusable product — so if an issue impedes usability, or anything that you feel won't be able to be corrected later, definitely flag it. But if it doesn't, and if the release cadence of your product lets you update it the week after it ships, document your concerns (probably using the team's issue tracker) and be cool with someone else making the call about whether it needs to be blocked on. The problem isn't that these aren't worth fixing, but that there are probably much worse problems that you'll only know about once you learn from real users, and you don't want to delay that too much.

Learn

• If you haven't yet, make prototypes to test the usability of your product. There are great tools these days to do realistic mocks and you don't need a fancy lab to find people to do usability tests. Adjust your designs according to findings if not disruptive to development.

• Get feedback from peers in or out of your company (depending on how confidential your work is). Other designers: how would they have handled your design challenge? What do they think of your solution? And the people you worked with: what do they think about your way of solving the design problems, or of interacting with the team?

• Refresh your understanding the core needs and wants of your users. Steep yourself in foundational research that will allow you to understand your user deeply beyond the task at hand.

Inspire

It's also important for you to provide deeper inspiration for your team. You want to make sure that the team understands and supports the role of the product in users' life, and broader rationale for your design decisions.

Present your work to the team often and give them an opportunity to challenge you — including on your design choices, not just on the technicality of it. You can open up about the tradeoffs that you've explored and why you settled on this specific path forward.

Some in the team won't care, but many of them will too, and understanding the purpose for which they work empowers them to do better work. (See this semi-famous management parable — if you're drafting the plans for a cathedral, you want your stonecutters to know how to cut stones, but also to know and to be proud of the fact that they are building a cathedral.)

Answer 3

Okay! So, to start with, I faced the same issue when I used to design for my previous company. Thus I can totally understand your thought process on this.

I tried out a some solutions to see if this can be improved.

There are a couple of things to look at.

Actively participate in discussions during the development process

Fortunately, I had some control over the project so was able to try this out. Once the design phase of a project is completed and the development starts, keep a close eye (if possible) to see if the design can totally be reproduced without any hiccups. Lot of the times what happens is either the design will involve development time which may/may not be there or something new comes up in between. The latter is really a problem and often what happens (at least in my case).

Thus, establish communication with the team to actively improvise as required. As a designer, I really don't like it when someone tweaks up something and it breaks the consistency of the design and diminish the user experience.

You may have to improvise the design even after completing it during the design phase

Even though the process is complete you may often have to look at some parts artifacts again to fix few things. Giving this in the hands of the developer to think on the fly may effect the overall look and consistency of the design.

Changes during the bug fixing phase

As you mentioned that you don't really have iterations, it can become difficult to identify problems and then not be able to really solve it in a consistent way that you have in mind. The only thing you can do here is to communicate with the testing team and then provide appropriate solutions over time.

I guess the real problem is the communication gap between different teams. So, keep communicating with the developers and the testing team to regularly check for problems and then propose appropriate solutions. This will not only keep you relatively busy but also will ensure quality control of the experience you have crafted.

You see, design is the phase where everything comes to life. Forms a path and provides solutions and direction to people coming up with the requirements. As a designer, I take pride in saying the design phase solves a lot of problems which would have then occurred in the later phases of development.

Also, even if you are idle, you can still find something to design or may be keep improvising on what you did. Everything needs design and it just keeps getting interesting :D

May be I just re-iterated on something really direct but just thought I would share this anyway

Keep designing! :D

Answer 4

I completely empathize with you on "Developers create something that isn't quite how it was imagined by the team during our brainstorming session. Designers become frustrated when last-minute revisions muddy up their spotless layouts".

I was in the same boat a few years back for one of the product. I will share (Subjective) what were the challenges and what worked for me -

Problem and Solution -

1. How do you communicate the thought process to devs?

We were following agile so mostly it was 2-weeks sprint. Every Monday we (PM, Designer and Devs) would plan iterations for 2 weeks. For tracking, we were using JIRA, so as a designer I and PM used to create stories beforehand on the tool. All the stories would have 5 pieces,

• What persona is trying to achieve and why
• Acceptance criteria
• Prototype link
• Design Spec link (I used confluence for this)
• If any interaction/animation is inspired by something, link or recording for the same.

When devs used to estimate the stories, I used to provide a small brief on my thought process and what is expected.

2. How to keep the sanity check on design?

Before I shade light on the solution, I want to talk about the process we were following. When devs are done with stories, they assign it to QA with test cases. QA verifies the same and reassigns to devs if they find something is not as per design. Devs would contact me for clarification, fix it and re-assign to QA. a lot of back and forth was involved and was time taking and inefficient.

I discussed with the team and initiated a process - UX sign off. Going forward any completed story/issue from devs comes to UX first for sign off. Once Designer has verified it from the aesthetic as well as experience perspective then only it goes to QA. This way we could save QA time and designers could collaborate more with the Devs. This resulted in Devs to learn and understand the importance of design.

Answer 5

Start working with developers from the outset, not just at "implementation."

This challenge you describe is a permanent characteristic of situations where you have designers and developers as 2 separate working teams with isolated vertical conduits of strategy directing their respective efforts. That's the real problem, and what you're calling the problem is actually the symptom.

In my opinion this mostly the designers' problem to deal with, not developers'. Your best efforts as a designer are only as good as their willingness to interpret your self-laminated designs faithfully and consult you when they have questions about intent.

In the reality I live in, developers have more to gain (i.e. getting code pushed, a version shipped and progress made even if it ain't perfect) by making their best guess than they do by pumping the brakes to ask you for clarification.

There is this staid, inflexible school of thought that characterizes UX design as this stepwise sequential process in which a "handoff" occurs to developers, and they follow some prescriptive instructions. You'll see a lot of beautiful artifacts with diamond structures and phases and such to describe the theoretical ideal approach to the design work from ideation to implementation. In practice, I've never, ever seen any project work that way.

Developers are doing the coding that makes the product, and these days they just walk over and talk with product and business owners, so whatever UX is aiming to accomplish has to fit in with how they work. Otherwise we're just in the way.

Update to this answer: Jeff Gothelf did a much better job explaining the risks of approaching UX design as a phase-based work deliverable that is handed off to developers:

"Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity."

So to answer the question:

"What do I do during the implementation phase? I'd like to intervene, but how?"

Don't think of it as intervention, that has a negative connotation. With a leaner approach to UX it's more appropriate for you to be involved at all phases - and that goes both ways. Developers should be able to weigh in on early design concepts without fear of "stepping on toes."

Focus less on deliverables produced from a design phase, and more on the human outcome to be fulfilled by everyone's combined efforts.

Answer 6

If there is capacity, get involved with the development side of things. As long as expectations are set it can be a great learning experience. It'll also put you into the shoes of a developer which may come in handy in some ways when your designing prototypes.