Dream book Case Study
Case study about Dream book web app. Problems we had to solve, issues we encountered, and how we solved them.
Dream book is a web application that serves as a tool for interior and exterior design, landscape design and home improvement.
It allows user to search and upload content, create projects, rooms and features. The idea behind it is to help the non-designers communicate their vision to the professionals that are going to work on the remodeling project or the house construction. They would communicate their vision by saving images of specific features in their “dream book”, and organize them by rooms or complex features.
Finalized “book” is a digital album of products that can be purchased on their respective websites and serves as a home’s style guide.
For the purpose of this text “nail” = “card with an image and control elements”.
I have joined the project in September of 2017, several months after it started. At that point art direction, ux flows and base styles have already been set. My main role for the next couple of months was to create new UI’s as a front-end developer. In the months to come I worked with developer, project lead and the client on the design and development of new features and the redesigns of the old ones where needed. At this stage I got to carry out both UI design and front-end development, while UX flows were decided on the group meetings.
There were 2 main questions we were trying to find answers for:
1. How to make users start projects instead of starting to scroll and checking out different “nails” (cards), and how to make them save those individual features to their rooms?
2. How to make complex app easy to use?
“Start the project”
With the new users in mind, we decided to streamline their experience towards the three consecutive actions: start a project, find what you want, save it to the room and continue designing.
Starting a project
An issue we encountered from the very beginning was endless scrolling. We did not call it like that. Test users would start scrolling, skipping the “start the project” button on the very top. The most often feedback complaint was that they: “weren’t sure what to do”. In the retrospective I called it: “The endless scrolling issue”.
We tackled that issue on the several different fronts the most important one being the new “welcome page”. New welcome page forced new users to create one of the offered room types, choose their preferred style, nail their very first feature and save it to the room. We wanted to make them focus and think about their future project from the get to, and not getting carried away with the pretty images that dominated the application.
Welcome page was followed by the short tutorial, highlighting all the main features on the home page. It could be accessed again through the profile settings but it would not show next time users would log in.
Find what you want
This step was a way easier to solve since we already had a good search bar taking the most of the horizontal space in the main navigation. We agreed that the main navigation should also be fixed, making the search and start buttons accessible at all times.
Second search tool we developed was a scrolling carousel similar to the ones used on Google images and Pinterest. The one we developed is unique in a way that users can toggle between room types and room styles depending which one they are trying to find.
The very last search option is the “nail feed”. It is a standard collection of cards, based on the user’s style preferences with the infinite scrolling enabled. Design goal of this section was to show as many nails as possible on the screen. Images take most of the space. They are centered within the nail with each having their title and type, plus price and trending status where applicable.
Save it to the room
Once a nail is clicked on, image is displayed in it’s full size with additional details and saving options.
“Ease of use”
Second big issue that started small but grew exponentially as we were adding new features was over-cluttered interface. For example our “card” can be of 3 different types, (we had 5 at one point) “Room”, “Inspirational” and “Feature Nail” and 2 different states (saved and not saved). There can be 6 different controls on a single card, and a several descriptive attributes.
To make that information overload somewhat clean and organized we decided to separate controls and descriptive attributes from an image but keep the card outline that binds all the elements together. Hierarchy of the elements was established using color, size and position. As a result, saving - our primary action was the most prominent second only to the image below which it sits. Next most important action was shuffling. We grayed it out and placed it opposite of saving. Once user starts shuffling, other controls show up depending on the state of the card.
As of right now, and I’m writing this in July of 2018, dream book is out and well. It’s being continuously developed and re-designed by the in-house team.
It was technically the most challenging project I had an opportunity to work on. We worked on it in a period of approximately 6 months, in an agile manner, consisting of 2 week long sprints that were sometimes cut off by other projects. Design and development sprints were all mashed up together and our main goal was to push as many new features as we could. At times chaotic we did manage to create a functional web app AND have a satisfied client.
In the retrospective, today I would have done some things differently. Keeping better control of the stylesheet and not allowing it to bubble up with every new feature, having a clear, constantly updated style-guide with every new iteration, and not doing everything from scratch when there is no time for it, are the most important lessons I’ve learned during my time with Dream book.