We’ve recently updated the SugarSync app to it’s current 3.0 release. The previous major release had a lukewarm reception, so we made sure that the highlights from the 1.0 version & the parts that made 2.0 shine were featured in this newest release. So far, the reviews have been successful, though there were many major features that existed in the old versions that have yet to carry over.
One of the biggest features is the way for a user to view their recently deleted files and folders. This is my design process outlined from beginning to end.
The goal is to understand how our users approach & use our app, so early on, I’ll consult with our support team to try to collect feedback on how users react to a certain feature. In this case, I asked how users are coping with not having the ability to work with their recently deleted items on the desktop app.
Naturally, this also gives us an opportunity to update the feature with new features, or at least features that were repeatedly requested from our users. We frequent our UserVoice message board to listen to our users & will note any feedback regarding the lack of the deleted items feature. The team also conducted some feedback surveys & learned how some users interact with their deleted files & folders. Lastly, in our user testing sessions, we’ve noted any roadblocks where users expressed their need to view their recently deleted items, so we noted the flows taken & noted that the Deleted Items feature would have been handy at this point.
I would then informally reach out to variety of other team members — usually a representative from development, quality assurance, product — to brainstorm on collecting use cases, good way to find edge cases. There’s always something that I would always miss, like a case where the user is managing their deleted items, but the encounter a server error. What does the app do then?
As this exercise helps me build up the mindset of a user, I’ll can begin elaborating on these use cases. However, to try to make the app more human-friendly, I’ll write the use cases as if the app is a human & the user had to interact with it through speech (think Apple’s Siri). A sample of a use case story:
User: I would like to view my all recently deleted items because I think I accidentally deleted a file, but not sure from which folder.
SugarSync: Okay, but our system limits us to showing you the files/folders from within 30 days.
User: I found the file. I’ve selected them & would now like to restore the files.
SugarSync: The files you selected belong to different folders. When you’re ready, I will put them in their respective original folders.
In writing these out, it helps me form some rough ideas on how the screens should be laid out.
If I feel satisfied that I’ve captured all different use cases (& hopefully all edge cases), I can begin wire framing. The idea here is that my designs should be able to answer everything written out in these scripts. These scripts should make sure that all parts of the design answers the requests of the user.
Now begins the visual part of the process! During the time I’m trying to collect use cases, I carry around my notebook to collect any early rough sketches on ideas for layout.
When it’s time to solidify my ideas, I move over to creating digital wireframes so I can easily share with the team as soon as possible. I’ve tried different wireframing tools, but found Illustrator to be the fastest since I’ve spent more than a decade in the Adobe Suite.
I refer back to my use case scripts to help me flesh out some wireframed screens. When all is done, I have a collection of screens that walk through these use cases. When it’s time to share with the team, the screens are uploaded to InVision to share as a click prototype.
Throughout this process, I’m working in proximity to the team. I would casually call them over to show them some screens to get some candid feedback as I go along. This is important because they usually help catch some oversights in interactions (Will the close button & confirmation buttons perform the same act?). Closer to the end, however, I will assemble the team for a formal design review to finalize decisions.
I’ll bring in the core team along with some other stakeholders who may provide relevant insight to the feature. A specific member from our Support team was brought in because they’ve dealt with many customers who have frequently requested this feature. Prior to this critique, we flared our thinking in trying to come up with solutions; the goal of this session is to focus our ideas into one good working one.
Attached to the email invite to the critique are the links to all wireframe use cases. I emphasize the importance of at least going through the screens once so I don’t have to go into great detail walking through the screens. Reviews are usually conducted this way: I start by quickly walking through the different wireframes/use cases, list out all the possible use cases, then finalize decisions. Hopefully, at this point, the edge cases are surfaced.
So that our most vocal team members don’t dominate the conversation, I hand out a stack of Post-It notes & pens & require everyone to write their thoughts & suggestions down while I’m walking through the flows so they can attach them to the respective printed wireframe that I’ve taped to the whiteboards after my spiel. Only clarifying questions can be asked aloud since it would benefit the group.
These sessions are always good way for developers to let us know about any major platform restraints, & the Product Team chimes in to provide business insights that can help us direct us in our decisions.
I normally block off one hour for the session, but limit myself 30 minutes for the walkthrough. The second half is open-ended & more candid so everyone usually walks around the wireframes & chats amongst themselves. In our most fruitful sessions, we’ve collaborated & came up with better solutions sketched out on the whiteboard.
After the design review & everyone is happy with the proposed solutions, we’re now ready to prepare my designs to be translated to detailed specifications so that the developers know what I want to be built. We use JIRA to track our projects through submitted tickets called Stories, so my specs are written there so that the stories can be split amongst the developers. Remember those user stories I wrote earlier? Coincidentally, they broken down enough that they can act as Stories in JIRA. This big Deleted Items feature is called an Epic in JIRA.
The beauty of working with a team for so long is that the more I work with them, my specs become more & more abbreviated that I can almost spec out in shorthand. Also, because we’re just adding a new feature to an existing app with an existing design pattern, these box wireframes would suffice for our developers.
For reference, the developers always have access to a UI kit I’ve provided. It acts as the style sheet for all design elements in our app.
It’s a running UI kit that the developers can refer since it acts as the pattern library. It’s easy to draft up specifications because I’ll just say that I’ll need the “green primary button” & they’ll know how to build it.
Happy ending: it’s in progress of being built! We have awesome developers that work with me & inform me if my specs need more detail. Most of us are in-house, but our offshore developers in Russia are excellent & we collectively have a good process from design into development.
I had to pare down a few features because the platform still needs to be updated, but have reserved in the backlog so we can handle it down the line after our major releases. In the end, the Deleted Items feature would act as an excellent minimum viable product. It’s a feature at its basic level, but ready to evolve after we learn from our users as they interact with it.