Zeplin App Redesign Project

I’m going to post a screenshot of the app, write about the pain points and then post my proposal and why I think this would work better (I’m using Spotify screens as example screens for my designs and anonymized screenshots for the current versions):

Dashboard

Profile picture

Zeplin shows my profile picture as a button in the upper right corner. The main function of this button is to logout or edit profile settings (profile picture, e-mail, password and billing information). And neither of those two is a frequent user action. Notifications or navigational elements like a back button are very much so. The title bar is a very prominent placement for actions that will hardly ever be touched. I would guess it’s a web pattern, as this kind of action would better fit in the menu bar (“Files” already contains Logout) and knowing which user is currently logged in is more important in browsing sessions than in a desktop setting. Therefore I’d advise to remove it and move functionality to the menu bar.

Screen thumbnails

Before I get into tags, I want to talk about the way screens are presented. In my opinion Zeplin always had a stronger affiliation with mobile app design first and Web and Desktop design second. Maybe that is a misconception, but it is the impression I always got. And that’s why I always found it odd, that the screen thumbnails were shaped as horizontal rectangles and therefore all my mobile designs were cut off. On some screens I couldn’t really make out what the main purpose of the screen was and — here’s issue number 2 — names were cut off because I use absurdly long names to convey the exact state of the screen. InvisionApp has a really nice way of presenting screens and making sure that you’ll find the right one right away. Maintaining the correct aspect ratio would be a great benefit.

Tags

Tags are a great feature in Zeplin and I would be completely lost without it. That being said, some pain points here were that I did never know how many screens were in a particular tag without activating it. Showing the current number of screens on the tags itself would greatly improve the experience by reducing unnecessary clicks.
Also the ability to add tags quickly without having to select screens first and leaving them at zero screens would be great, instead of removing them once no more screen has this tag.

Screens

One of the issues I always had with the screen views is that the title can’t be selected and copy pasted to quickly talk about a specific screen in another channel or to rename the same screen in Sketch. As I said before, screen names are usually long and have multiple ends based on which state the screen is in. Quickly renaming screens is another pet peeve of mine, since it can be cumbersome to right-click and find the right contextual menu (no matter how close it is to the pointer) entry fast. In Finder macOS uses the slow-double-click to rename files, which I find very handy and reliable.

Updates

The biggest pain point on the Dashboard is the lack of feedback regarding updates and actions. The notification center (top right) might be a good pattern for the most recent change on which you might want to act on or if you’re going back a few entries to find a specific update. But where it becomes tricky is an overview, where something has changed and if, what kind of notes have been added or been replied to. This is what the Dashboard should do — show me which screens are important.

My proposed redesign for the Dashboard view is as follows:

The redesigned screen offers solution for all aforementioned pain points:

• Screens are presented true to their correct aspect ratio, therefore making it easier to see the whole picture and not relying on partial information.
• Screen titles are now bigger, but show more characters due to allowing 1 more line.
• Screen titles can be renamed with a slow double-click right in the Dashboard (without changing context or opening a dialog).
• Screens have icons indicating if the screen has notes on it. Users could hover over the icon to see all kinds of notes that have been added to this screen (and that are new). New notes could be displayed by a highlighted icon (see 03 Search with at least 1 new note).
• Newly updated screens (by import) receive a blue dot indicator next to their name, similar to the iOS home screen or unread e-mails in the Mail app.
• Tags can now be created quickly with a simple button and can be left empty.
• Tags have a count indicator showing the number of screens which are tagged that way.

The first 3 tags are a new feature to improve workflow experience and I will elaborate on this further once we get to the Detail screen Notes section.

