Designing a new feature from ground up for an existing web project
bescouted.com
Starring Linas Šimkus as Product Owner
BeScouted is an online portfolio service for photographers, models & other related professions ( like MUA or stylists ). I was hired to visually and logically design a new feature which was set to let users create active photography projects and cast other users to particapate. Also upon completion the finished project can be viewed as a part of their portfolio. PO & CEO already had a birds-view idea of what the feature should work like, so after a day’s intro to the project and the plan we started designing more details.
Planning stage
Designing the big picture
- The abstract
We spent a considerable amount of time designing and polishing the logic behind the Project Feature. The core unit within it of course is the project itself. We decided upon the data which it has to have ie casting expiration date, project execution date, geolocation and so on. Afterwards we defined several personas with different agendas and positions within our service. We designed how each one of them moves back and forth through the feature and what are his goals, possible confusion sources and expectations at all project execution stages. The scheme had many moving parts which influenced each other in unexpected ways, so we created multiple iterations of the business logic and tried to guide our personas through it searching for illogicalities and “plotholes”, fixing them and them iterating again and again, repeating the process until there weren’t any problems we could find by modeling.
2. The schematic
After being satisfied with the abstract logic of it all we started putting it down into more earthly shape by creating a very rough wireframe of states and dialogues, connecting them and assigning functions to the connections between the states and the dialogues which later would be used by backend dev’s to materialise the feature in hard but-not-too-hard code. Also in this stage we started thinking about how the new feature integrates with the existing service, what needs to be modified there and can we avoid it to minimise development cycle. For example a whole new set of notifications across various channels was necessary, so we had to divide them into critical, not so critical, disappearing if something changed and so on. At the same time we divided the actions which each persona could perform within the feature into having minor, major and destructive impact on the project. That classification helped designing the notifications with less confusion, and also had long reaching consequences to the more hands-on UX/UI design since the destructive actions should be perceived as destructive and at all the stages the user has to understand what will happen if he performs something. During this stage we also actively ran our personas through the scheme, eliminating logic bugs to avoid having to rollback when we are already in the active development .
3. The result
After polishing the logic I created some schemes to use as a reference during design and development. Using this scheme we created user stories for the whole feature and divided them into tasks. That helped us to estimate the whole timeline of development, set milestones for UI design and approximate work frontend work schedule. Overall this allowed us to start full speed backend and db development right away without drawing a single pixel of the UI which is pretty valuable for a startup where time is of the essence.
Visual design & front end planning
Getting ready to push some pixels around
Getting to know the field.
Designing a feature for an existing service required me to analyse the existing UI elemenets, typography, grids and colors/branding. I had access to the design psd’s which I analysed, but since I use Sketch as my design tool of choice after looking through the psd’s I decided to port some existing parts of the design to sketch directly from the browser. It also helped mitigating the fact that overtime the actual running application deviates from the design through small adjustments made by marketing, PO or the designer himself directly in FE without updating the source psd file.
After understanding the visual language in place and documenting it all I planned on how I can adjust my existing workflow and what compromises can be made so I don’t ruin the visual integrity of the app while not being impaired in decision making and technology. For example the existing app used sprites for icons, so I descused a transition from that to iconfonts with the FE dev.I t is both more flexible to design, less time consuming to deploy and less taxing on performance, also it doesn't take too much time to implement. Another thing I had to change around was the color scheme, since the original app only used yellow, black and greyed-out for buttons and the new feature implied more complicated actions with the interface, so it wouldnt be sufficient. After pitching it to the team and beeing OK’ed I developed the visual language for designing the new feature.
I defined all of the colors and typography variantion I would use in my design. I didn’t include any UI kit like fields & buttons since by the limitations of the project I had to reuse the existing once to maintain uniformity across the whole product.
Iterating visual design
Few words on pixelwork
After establishing a solid logical foothold for the actual UI I started iterating the it combining the data hierarchy we established during the planing stage and visual appeal. The main challenge of this stage was that the minimum and the maximum amount of data displayed within the main project casting window could vary drastically so for every iteration I had to consider best, good, ok, bad, worse and the worst cases. I used real images from BeScouted to see how image related parts such as autocroping work, but it wasn’t that easy with the text used since there is nothing quite like this.
One of the reasons why i prefer Sketch over Photoshop is that I like to keep all the versions of the design from the very start as a primitive wireframe so I can see the progress the moment I want to see it and within one file. This approach allows me to go back and see what works and what doesn't on a larger scale, here is an example of that in motion.
Outcome
The visual design & FE development took four 2 week srpints to complete, deploy and start testing. Currently the feature is live and is undergoing performance tweaking, heres a vid of it in use with actual user-created content.
Contact me hi@alsoko.net
…or read about my thoughts about
