Bridging the gap of UX design and product development in small team
In my last article, I have talked about the exciting project in PebblePost: Designing for an Information-rich Dashboard and Concurrent Workflow. We have followed a design journey from empathizing with users, generating insights, defining the problems and making assumptions for desiring solutions. We have come a long way with a user-centered approach. However the team also faced some challenges leaping from concept to production.
The Challenges
Most of the challenges are due to the need to keep up with rapid iteration to stay competitive but with limited development resources. I believe there are various ways to overcome these challenges. However, we found a way that is particular helpful in our product development that I think it’s worth sharing.
Where to start?
This is a simple question but an critical one to me, because this is the first time I would design something from ground up. Not like a design project of which the deliverable is to present a concept or improve particular part of a larger system. This time, I would work with engineers to build out the entire thing, from 0 to 1. Then we would iterate to get from 1 to 100 as fast as possible.
When the initial idea has been validated, a lot of designers cannot wait to open Sketch or whatever favorite tools they have and start drawing UI. After all, that’s the fun part and that’s when we start to deliver design artifacts that makes every designer proud of. As a designer, I personally love this part just like a developer can’t wait to start writing codes. However, if I had taken some time to make cautious decisions on the following questions, the later-on development would be much smoother.
“Are we going to use any design language as foundation? Which one to use?”
“What’s the scope of this project? Is it to improve particular workflow/component or is it to layout the blueprint for an entire application?”
“Does the team or any developers has preferred front-end framework in mind?”
There is no right or wrong answer to these questions. But having discussed them before diving right in will save much more time later on.
For example, if you are in a small team to develop a web application, you are more likely to build on top of some existing design language such as Material Design, Ant Design, Bootstrap instead of building your own from the beginning. Picking the appropriate design language and sync up with development teams to make sure developers are comfortable to work with the corresponding front-end framework. This will save a ton of work for communication and avoid a lot major expectation mismatches. For instance, if you have blue action button on your UI. In Ant Design, you only need to let your developers know it is a button with type “Primary”. A few line of code without CSS specs will generate the exact blue button you want. It basically serves as a design system which small team doesn’t have the resource to build in the beginning.
Developer’s implementation does not quite meet your expectation
A lot of times, developers will start coding base on the mockups designer provided. By not meeting expectation I mean firstly, the implementation did not look exactly the same as the design. Secondly, it did not work as expected. Finally, you may have not considered countless of edge cases whatsoever, and you are guaranteed to see some surprises. If you have taken some time to figure out a decent design language to be shared with designers and developers, the first problem described above would have been solved. However, the actual implementation may still look different than the mockups. Mockups are usually static, the designer may generate multiple mockups for different states, different screen sizes. But edge cases are hard to cover because designers are designing static elements on a canvas tool like Sketch or Illustrator. By nature, it is hard to have a static mockup to represent UI in adaptive and dynamic environments, such as responsive screen size. In this case, if designers only provide mockups, developers will not have enough information and can only guess what designers want.
Users like the prototypes more than the real production
Since static mockups have the limitation, we heavily use prototypes, which can simulate how the application render in real environment. We use prototypes to get users’ feedback. Committing engineering resources on unvalidated ideas is a waste and prototyping definitely helps us to avoid that. However, it is tricky that different type of prototypes require different level of effort and derive different results. Low fidelity prototypes can be generated at low cost and it is ideal to communicate some early ideas in an abstract format. User like your prototype and may have nothing bad to said because a lot of details are missing or omitting intentionally, which fails to catch their concerns. As we increase the fidelity of the prototypes, user may start to provide more feedbacks but the cost of creating the prototype also increases, and we start to slow down. Inevitably, a lot of the drawbacks only being exposed when we have developed the real thing. At the time we release the product and ask user to use it, they seems don’t like it as much as the prototypes.
Though, our goal is not to develop a perfect product with a first hit. And it is not possible to discover all the issues before starting development. However, I think there are still smart ways to identify as much as concerns and problems during the design and prototyping phase with lower cost and shorter time, especially with all the amazing tools available nowadays.
How we tackle the problems
This approach may not be entirely new, but we figured this works incredibly well with us.
1. Stick to a design language from the beginning
A lot of open sources design system are maturated and free. In our case, we used Ant Design. Start working off a well established design system enable us to leverage well tested and maintained design language. It gives us the consistency throughout the entire design and development process. It also free us up from struggling with trivial design decisions like the height and width of a button, color and shades of the borders. We can always customize these design preferences later and focus our energy on more critical decisions like how is the information architecture, what does our major user flow look like, how does the user interaction work.
If you are working with tools like Sketch, AdobeXD, Framer X, you are guaranteed to find a plugin for those major design systems from which you can drag and drop UI components into your project and start architecting your UI layout immediately without drawing low level components like buttons painstakingly.
2. Sync with developers with corresponding front-end framework
After you have decided which design language to use, the next thing is to work with developers to figure out the best front-end library for development. A design language is just a set of design guidelines and principles. It is up to your team and the business requirements to determine which implementation to use. For example, Google has provided an official front-end framework for Material Design implemented in AngularJS. A third party may also provide a ReactJS implementation for it. Your team should come to an agreement on which framework to use base on your company’s technological stack and business needs. Once the design and development framework has been synced and set up, both designers and developers should feel extra confident for knowing what exactly each other need and expect. They will have more empathy for each others when they are using the same UI elements to construct a user experience.
More importantly, it is easier to align expectation because they are working with the same design/code base. It is such an efficiency boost when I don’t have to document all the trivial UI specs for developers, but just point them to online documentation of the particular UI element.
3. Prototype as realistically as possible in cost-effective way
We all known the value of prototyping and there are a lot of prototyping solutions out there for generating different type of prototypes. You can use Sketch with InVision to transform static mockups into clickable web pages. You can use Framer X to generate interactive and responsive prototypes that is possible to make it look exactly the same as a real application. But there is limitation: if you need to test user interaction, it is either difficult to test it comprehensively or making the prototype itself gets complicated quickly.
Today I want to share another amazing prototyping tool that can generate much higher fidelity prototypes. This may need some basic understanding of Javascript. The tool is called Codesandbox.io. Essentially, it is like JSFiddle, but more powerful. It runs a react web application where you can insert a few lines of codes to preview the UI components immediately. In the following example, if you want to prototype a UI with four Ant Design buttons. All you need to do is copy the example code from Ant Design’s documentation website and paste in the JS file in codesandbox:
<div> <Button type="primary">Primary</Button> <Button>Default</Button> <Button type="dashed">Dashed</Button> <Button type="danger">Danger</Button></div>
That’s it! You will see the rendering in realtime on the right window. Then you what you need to do next is like playing LEGO. You can paste codes of other UI components to construct a more complex UI.
Since what you see is what you get. You can copy the link in the preview window on the right and send it to users for getting feedback or testing. You can also share it with developers and use it as a live specs documentation.
We used this approach to generate a lot of prototypes that users don’t even know thats a prototype. We got a lot of valuable learnings when we watch users interacting with them.
Summary
The major problems I am presenting here are that, (1) It is hard or time consuming to sync up with design and development; (2) Create prototypes help us identify issues before development but it also require a lot of time and resource to build.
Our solution to these two problems are (1) Make an agreement on a design language to be used throughout the development. (2)Use codesandbox.io as prototyping tools to communicate design to users as well as developers.
Hope our approaches could be of help to you. Feel free to leave any questions or suggestions, thanks!