There are some changes in the sidebar, but since those don’t change the interactions and are mostly just visual polish, there’s no need to go into further detail. One thing I still want to add here is: I’ve added a lot of white space (more than necessary) and tried to separate sections more from each other. Visual noise is very high in certain views in the current app. The Dashboard doesn’t suffer much from it, but some of the Detail Screens do, so I’ll explain the use of dividers: if content is well constructed and is not fluctuating too much, you can often get away by using whitespace and clever layouting to differentiate different sections from each other. However, having dividers doesn’t (always) hurt to reinforce an established layout. The Material Design guidelines have a good section about dividers, which is exactly how I used them throughout the redesign:

Full-bleed dividers separate distinct content sections (e.g., biographic details from contact information) or distinct content elements (e.g., list items) in both lists and page layouts. (…)

Inset dividers separate related content, such as sections in a list of contacts or emails in a conversation. (…)

Detail screen Info

Before we start with the pain points in the Detail screens, let’s talk about something which you might have already noticed in the redesigned screen before: I didn’t change the core 3-way-layout and navigation concept — Title bar, Main Content View, Sidebar. I’ve thought about various ways to improve upon them, but I always came back to this system, because it’s well designed. It does make sense to have the screen as the main focus point at all times visible and all additional information on the side, split into corresponding sections, but readily available whenever needed. It’s also reminiscent of the Sketch interface (where I’m guessing most Zeplin users are coming from), thereby familiar and easy to get used to.

I explicitly didn’t want to change core principles if not absolutely necessary and I was happy that it wasn’t the case here. That’s why the Detail screens feel very familiar in the redesign, yet have some changes on accessibility or new convenience features.

Screen view

The screen itself and the note bubbles are something I’m very happy with, if I had to point something out I would increase bubble size slightly to make it an easier tap target. That’s it. But what about accessibility? My first pain point is actually keyboard usage. For power users keyboard shortcuts are an obvious solution to move through an app and this feature exists to an extent, but what about basic keyboard usage? Moving through different screens just by navigation keys is possible if they are directly adjacent to each other, but if I had to jump 10 or 15 screens in one direction? I would need to quickly get back to the Dashboard and move to the desired screen. Right now I have to either click on the back button in the upper left or press the keyboard shortcut (which is fast, but not as intuitive as it should be). The solution to this should be enabling the Escape key to go from Detail screen to Dashboard, move with the navigation keys and press Enter on the right screen to enter Detail screen again. Since the Project screen is something only touched when jumping between projects and not an ongoing activity, the central hub is the Dashboard. And users should be able to jump back and forth with basic navigation (Enter to enter, Escape to “escape” — go back one step in the navigation hierarchy) between the hub and the spokes.

Screen viewing options

We have 4 distinct interface elements at the bottom, all of them with the appearance of buttons. Whenever I want to use these buttons, I have to aim very carefully, since the tap targets seem very small (also the buttons actually overlap the scrollbar because the margins don’t actually compensate for it — which I guess is standard macOS behaviour)
I compared them to the native macOS push buttons:

Those were only larger by 2pt (20pt to 22pt), but I think the reasons those buttons seem to be much smaller and therefore require more effort for me to click is because they are a bit bland and lack the same affordances that the native buttons provide (borders, different shadow to simulate depth, background gradient, higher contrast on text) and while those singled out might not mean much, together on such a small size it can make a big difference. That being said, I’m also not a big fan of the tiny buttons macOS offers and I wished they would just add a few more points to make them easier to hit.

When I first discovered the next button, I immediately thought of sharing options, since it is very reminiscent of older icons that use this metaphor, but upon trying it out I was surprised to find it actually contains the “Pop Screen Out” option. Disclaimer, I have never used this feature. It’s more for developers to compare screens and personally I’m not a big fan of absolute “pixel perfectness” (which might be ironic, regarding I just talked about a few points off in button sizes). But in my experience this sort of perfection is hardly ever reached due to a multitude of differences in a graphical representation of the desired end product and the actual software implementation (I’m talking to you, Sketch text layout settings). So if the text label is off by 2pts to the top, that’s not why your app is going to fail.
That being said, using icons for such abstract features that aren’t commonplace might not be the best idea. So I would suggest to add labels to avoid confusion.

The next button is actually really tricky because it deceives the user by pretending to be something it’s not. The “+” button actually just displays a hint how to add notes, but doesn’t fulfil any other purpose than that. So that makes it the biggest offender in the sense that you should meet your user’s expectation and not surprise them with unexpected behaviour that isn’t helping them achieve their initial goal immediately. When tapping the button, I expect to be able to add a note, not find out ways how to add a note.

I’ve tried various ways to add notes, but without completely changing the current state there isn’t a simple way to do it, that’s why I find the current system pretty well designed. But you also want to show new users how to use features that are only accessible by keyboard shortcuts. What do you do?

The UI is pretty and clean when it’s reduced to its core and only has a few icons and that’s it. But when it gets in the way of your user trying to achieve his work, it becomes unusable. The great thing about digital product design in comparison to physical products is the vast interactive and adaptive nature of the medium. We’re only bound by the code we choose to write and we can react to the user based on their needs right at this moment. That’s why I would advocate for the principle of progressive reduction. The idea is simple: simplify the user experience by reducing any kind of (eventually) superfluous helper content and visual cues based on data you gathered about your user. Let’s look at the last 2 examples: we have a fake button hiding a longer text hint. The keyboard and mouse interaction is pretty simple, so why not show the user the hint initially (without needing a button click) and remove it once you’re sure the user understands the interaction. The approach could be something like “Remove hint text after 3 correct uses of adding a note in a single session” or “Add hint text after 1 week of inactivity and not creating notes — remove after first successful adding of note” — remember that these examples aren’t based on real data yet. Same goes for the “Pop Screen Out” button — add an initial label to explain the action better, then remove it after a few successful interactions. Obvious always wins, so have text labels and helping hints right at the start and begin reducing it once you’re really sure the user won’t need them anymore (and show them again after they might have forgotten about it).

Now we’re coming to the last button and my biggest adversary in the whole app: the show/hide notes button. First I want to say great use of the (two) Three Wise Monkeys emojis. I really like it, this emoji is for me now forever ingrained with Zeplin App. That being said it’s not that user friendly.

The reason for that is that we have established that all these controls are buttons (even the fake one). Yet this one isn’t — it’s a toggle. And the big difference between a button and a toggle is that the button describes the action that will be taken or the destination you’re reaching once you click it (“Cancel”, “Save”, “Back”, “Projects”…) and a toggle describes the current state of the interface or a setting (“On/Off”). I have to disclaim that there can also be some examples of toggles that are actually actions — for example ordinary audio controls: Play/Pause is a toggle which doesn’t show the current state, but the action you can take — , but the ambiguous destination or action isn’t the only problem with this toggle: uncertainty. Doesn’t matter if I managed to find out that it is a toggle, I can never tell which state I’m currently in. The emoji is so tiny that I can hardly tell both apart and when I manage to see if the eyes are covered or not, I already forget if I should press it to reveal the notes or to hide them.

There are several solutions to this problem, in my redesign I chose a more controversial one, as you will see.

Sidebar Information

Information in the sidebar is very dense and the designers tried to differentiate between different sections with striped backgrounds. But since this isn’t a table view and sections consist of a label and it’s corresponding content, it becomes very difficult to quickly distinguish between labels and content.

Let’s talk about the purpose of the sidebar in relation to the screen viewing options at the bottom of the screen view. The screen viewing options display a variety of actionable options to change the appearance of all screens in the project — namely zoom settings, adding notes and showing/hiding notes. Every setting you change here affects the screen you’re viewing and all other screens as well (with the exception of the “Pop Screen Out” button, but it makes sense to have this button close to the actual screen itself and not off to the side).

The sidebar displays information connected to the screen you’re currently seeing and only this screen. It has different sections, each filled with corresponding data (colors, assets and comments) depending on the screen. Yet the grid toggle is a project wide setting and influences every screen, not only the one currently viewed. So the grid toggle should actually be located near the screen viewing options.
Also I’m not sure about naming conventions. I can’t exactly remember if and how Photoshop handles layouts, but in Sketch the feature is called Layout, not Grid. And if I’m correct in assuming that most of Zeplins users are coming from Sketch, it would make sense to keep naming conventions the same to avoid confusion.

My proposed redesign for the first tab of a Detail screen:

• Simple keyboard interactions: press Escape to go back to the Dashboard.
• Standard macOS push buttons (slightly larger than custom ones and affordance is more apparent).
• Added grid toggle as split button — click main button area to toggle between grid on/off. Click dropdown indicator to show grid specifications.
• Changed “Pop Out Screen” icon and added label (against macOS HIG — they advocate to never use an image and a label for push buttons)
• Added basic text hint for note adding (progressive reduction principles — this won’t be visible all the time if you’re an active user of this feature)
• Changed toggle to push buttons, kept monkey emoji and added label to make it clear what is happening when clicking the button.
• Separated Sidebar sections more.
• Added States feature

Feature: States

The idea behind states is basically to have screens act as folders to contain multiple other screens. When I’m working on a design my Dashboard is always cluttered with many, many screens. But most of the screens are actually either

1. variations/alternatives for the same screen to have product team or manager decide on what we’re going with, or
2. different states of the same screen. Because I want to avoid as much confusion as possible I wind up with a multitude of screens that would require much back and forth explanation if I hadn’t included them. Things like “What happens when you scroll down?” or “What does this look like when the label extends much more to the right?”.

States would keep the Dashboard clean with actually the real screen flow and hide necessary complexity within a logical context when it’s needed (progressive disclosure). These states would be completely independent screens in regards to assets, colors or comments, with the only exception being tags (as the states wouldn’t show up in the Dashboard as seperate screens)

Interactions with this feature could even start right in Sketch: by parsing layer names you could set up patterns like ScreenName*StateName so that Zeplin could automatically group all layers with the the same prefix together (and have the artboard called only ScreenName be the parent screen) and display whatever follows the asterisk as the state name.
And in Zeplin you could select screens and drag them on top of each other to achieve the same effect. The screen that is dragged would be automatically added as a child. Since Up and Down arrow keys are not used right now, they could be used to change quickly between states.

Detail screen Colors

The colors tab is actually a pretty simple one. It offers the set background color and available fill colors for all in Sketch specified elements with the option to add them to the styleguide.

I found the color display to be pretty narrow, so I would enlarge those to give a better sense of the color. The color list is also pretty tightly packed and the color displays are right next to each other, adding some white space might help to allow skimming by differentiating between the rows a bit better.
Other than that I think this tab is pretty well designed and compared to other spec tools I don’t have to either hover or click on colors to get more information. All the available data — Hex code, alpha value and optional variable name — is presented right here, which I find very handy.

I could think of some convenience features which are barely worth the effort, that’s why I’m only mention it in the passing: maybe allow for clicking on the color display to quickly highlight the elements containing the corresponding color. Or have a dropdown for each color to directly show all elements for this color.

• Enlarged color display
• Added white space to the list items

Detail screen Assets

The asset tab is pretty close to the colors tab, but there are a few more interesting things going on. For example I have always wondered why it is nowhere explicitly stated how many elements there actually are on this screen that I can export. The wording could be misleading: in this example Zeplin treats each individual file as an asset, where one could say that there are only 3 assets and in case of PNG export (5 files — mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi — per individual asset) actually 15 files, not assets. I wouldn’t be surprised to find out that others have a different nomenclature or just call every file asset, so this is just a minor point.
In this example there are only few assets you would have to count or you could argue that you could look up the SVG assets, but these are only hacks for a simple question, really.

I was also confused to have basically the same kind of nondescript visual (orange bubble, white text) for two very different file types, which could potentially lead to unexpected exports. Color coding different file types and/or adding other visual cues to show distinction between all possible file types could go a long way to ensure the expected result when exporting. Speaking of expected results I can’t help but mention that it’s dangerous to put 2 unlabelled icon buttons (with no button affordances) next to each other.

Regarding the asset preview thumbnail I found that the preview adds margins to some of the assets, despite them not being exported as such. Which is undesirable as the preview should help find anomalies in exports or reassure that everything is as it should be. Scaling up or down to fit in the thumbnail size is understandable, misleading the user by adding unexpected margins is not.

• Explicitly stating how many assets exist on this screen
• Using the file metaphor, icons and color to distinguish between the two file types (PNG = raster-based, SVG = vector) and also adding some detail like a file stack for PNG to convey that there are multiple files per asset in this case.
• Minor feature: adding final export size to eventually spot anomalies.
• Using pushing buttons with explicit labels allows the user to focus all attention on the buttons and not even read the left side.
• Asset preview thumbnails display correct margins.

Detail screen Notes

Now to the most important aspect of the whole app for me: the Notes tab and notes on the screen. This is where I as a designer spend most of my time.

Let’s talk about the sidebar first: it suffers from the same lack of distinction between conversation sections as some of the other tabs do. By not using dividers or contrast it’s up to the layout to make it immediately clear which notes belong together and which don’t. But not only is the tiny gap between the narrow note colors the only hint that a new conversation is starting, also the complete visual disconnect between the notes in the sidebar and the notes in the main content view makes it really difficult to link them together mentally. The note elements on the left have a few key identifiers: shape (presented as circles), color (every note has a fill color with a white border), spatial features (by displaying a light drop shadow the illusion of elevation is evoked) and a unique text string (note index starts at 1, increments by one with each note, is unique as in never changing and also displays color as its own additional identifying feature). The sidebar removes 2 out of these 4 identifiers right away — shape and spatial features — and completely separates color and the unique text string by showing one on the far left and the other on the far right (while also changing the text color and string by adding an octothorpe in front).

The sidebar also offers the latest reply to the note, which I find kind of a nice feature, but it also adds a lot of complexity to it, which may not be the best course of action. By reducing the content to its core element (the original note) and by only displaying further context on click you could hide complexity (progressive disclosure again) and have the sidebar serve the purpose of a quick overview over all existing notes.

In the beginning I stated that Zeplin is a collaboration tool between designers and developers. But that’s not all it can be used for. I also use it to talk to product managers or stakeholders, get feedback and have a back and forth conversation about features, ideas or even only for validation (a “Good job” can go a long way). And while Zeplin offers a variety of colors for the notes I always felt that they were underused. Colors can be randomly selected and have no labels attached, which is — to some extent — a good thing, as it allows teams to create their own work flow and assign meaning to each color. But on the other hand too much customizability is difficult to streamline and could be complicated to create a well designed work flow with.

Let’s start the redesigned features with the most consequential one. This feature is highly dependent on each user’s workflow, but I think the following is pretty common:

• Note colors have been reduced to 3 and have unique labels assigned them.

These labels are To Do (Red), Comment (Blue), Done (Green) — RGB for the win.

Differentiation between orange and red, yellow and green were always difficult (especially for me, since I suffer from a mild case of red-green color blindness — obligatory ~10% of the male population suffer from it), that’s why those 3 colors survived as they offered a stark enough contrast to be distinguished.

Every new note starts off as a red To Do note, but can be changed to Comment or Done anytime (just as in the current color system). Users can be assigned those tasks by mentioning them in the opening note.
Comments are notes that need no action to be taken, but are rather used to explain certain behaviour (interactions, animations, transitions, navigation, etc…).

I’ve always wondered why it wouldn’t make sense to allow some sort of micromanagement for each screen, so every user would have an easy time to see which screen needs work and which screen is done. I’m guessing most users took it upon themselves to assign colors to tasks, done tasks or simple remarks (as did my teams and I), but Zeplin wouldn’t allow for smart filter options to really show only the important stuff or let me focus on it.

This is achieved in 2 ways:

1. The sidebar offers filter functionality by showing All, To Do, Comment and Done in a segmented control to switch between and with a count indicator to quickly see how many tasks are still to do or how many are already done.
2. As seen on the Dashboard, as soon as any type of these notes get added, automatically curated tags appear for it. Those tags have the same name as the notes and the logic is handled as follows:
   To Do tag: all screens with at least one To Do note will be tagged as such.
   Comment tag: all screens with at least one Comment note will be tagged as such.
   Done tag: all screens with at least one Done note and no To Do notes will be tagged as such.

This allows to easily filter for screens that have specific notes on them and make managing much easier despite not more work for the user.

To continue with the list of design changes:

• Sidebar notes only display original note with an indicator if there are any replies. Main interaction (replying, changing type of note) and secondary options (edit, delete) still happen in the main content view.
  Also the visual disconnect between notes in the sidebar and notes in the main view is gone as they use the same styling now.
• The notes popup in the main content view are automatically expanded to show the reply input area, therefore requiring one less click to add to the conversation.
  I thought a lot about placement of the button to change note type and decided to put it close to the reply input area as to encourage posting a reply upon changing type. You uploaded the missing asset? Let the other guys know that by posting a reply.
• The final touch for notes is an additional feature that allows you to link screens in the comments so you can jump directly between screens. This could be used to create a very simple navigation prototype for the always upcoming “Where does this button lead to?” question.

Import and upload

Before we go over the last tab in the Detail screen, we have to talk about another new feature first. And this stems from the wish of some developers and managers to have a little more oversight of what’s happening. It’s often difficult for the other people in the project to be aware if and of changes that have been made. And that makes sense to me. Personally I have always wondered why designers often get cut some slack in this regard while developers have to take care of their commit messages and patch notes.

So the main idea is to add the possibility to write change logs for every screen you’re uploading to have a history of changes and also let people compare results. That’s the gist of it. And because this is a new feature and there isn’t anything particular wrong about the Import dialogs, I’ll jump right into the newly introduced work flow:

Zeplin has a Slack integration for some of these issues, but solely relying on a single third-party-integration to solve push notifications is certainly not working for everybody. Not anyone is on Slack, so I would rather use Zeplin’s own app notifications to update people.

This could be as simple as selecting and sending a push notification to certain people to let them know about any updates. But what about screen change logs? An import could mean more than one screen, maybe dozens. And how does one design for the case that some people don’t want to use this feature?

After several iterations I came to the conclusion that in order for it to work seamlessly, we can’t just throw dialog after dialog at the user, it has to be very unobtrusive in order not to scare users away. That’s how I arrived at an persistent, expandable status bar to contain all imported screens, horizontally scrollable (due to the nature of the OS — with Touchpads and Magic Mouse shouldn’t be to big an accessibility hurdle).
That way you can entirely ignore the feature, aren’t stopped from further interacting with the app, but you can still expand the bar whenever you wish and write down some changes.

I don’t know why Zeplin is using indeterminate progress bars for the upload, I’m guessing it is due to technical difficulties. Which is a shame because it would be a nice feature too see exactly how fast (or slow) I’m uploading. That’s why I included it in the redesign, but with the suspicion that it might be a whole lot harder to do.

With this feature being added, we can take a look at the final Detail screen:

Detail screen History

The History tab would include a timestamp, person responsible for change (not necessarily just screen import), a change log entry and a snapshot of the screen at that time (clickable to magnify). I thought about the depth this feature could bring, but decided against a more detailed snapshot, i.e. the snapshot is just an image, not an interactive screen with its own description, colors, assets or notes. This would make interacting with it much more difficult and that’s not what Zeplin needs.